On 4 November 2013 13:33, Jeff Epler <jep...@unpythonic.net> wrote: >> set mdi (debug, #<_hal[axis.1.f-error-lim]>) >> get operator_display >> OPERATOR_DISPLAY 0.010000 > > Personally, I discourage use of this feature, because it ignores one of > the main points of linuxcnc's hal: ... > As a concrete example: suppose you have some kind of signal you want to > wait on from gcode. If you have a O-while loop on > #<_hal[parport.0.pin-10-in> then your part programs are not portable to > a machine which uses mesa hardware instead.
I am not sure if the feature can read signals as well as pins. Using a signal would address the portability problem. I see your point, but also suspect that any setup using this system with this degree G-code-to-HAL linkage is likely to be rather importable anyway. I used this for my lathe macros as an easy way to get values from a GladeVCP GUI into G-code. Reading the spinbox values into G-code without any hal-coding being needed suited my laziness, while admittedly undermining the whole point of HAL being the mediator of data transactions. I guess I should at the very least have had the G-code reading signal values so that there was the option of re-directing them. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
