Thinking about this some more, and about the use-cases... I think that G-code access to the INI file is good, and right. It's static data, from an appropriate layer.
All the reasonable use-case i can think of that would currently use HAL pins are for the GUI controls. So perhaps what is needed are a set of GUI controls that write to G-code parameters rather than to HAL pins? As it happens, the cases where I was using the system are now handled by subroutine parameters parsed into the MDI call by the underlying Python code, but that isn't really an option in PyVCP, and is probably more "programmery" that is ideal for the target audience of GladeVCP. Creating named parameters is something that the stdglue remap routines already do, so it is really just a case of re-working the LinuxCNC-specific GladeVCP widgets. Whether there should be a separate set, or an alternative property field I am not 100% sure. Could pressing "enter" in a GUI control send a re-synch to motion? And would that be an alternative to making parameter read into a queue-buster? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
