I'm just thinking out loud here:
>
> The question I'm asking myself: is a UI actually the right place to save HAL
> state across runs?
>
I think it depends on the data. eg toolnumber -no the interp should do that.
jog increment -yes the UI should. But you could argue in either case.
> One of the consequences of doing it in the UI is: it works _only_ for that
> UI. So pyVCP is still out there without persistence, and likely others.
Then pyVCP needs to be updated to include this capability (if it's wanted)
> I would think the right place is always the closest distance to where the
> driving datastructure lives. In the case of interpreter, persistent
> parameters are saved and restored by the interpreter itself (right), the case
> of HAL pins it is currently done by a GUI (wrong place under that criterium).
>
Well since the UI drives the changes I would think It should drive how and what
is persistent.
If the HAL pin is persistent then you must find away to initialize the widget
from the HAL pin on startup, then drive the pin after that. But what if the GUI
starts before the HAL pin?
For instance the gearchange component has persistant HAl pins but The GUI
started before it.
But you could argue that too.
hmm and I haven't thought of a no GUI system that needs persistence.
I think a common messaging system that components or UI could use at their
discretion, would be helpful. It would be nice if any component could access
any information at any time (well at least read them anyways)
Can a realtime HAL components easily use a messaging system? Kernel code is
limiting right?
And I think that linuxcnc not remembering the last tool in the spindle and
using tool 0, is arbitrary and limiting for little reason. It should use the
last tool number unless told otherwise. (by user or toolchanger)
Chris M
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
