On Sun, 16 Mar 2014, Michael Haberler wrote:
Date: Sun, 16 Mar 2014 23:16:59 +0100
From: Michael Haberler <[email protected]>
Reply-To: EMC developers <[email protected]>
To: EMC developers <[email protected]>
Subject: Re: [Emc-developers] PID bidirectional pins.
Am 16.03.2014 um 23:02 schrieb John Kasunich <[email protected]>:
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.
It might be less than helpful to discuss this problem under the angle of
'legitimacy' which is basically how you intended it to work back then under
the usage scenarios conceived back then, so I'm not commenting on that.
Fact is: there are valid use cases which are not covered by the historic HAL
design, and I am less interested in discussing the past, rather a possible
future approach, which I cannot discern yet from contributions so far.
I do know that index_enable is a pain to deal with anytime its not used in the
standard way (because it is an I/O pin). It would be easier to use in these
cases if it was done with two pins (or better still have index always enabled
and have "index_detected" and "latched_count_at_index" pins.
If you have any comments on the requirements I suggested, I am all ears.
- Michaeö
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
------------------------------------------------------------------------------
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
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
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
