On 02/01/2015 10:57 AM, Dave Pape wrote: > Hi Kirk > > I was looking for a answer to this question about 3 years ago and I did not > get any help on this topic. I hope you will get some were with this problem. > > I am using "axis" for my screen in LinuxCNC, on my machine, and it displays > the fourth axis in the same way as (Gremlin).
Gremlin is the software that does the backplot for Axis. I looks like gremlin.py bridges LinuxCNC and some OpenGL files. gremlin.py: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/usr_intf/gremlin/gremlin.py;h=457814d062ac33a080b3f82e9dc20bbc98713aca;hb=HEAD glcanon.py http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=lib/python/rs274/glcanon.py;h=6d907d622d5f547df722f80a72da54ab7b95500a;hb=HEAD I have some notes here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Gremlin and: http://www.wallacecompany.com/machine_shop/LinuxCNC/fourth_axis/ For now I'm thinking of adding an A axis pointer to the current XYZ axes pointer set. At 0, the A axis will be in line with Z but will rotate in the YZ plane around X as the A position changes. The drawing of the XYZ axes is done much less often than the tool path and the A axis could change as often as the tool path so it seems the A axis drawing needs to be in with the path drawing code. I'm not sure if the A axis pointer will be useful but I'm hoping the exercise will provide some insight. Another thought came to mind, shifting the A axis together with the tool path would be fine for paths on a workpiece in the A axis spindle, but what about paths that are not associated with the A axis? These paths should stay with the normal XYZ space, but there may not be a good way to determine which paths belong to which frame. It would be nice to see a proper working system as a guide. I think the best way to fix > this problem is to have two machine origins. The first origin would be your > home position with the cube work space of the machine. The second origin > that you could turn on and off as needed, would be centred on the centre > line of the rotary table. By shifting the second origin from the primary > machine origin the fixed work space would give you no G code out of bounds > error, that you would get if the center line of the fourth axis was moved > to the home origin. I think this would be a good solution to the problem of > the distorted fourth axis presentation. Yes, my sample g-code only moves in X and the A axis rotates the workpiece underneath it, but the displayed path could easily go out of the workspace limits, so adding A to the DISPLAY tag really only adds an indication that A has moved, but not how. > > If we could just get someone with the know how to look at this problem, > every one with a fourth axis would appreciate it. A accurate screen > presentation would be very helpful when checking a workpiece setup. I'm hoping to do some work on it and see what happens. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/ ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
