Menu
▾
▴
emc-developers
|
From: Peter J. <jen...@ya...> - 2013-06-07 19:37:37
|
Hello,
Matt Shaver pinged me that I should post an update on Rockhopper, Little Penguin and Emperor (all projects named after penguin types, in case you're not up on your penguin trivia).
I think Rockhopper is exactly what has been described: a web
interface for LinuxCNC, written in Python, that allows JSON based
communications. It supports the users choice of Websocket
connection, a REST HTML interface, or a REST interface with JSONP.
I've made a slew of updates to Rockhopper, but need to push them to
the github server -- sometimes I need some prodding to interact with
the outside world ;-) I'll push the latest up over the weekend.
Rockhopper is currently using halcmd to poll the hal pins. It's an
ugly way to do things, but it works fine. If there were a prettier
python interface to the hal layer, that would be the thing to use,
but I haven't really had time to delve into the internals of
linuxCNC and add that.
As mentioned, Rockhopper also has a HAL graph visualizer. It would
be simple enough to divorce this from the web server, but right now
I'll leave that as an exercise for the reader ;-)
As for a network-based interface, for me that is the Emperor
project. I've spent a lot of time exploring different cross
platform environments, including Java, Qt, Mozilla XUL, HTML, and a
bunch of others I can't remember at the moment. I could talk at
length about each of these, and their strengths and weaknesses as a
cross platform solution. In any event, after quite a few false
starts, I've finally settled on doing a remote interface using
HTML/CSS/Javascript. In other words, a single-page-application for
the web.
Here's a picture of what I have running now, running full screen on
a 1024x768 monitor (higher resolution would look better, but this
gives you the idea):
http://peterjjensen.com/Emperor/Emperor.png
I've also written a tablet version for Android that has the same
features, but looks a bit different. That's the Little Penguin
project. Here's some pictures of that running on my Nexus 7 Android
tablet:
http://peterjjensen.com/Emperor/LP1.png
http://peterjjensen.com/Emperor/LP2.png
http://peterjjensen.com/Emperor/LP3.png
So, to summarize:
* Rockhopper is a web server that runs on the LinuxCNC machine and allows remote control. It also includes some web pages for configuring LinuxCNC (see documentation on the wiki), including a HAL graph visualizer that works quite well for "reasonable" sized HAL setups.
* Emperor is a desktop client web page, which is written in Javascript, HTML and CSS. The idea is to make an easy-to-use interface that can be run on any desktop platform, including the Linux system running LinuxCNC (connection over localhost). Emperor uses Rockhopper as the server.
* Little Penguin is an Android app which remotely controls the Rockhopper server, just like Emperor except it's on a tablet. Little Penguin is written in Java because that is the standard for android native apps (I couldn't get the performance I wanted from a web-app on this platform). Little Penguin is intended to be used primarily as an MPG, but also has features for doing most everything else you might need to do.
* I also made a little Webmin plugin that allows starting and stopping the linuxCNC system and Rockhopper. That project is too small to have it's own name ;-)
Ok, so now the tough part: how to get it? My last post was
soliciting advice on how to license things, and I haven't really
spent much time thinking about legal stuff since then. Basically,
I want to give as much to the LinuxCNC community as possible, but
I also need to feed my daughter. Any advice on how to best
achieve those two goals simultaneously will be considered ;-) All
this will be handled through Machinery Science, LLC, which is Matt
Shaver, Tom Easterday, and myself.
* Rockhopper is currently available on github. I expect that it will ultimately be released under GPL, although I've been to busy coding stuff to actually think about legal stuff.
* Emperor will probably also be sold for a fee, although I don't know what that fee will be. Cheap enough to make it a no-brainer, I hope.
* Little Penguin will be put up on the Google Play store, and I think we'll ask a small fee to use it ($10 or so?).
Matt convinced me I should go to the LinuxCNC Fest in Wichita
later this month, so hopefully I'll get to meet a lot of y'all
there and get feedback on all of the above. I'm not good about
reading the newsgroups, but I will respond to e-mails, and will
try to follow this thread a bit more closely ;-)
Cheers,
-Peter
--
Peter J. Jensen
|
|
From: Kent A. R. <ken...@gm...> - 2013-06-07 21:35:21
|
On 6/7/2013 3:37 PM, Peter Jensen wrote: > As mentioned, Rockhopper also has a HAL graph visualizer. It would > be simple enough to divorce this from the web server, but right now > I'll leave that as an exercise for the reader;-) Since Peter's Python coding style is so much better than mine, I'll push this thought forward so others can share the experience:-) 0) get Rockhopper and install supporting packages, notably graphviz and pygraphviz (see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server), but you've already done that, right? 1) have LinuxCNC running and loaded with a HAL configuration (this is necessary so all the .hal files have already been parsed and loaded into memory so Peter's code can access the data needed). 2) in a terminal window, make sure the environment variable PATH includes the path to your LinuxCNC binaries and the environment variable PYTHONPATH includes the path to your LinuxCNC python interface. For example, I have been building run-in-place installations from git pulls in a linuxcnc-dev directory in my home directory, kreed, so this step means PATH=/home/kreed/linuxcnc-dev/bin:<other paths> and PYTHONPATH=/home/kreed/linuxcnc-dev/lib/python:<possibly other paths> The easy way to set the environment variables is to source the script provided in the distribution (for run-in-place, that is) of the LinuxCNC you are running. This means invoking . <path to LinuxCNC scripts subdirectory>/rip-environment where the above is typed "dot space" and so on. In my case, this means invoking . /home/kreed/linuxcnc-dev/scripts/rip-environment 3) execute the command python <path to Rockhopper directory>/MakeHALGraph.py <name of output svg file> So, for example, since I placed the Rockhopper directory in my home directory python /home/kreed/Rockhopper/MakeHALGraph.py fancyschmanzy.svg generates a file fancyschmanzy.svg file in the current working directory from the HAL configuration in my running instance of LinuxCNC. 4) enjoy --- Obviously one doesn't need to use fully qualified file and directory names but I wanted to be error on the side of being pedantic rather than cryptic. Obviously, all this could be turned into a self contained, do-all script, placed on the desktop with a cool Penguin-related icon, etc. To make Peter's script read from .hal files independently of LinuxCNC would take some work. For my own hal2html, which could read from either .hal files or a running LinuxCNC, I write my own naive parser for reasons I explained, but one could be bold and hook into the existing parser in halcmd. To borrow a phrase from Peter, "I'll leave that as an exercise for the reader." Finally, I have to say this focus on HAL graphs is detracting from the other very nice pages that Rockhopper presents to the user. The LinuxCNC Configuration Page, for example, is a joy when it comes to examining .ini files. Props. Regards, Kent |
|
From: Kent A. R. <ken...@gm...> - 2013-06-07 23:12:17
|
On 6/7/2013 5:38 PM, Kent A. Reed wrote: > Obviously one doesn't need to use fully qualified file and directory > names but I wanted to be error on the side of being pedantic rather > than cryptic. Obviously, all this could be turned into a self > contained, do-all script, placed on the desktop with a cool > Penguin-related icon, etc. Oops, I pressed send a tad too soon. Perhaps not so obviously, one can modify the MakeHALGraph.py script to generate the diagram in other formats besides SVG, typically including PostScript, XFIG, FrameMaker graphics, HPGL, PCL, PNG, GIF, DIA (interesting, this last one!). Regards, Kent |
|
From: Gene H. <ghe...@wd...> - 2013-06-08 00:01:01
|
On Friday 07 June 2013 19:33:46 Peter Jensen did opine: > Hello, > > Matt Shaver pinged me that I should post an update on Rockhopper, > Little Penguin and Emperor (all projects named after penguin types, in > case you're not up on your penguin trivia). ;-) > I think Rockhopper is exactly what has been described: a web > interface for LinuxCNC, written in Python, that allows JSON based > communications. It supports the users choice of Websocket > connection, a REST HTML interface, or a REST interface with JSONP. > I've made a slew of updates to Rockhopper, but need to push them to > the github server -- sometimes I need some prodding to interact with I have used it several times, and I love the concept. My main problem is that the .svg output, when viewed on a firefox screen has a non adjustable scale that is waaaay too small to be readable. And, if I make the halgragh.svg, then convert it to multiple pages of letter sized paper, I need some sort of control over the scale of the output. The last one I made, 3 hours ago, of the hal file I'm working on for my lathe, was, when converted and clipped to 8.25" x 10.5" pages, totaled 20 pages. If I had some sort of a scale control, I could do that on 4 sheets and still be able to read it just fine. I am inclined to edit the svg file, and divide the viewport by about 3, which should shrink it down to 4 pages if I understand how this works, but there is considerable doubt as to my understanding. :( The other thing is we need a switch to enable a thin, dim, page outline to aid in trimming more accurately, an outline that will show in the printouts to aid us in windy area's, about 1 pixel wide. Thirdly, it needs a switch so it does draw the stuff thats there, but disconnected. That would be handy for both troubleshooting and garbage cleanup in the .hal code. Forthly, thank you very much Peter, for a useful visualization tool. But some docs would be nice. ;-) > the outside world ;-) I'll push the latest up over the weekend. Please post the link when you have. :) > Rockhopper is currently using halcmd to poll the hal pins. It's an > ugly way to do things, but it works fine. If there were a prettier > python interface to the hal layer, that would be the thing to use, > but I haven't really had time to delve into the internals of > linuxCNC and add that. > > As mentioned, Rockhopper also has a HAL graph visualizer. It would > be simple enough to divorce this from the web server, but right now > I'll leave that as an exercise for the reader ;-) > > As for a network-based interface, for me that is the Emperor > project. I've spent a lot of time exploring different cross > platform environments, including Java, Qt, Mozilla XUL, HTML, and a > bunch of others I can't remember at the moment. I could talk at > length about each of these, and their strengths and weaknesses as a > cross platform solution. In any event, after quite a few false > starts, I've finally settled on doing a remote interface using > HTML/CSS/Javascript. In other words, a single-page-application for > the web. > > Here's a picture of what I have running now, running full screen on > a 1024x768 monitor (higher resolution would look better, but this > gives you the idea): > > http://peterjjensen.com/Emperor/Emperor.png > > I've also written a tablet version for Android that has the same > features, but looks a bit different. That's the Little Penguin > project. Here's some pictures of that running on my Nexus 7 Android > tablet: > > http://peterjjensen.com/Emperor/LP1.png > http://peterjjensen.com/Emperor/LP2.png > http://peterjjensen.com/Emperor/LP3.png > > So, to summarize: > > * Rockhopper is a web server that runs on the LinuxCNC machine and > allows remote control. It also includes some web pages for configuring > LinuxCNC (see documentation on the wiki), including a HAL graph > visualizer that works quite well for "reasonable" sized HAL setups. > > * Emperor is a desktop client web page, which is written in Javascript, > HTML and CSS. The idea is to make an easy-to-use interface that can be > run on any desktop platform, including the Linux system running > LinuxCNC (connection over localhost). Emperor uses Rockhopper as the > server. > > * Little Penguin is an Android app which remotely controls the > Rockhopper server, just like Emperor except it's on a tablet. Little > Penguin is written in Java because that is the standard for android > native apps (I couldn't get the performance I wanted from a web-app on > this platform). Little Penguin is intended to be used primarily as an > MPG, but also has features for doing most everything else you might > need to do. * I also made a little Webmin plugin that allows starting > and stopping the linuxCNC system and Rockhopper. That project is too > small to have it's own name ;-) > > > Ok, so now the tough part: how to get it? My last post was > soliciting advice on how to license things, and I haven't really > spent much time thinking about legal stuff since then. Basically, > I want to give as much to the LinuxCNC community as possible, but > I also need to feed my daughter. Any advice on how to best > achieve those two goals simultaneously will be considered ;-) All > this will be handled through Machinery Science, LLC, which is Matt > Shaver, Tom Easterday, and myself. > > * Rockhopper is currently available on github. I expect that it will > ultimately be released under GPL, although I've been to busy coding > stuff to actually think about legal stuff. > > * Emperor will probably also be sold for a fee, although I don't know > what that fee will be. Cheap enough to make it a no-brainer, I hope. > * Little Penguin will be put up on the Google Play store, and I think > we'll ask a small fee to use it ($10 or so?). > > > Matt convinced me I should go to the LinuxCNC Fest in Wichita > later this month, so hopefully I'll get to meet a lot of y'all > there and get feedback on all of the above. I'm not good about > reading the newsgroups, but I will respond to e-mails, and will > try to follow this thread a bit more closely ;-) > > > Cheers, > > -Peter > > > -- > Peter J. Jensen Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> I have discovered the art of deceiving diplomats. I tell them the truth and they never believe me. -- Camillo Di Cavour A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. |
|
From: Kent A. R. <ken...@gm...> - 2013-06-08 01:31:09
|
On 6/7/2013 8:00 PM, Gene Heskett wrote: > I have used it several times, and I love the concept. My main problem is > that the .svg output, when viewed on a firefox screen has a non adjustable > scale that is waaaay too small to be readable. Actually, SVG has no intrinsic scale. "Scalable Vector Graphics" means just that. It's your browser which is causing you problems (and Firefox is not alone in not understanding fully how to display and manipulate SVG. Life used to be better when we all had to use Adobe's plugin SVG viewer but Adobe killed that project years ago.). > And, if I make the halgragh.svg, then convert it to multiple pages of > letter sized paper, I need some sort of control over the scale of the > output. The last one I made, 3 hours ago, of the hal file I'm working on > for my lathe, was, when converted and clipped to 8.25" x 10.5" pages, > totaled 20 pages. If I had some sort of a scale control, I could do that > on 4 sheets and still be able to read it just fine. > > I am inclined to edit the svg file, and divide the viewport by about 3, > which should shrink it down to 4 pages if I understand how this works, but > there is considerable doubt as to my understanding.:( Well, that's the thing. SVG has no intrinsic scale so Graphviz helpfully adds meta information about what *it* thinks is the right size based on its internal settings. If you don't like the choice made by Graphviz you can fool the downstream tools several ways. First you can edit the width, height, and viewBox parameters in the SVG file as you suggest (be consistent, please). I think that's too much trouble and too error prone. Second you can simply lie to the ImageMagick convert program about the tiles you want it to create. Either way you are changing how much of the full sheet will end up on a single page (tile). Remember we are playing charades anyway. My first instructions skillfully segued past the fact that pixels are not the same as points but we did our computions as if they were. How the png image gets scaled during printing remains under your control. If, for example, I tell convert to "-crop 1188x1548" (e.g., twice the width and height values given in my earlier message) it will dutifully place 2x2=4 times as much of the original sheet in each png file compared to before. If you still print the png file as 8.25in x 10.75in (e.g., now 144 pixels per inch), then you'll have reduced the scale of the output by a factor of 2 in each dimension, and the number of pages by a factor of 4 (approximately, depending on details at the edges of the diagram). > > The other thing is we need a switch to enable a thin, dim, page outline to > aid in trimming more accurately, an outline that will show in the printouts > to aid us in windy area's, about 1 pixel wide. Great idea. I think it might even be done with ImageMagick. Could be either full box outline (if you use scissors) or just printer's crosses at the corners (if you use a paper cutter). Give me a night to think about it. Graphviz and hence MakeHALGraph.py know nothing about this stuff. > > Thirdly, it needs a switch so it does draw the stuff thats there, but > disconnected. That would be handy for both troubleshooting and garbage > cleanup in the .hal code. Well, I happened to run the axis_mm configuration through MakeHALGraph.py this afternoon and the resulting diagram *does* show single-ended signals (Xacc, Yacc, and Zacc, for example, each of which has a source but no sink). In earlier messages, you talked about "dead ends," which I think is covered by what I just described. Now you are saying "stuff that's there but disconnected" which I could take to mean something different Please clarify. Regards, Kent |
|
From: Gene H. <ghe...@wd...> - 2013-06-08 01:49:31
|
On Friday 07 June 2013 21:36:55 Kent A. Reed did opine: > On 6/7/2013 8:00 PM, Gene Heskett wrote: > > I have used it several times, and I love the concept. My main problem > > is that the .svg output, when viewed on a firefox screen has a non > > adjustable scale that is waaaay too small to be readable. > > Actually, SVG has no intrinsic scale. "Scalable Vector Graphics" means > just that. It's your browser which is causing you problems (and Firefox > is not alone in not understanding fully how to display and manipulate > SVG. Life used to be better when we all had to use Adobe's plugin SVG > viewer but Adobe killed that project years ago.). > So far back I hardly remember it. > > And, if I make the halgragh.svg, then convert it to multiple pages of > > letter sized paper, I need some sort of control over the scale of the > > output. The last one I made, 3 hours ago, of the hal file I'm working > > on for my lathe, was, when converted and clipped to 8.25" x 10.5" > > pages, totaled 20 pages. If I had some sort of a scale control, I > > could do that on 4 sheets and still be able to read it just fine. > > > > I am inclined to edit the svg file, and divide the viewport by about > > 3, which should shrink it down to 4 pages if I understand how this > > works, but there is considerable doubt as to my understanding.:( > > Well, that's the thing. SVG has no intrinsic scale so Graphviz helpfully > adds meta information about what *it* thinks is the right size based on > its internal settings. > Humm, is there a Graphviz.rc file that can have its tires kicked? That might even be a better idea. > If you don't like the choice made by Graphviz you can fool the > downstream tools several ways. First you can edit the width, height, and > viewBox parameters in the SVG file as you suggest (be consistent, > please). I think that's too much trouble and too error prone. Second you > can simply lie to the ImageMagick convert program about the tiles you > want it to create. Either way you are changing how much of the full > sheet will end up on a single page (tile). Remember we are playing > charades anyway. My first instructions skillfully segued past the fact > that pixels are not the same as points but we did our computions as if > they were. How the png image gets scaled during printing remains under > your control. > > If, for example, I tell convert to "-crop 1188x1548" (e.g., twice the > width and height values given in my earlier message) it will dutifully > place 2x2=4 times as much of the original sheet in each png file > compared to before. I thought about that approach too but I won't quite double it as that would go clear off the edges of the paper & I don't think this printer can do full bleed. > If you still print the png file as 8.25in x 10.75in > (e.g., now 144 pixels per inch), then you'll have reduced the scale of > the output by a factor of 2 in each dimension, and the number of pages > by a factor of 4 (approximately, depending on details at the edges of > the diagram). Next time, I'll multiply both figures by 1.65 just for grins & giggles. Thanks for confirming its a doable tweak. > > The other thing is we need a switch to enable a thin, dim, page > > outline to aid in trimming more accurately, an outline that will show > > in the printouts to aid us in windy area's, about 1 pixel wide. > > Great idea. I think it might even be done with ImageMagick. Could be > either full box outline (if you use scissors) or just printer's crosses > at the corners (if you use a paper cutter). Give me a night to think > about it. Graphviz and hence MakeHALGraph.py know nothing about this > stuff. > > > Thirdly, it needs a switch so it does draw the stuff thats there, but > > disconnected. That would be handy for both troubleshooting and > > garbage cleanup in the .hal code. > > Well, I happened to run the axis_mm configuration through > MakeHALGraph.py this afternoon and the resulting diagram *does* show > single-ended signals (Xacc, Yacc, and Zacc, for example, each of which > has a source but no sink). In earlier messages, you talked about "dead > ends," which I think is covered by what I just described. Now you are > saying "stuff that's there but disconnected" which I could take to mean > something different Please clarify. > > Regards, > Kent > That would be something that I had cobbled up, but then bypassed, with the net input probably still hooked up, so 2 or 3 modules are there, and are being fed data, but the output isn't being used anymore. That sort of stuff could be excised, saving a few cycles in the servo-thread I'd think. But I tend to leave it laying there just in case I need to 'hook' it up again for something else. I'm as packrat that way. Thanks Kent. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> Paranoia doesn't mean the whole world isn't out to get you. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. |
|
From: Matt S. <ma...@ma...> - 2013-06-08 06:56:32
|
On Fri, 7 Jun 2013 21:49:19 -0400 Gene Heskett <ghe...@wd...> wrote: > That would be something that I had cobbled up, but then bypassed, > with the net input probably still hooked up, so 2 or 3 modules are > there, and are being fed data, but the output isn't being used > anymore. That sort of stuff could be excised, saving a few cycles in > the servo-thread I'd think. But I tend to leave it laying there just > in case I need to 'hook' it up again for something else. I'm as > packrat that way. Commenting out the addf statements for the functions associated with the unused components will eliminate their time consumption in your servo-thread. Thanks, Matt |
|
From: Gene H. <ghe...@wd...> - 2013-06-08 08:59:15
|
On Saturday 08 June 2013 04:55:26 Matt Shaver did opine: > On Fri, 7 Jun 2013 21:49:19 -0400 > > Gene Heskett <ghe...@wd...> wrote: > > That would be something that I had cobbled up, but then bypassed, > > with the net input probably still hooked up, so 2 or 3 modules are > > there, and are being fed data, but the output isn't being used > > anymore. That sort of stuff could be excised, saving a few cycles in > > the servo-thread I'd think. But I tend to leave it laying there just > > in case I need to 'hook' it up again for something else. I'm as > > packrat that way. > > Commenting out the addf statements for the functions associated with > the unused components will eliminate their time consumption in your > servo-thread. > > Thanks, > Matt I thought it should, but since I tend to organize the addf's into what I think would be the correct sequence, I have probably forgotten to go back to the top of the file and do that a time or 10. An old farts short term memory doesn't help, darnit. Thanks Matt. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> A girl with a future avoids the man with a past. -- Evan Esar, "The Humor of Humor" A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. |
|
From: Gene H. <ghe...@wd...> - 2013-06-22 15:55:18
|
Trying to generate a new printout of the lathes rockhopper.svg output, now that I have it working with a G33.1 move. IIRC I used gimp to make a .pdf out of it, but now neither Posterazor or poster can generate anything that can be loaded and viewed with gs or acroread, posterazor even claims 'can't load file' but no reason given. But acroread can open & display other .pdf's just fine. Has a library update managed to hose something poster or posterazor needs before it can digest? Poster goes thru the motions, supposedly generating a 15 megabyte 6 page document, but its unprintable, cannot be opened as anything but text by libreoffice for example. I'm fresh out of clues this morning it seems. :( Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> BOFH excuse #390: Increased sunspot activity. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. |
|
From: TJoseph P. <tj...@gm...> - 2013-06-24 16:41:34
|
On 06/22/2013 10:55 AM, Gene Heskett wrote: > Trying to generate a new printout of the lathes rockhopper.svg output, now > that I have it working with a G33.1 move. > > IIRC I used gimp to make a .pdf out of it, but now neither Posterazor or > poster can generate anything that can be loaded and viewed with gs or > acroread, posterazor even claims 'can't load file' but no reason given. > But acroread can open & display other .pdf's just fine. > > Has a library update managed to hose something poster or posterazor needs > before it can digest? Poster goes thru the motions, supposedly generating > a 15 megabyte 6 page document, but its unprintable, cannot be opened as > anything but text by libreoffice for example. > > I'm fresh out of clues this morning it seems. :( > > Cheers, Gene > Hi Gene, got an svg file that i can try to process? ( process = produce tape together billboard printouts ) regards TjTr33 tomp |
|
From: Gene H. <ghe...@wd...> - 2013-06-24 17:57:20
|
On Monday 24 June 2013 13:30:01 TJoseph Powderly did opine: > On 06/22/2013 10:55 AM, Gene Heskett wrote: > > Trying to generate a new printout of the lathes rockhopper.svg output, > > now that I have it working with a G33.1 move. > > > > IIRC I used gimp to make a .pdf out of it, but now neither Posterazor > > or poster can generate anything that can be loaded and viewed with gs > > or acroread, posterazor even claims 'can't load file' but no reason > > given. But acroread can open & display other .pdf's just fine. > > > > Has a library update managed to hose something poster or posterazor > > needs before it can digest? Poster goes thru the motions, supposedly > > generating a 15 megabyte 6 page document, but its unprintable, cannot > > be opened as anything but text by libreoffice for example. > > > > I'm fresh out of clues this morning it seems. :( > > > > Cheers, Gene > > Hi Gene, > got an svg file that i can try to process? > ( process = produce tape together billboard printouts ) > > regards > TjTr33 tomp First, I got it, its hanging on the inside of the shop door a/o yesterday. Second, in lathe-stf/halgraph.svg on my web page is the rockhopper output. Now all I have to do is remember how I did it so I can do it again. Whatever I made the halgraph.eps file with added some semi accurate corner boxes that would have been considerably more useful if they were plain cross-hairs to be used as cutout guides, and I also could use a better, straighter cutting paper cutter, but the biggest problem by far was the uneven shrinkage of the paper between the imaging drums in my HL3170CDW printer, and laying somewhat curled up and cooled off, on the assembly table. Registration errors of 1/16" between the ends or sides of a sheet were not unusual because of that. IMO 24lb laser rated paper should NOT do that. It turned out that the 6 page long eps file was directly printable once I had gone into the printer and turned off the long edge binding for duplex in the menu. That option is broken anyway, the binding ditch is on the wrong edge of the paper. And no way to move it that I can find. So, many many thanks for the offer TomP, but I got it. That matching hal file might be the biggest one extant at 290 lines, if not its fairly close to the top of the list, and will be over 300 lines by the time I cobble up a 3 stage dynamic breaking function that will let me run a G33.1 loop with the spindle turning 500 or more revs. Currently its resistor is 16 ohms, 40 watts, and might be good for 3 stops in a row from 1500 revs before they melt down. One stop warms them to the uncomfortable stage. I've found 2 spare pins on the parport, and the output from a wcomp module watching the encoder should give me enough control to sequence ever lower resistor values as the revs fall. Unforch the nearest supplies of P&B ICE Cube relays and sockets is 25 miles up I-79 from me and I've miss-laid my round tuit, been busy with HD's committing harikari in this box, re- allocated sector counts are exploding. So 3 new 1Tb seacrate drives and 8 gb worth of memory to expand this box to its max memory are on a truck someplace between TN and WV. Busy, expensive week in store. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> BOFH excuse #388: Bad user karma. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. |
|
From: TJoseph P. <tj...@gm...> - 2013-07-22 08:38:56
|
Hello Peter, these docs for Rockhopper http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server say the "python API for Linuxcnc" are at http://www.linuxcnc.org/docs/devel/html/config/ini_config.html#_emc_section_a_id_sub_emc_section_a but thats an explanation of a .ini file where is the API doc? also would you know where the source files for linuxcnc.so? (imported by LinuxCNCWebSktSvr.py ) thanks for a very nice app, TomP |
|
From: TJoseph P. <tj...@gm...> - 2013-07-22 08:48:10
|
On 07/22/2013 03:38 AM, TJoseph Powderly wrote: > Hello Peter, > these docs for Rockhopper > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server > say the "python API for Linuxcnc" are at > http://www.linuxcnc.org/docs/devel/html/config/ini_config.html#_emc_section_a_id_sub_emc_section_a > > > but thats an explanation of a .ini file > > where is the API doc? found it ( difficult to search for 'linuxcnc' n<the python module> on the 'linuxcnc' <the application> site , very bad name !) http://www.linuxcnc.org/docs/html/common/python-interface.html i'll update that wiki page with the correct link if it proves correct > > also > would you know where the source files for linuxcnc.so? > (imported by LinuxCNCWebSktSvr.py ) have not found this ^^^ yet > > thanks for a very nice app, > TomP |
|
From: andy p. <bod...@gm...> - 2013-07-22 11:40:09
|
On 22 July 2013 09:47, TJoseph Powderly <tj...@gm...> wrote: >> would you know where the source files for linuxcnc.so? >> (imported by LinuxCNCWebSktSvr.py ) > > have not found this ^^^ yet I _think_ this is src / emc / usr_intf / axis / extensions / emcmodule.cc -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto |
|
From: Kent R. <ken...@gm...> - 2013-07-22 13:44:34
|
On Mon, Jul 22, 2013 at 7:39 AM, andy pugh <bod...@gm...> wrote: > On 22 July 2013 09:47, TJoseph Powderly <tj...@gm...> wrote: > > >> would you know where the source files for linuxcnc.so? > >> (imported by LinuxCNCWebSktSvr.py ) > > > > have not found this ^^^ yet > > I _think_ this is src / emc / usr_intf / axis / extensions / emcmodule.cc > > Yep. Just follow the bouncing ball in src/emc/usr_intf/axis/Submakefile. This discussion reminds me I promised Michael I would clean up the documentation for the Python Interface...about the same time I promised you (Andy) I would clean up the documentation for compilation of modules. Sigh. Regards, Kent |
|
From: Kent R. <ken...@gm...> - 2013-06-07 20:04:09
|
On Fri, Jun 7, 2013 at 3:37 PM, Peter Jensen <jen...@ya...>wrote: > Hello, > > Matt Shaver pinged me that I should post an update on Rockhopper, Little > Penguin and Emperor (all projects named after penguin types, in case you're > not up on your penguin trivia). > > <...> > As for a network-based interface, for me that is the Emperor > project. I've spent a lot of time exploring different cross > platform environments, including Java, Qt, Mozilla XUL, HTML, and a > bunch of others I can't remember at the moment. I could talk at > length about each of these, and their strengths and weaknesses as a > cross platform solution. In any event, after quite a few false > starts, I've finally settled on doing a remote interface using > HTML/CSS/Javascript. In other words, a single-page-application for > the web. > Peter: Maybe I'm just too old and battle-scarred but from my perspective you made the right choice---perhaps with the proviso that "HTML" might come to mean "HTML5". Thanks for your thoughtful summary. I won't bore you with half-baked comments here; I'm sure you'll get lots of discussion at Wichita. Wish I could be there. Think some more about licensing before you arrive<nudge nudge>. Regards, Kent |
