I think the only legitimate use case for I/O HAL pins is something like the index-enable on encoders - the "user" sets the pin true, then when the next index arrives the driver latches the index position and sets the pin false again as a handshake. This "one wire handshake" is a substitute for a more complex two-wire handshake that could be done with regular in and out pins, but has two extra states and extra HAL "wiring" to get right.
For the PID tuning case, I think the use of I/O pins is the wrong way to go about it. Micheal pointed out this HAL behavior: > however, there is one more problem: the moment you > link an HAL_IO pin which has a value preset (like > pid.0.Pgain set to 1) to a signal (which defaults to 0), > the preset value is lost. > > I dont see how halcmd can make a signal inherit the > value from such a preset pin, or read a pin value, > preset the signal, and link _then_. > > > halcmd: show pin pid.0.Pgain > Component Pins: > Owner Type Dir Value Name Epsilon Flags > 32770 float I/O 1 pid.0.Pgain 0.000000 0 > halcmd: net foo pid.0.Pgain pid.0.Pgain > halcmd: show pin pid.0.Pgain > Component Pins: > Owner Type Dir Value Name Epsilon Flags > 32770 float I/O 0 pid.0.Pgain 0.000000 0 <=> foo > ------------------------------^ That is an effect of the way HAL pins are implemented. A HAL pin is simply a pointer. When the pin is connected to a signal, the pointer points to the value of the signal. If three pins are connected to a signal, three pointers point to that value. The writer writes to that location, the reader(s) read it, and it all works. But what about when there is no signal hooked to the pin? For performance reasons, we don't want to do any kind of checking and special case code. The HAL component always simply de-references the pointer and carries on with its real-time work. But that means the pointer must always be pointing somewhere safe. The solution is that every HAL pin data structure has a field called "dummy". When the pin is first created, the pointer points at the dummy. If the pin is an output, the component writes to dummy every thread execution. If input, it reads from dummy. A setp command sets the dummy. A net command changes the pointer so it points at the signal instead of the dummy. That is why the 1 changed to a 0 in Micheal's example. There is still a 1 in the dummy location - if he were to do an unlinkp, the pointer would be switched back to the dummy and the 1 would re-appear - regardless of any value the signal might have had. The actual behavior would be: pin is created pin is given a value of 1 (by setp, or by the comp as a default value) pin has a value of 1 pin is connected to a signal pins value becomes 0 - first surprise signal is connected to a slider someone moves the slider and sets the value to 20 pin has a value of 20 pin is unlinked from the slider pins value becomes 1 - second surprise A proposal: We could modify hal_lib so that when the first pin is linked to a signal, the library code copies the value from that pin's dummy location to the signal. That would eliminate the first surprise, by preserving any value that the pin might have had prior to linking, whether it came from a setp command or was set internally by the component. When a pin is UN-linked from a signal, and the pointer is switched back to the dummy value, we should almost certainly be copying the current value of the signal to the dummy (and we aren't today). That would eliminate the second surprise. I think the only reason this hasn't been reported as a bug already is that unlink is rarely used - we build a configuration and then run with it. As an aside, if a GUI widget wants to preset itself to the current value of the signal, then its pin should probably be an I/O rather than OUT pin. That preset function is risky. Typically a GUI builder determines the upper and lower limits of the slider - perhaps 0.5 and 50 for a P-gain, for example. What should the behavior be if the current value of the signal is -200? -- John Kasunich [email protected] ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
