We recently noticed a weird problem with stepconf-generated
configurations: During startup, the charge pump (which is supposed to be
linked to estop) activates for a huge fraction of a second.
This turns out to be due to a change made between 2.5 and 2.6:
commit 51a0afc7639461edb58b0e495da1d26e5b7d4f75
Author: Michael Haberler <g...@mah.priv.at>
Date: Mon Mar 17 09:31:30 2014 +0100
hal/link/unlink: revise semantics of hal_link()/hal_unlink():
old behavior: a pin's default value would be overwritten by a signal value
on link, effectively making the default pin value invisible outside the
component, and potentially causing a jump in the pin's value on link.
an unlink would re-apply the pin's hidden default value regardless of the
signal value, also causing a potential jump in the pin's value on unlink.
new behavior: the very first link of a signal to a pin will make the
signal inherit the pin's value. On unlink, the pin's default value will
be set from the current signal value.
The result is:
- no sudden jumps in pin values as a result of link/unlink
- it is now possible to access a pin's default value from other pins
- it is possible to have the changed default value retained on unlink
Change of behavior: Code relying on signal values defaulting to zero
post-linking should be revised to consider:
So far, a new signal value defaulted to 0/0.0/false regardless of
the pin's values linked to it.
Now, the signal will inherit the first linked pin's value.
ref: [Emc-developers] PID bidirectional pins. Mar 16 2014
The discussion in that thread, (which can be found here:
http://mid.gmane.org/CAN1%2BYZVHDRyLhG9MesvZ7EiuxJ4Q3uFyw7LaNQXqfrYrkO7G9A%40mail.gmail.com
) centers around pid.#.Pgain pins, which were "IO" pins at that time and are
now "IN" pins.
The specific original problem is that writing this:
net estop-out charge-pump.enable iocontrol.0.user-enable-out
causes the power-on value of "charge-pump.enable" (which is TRUE) to be copied
to the signal "estop-out", where it remains until quite a long time later in
startup, when iocontrol finally writes FALSE to iocontrol.0.user-enable-out;
just how long depends on system load, because iocontrol is a free-running task,
not a realtime task.
I think it's important to fix the specific problem that affects
stepconf-generated
config files (possibly changing stepconf in the process), but also to re-visit
the algorithm hal_link() uses to decide when to copy a value from a pin to a
signal.
Here's the thought experiment I've been using for myself, and mentioned on IRC:
# (newsig rather than creating via net command, to show that a signal
# can also have an explicit initial value)
newsig S signed
sets S 1
# Note: assume pin PI is direction IN and power-on value 2
net S <= PI
# Note: assume pin PO is direction OUT and power-on value 3
net S <= PO
# Note: assume pin PJ is direction IN and power-on value 4
net S <= PJ
show sig S
Note that HAL threads are not started, so the function that updates PO has
never had a chance to run and drive PO's value.
The question is: What value should S show?
Old LinuxCNC (2.5.x) would show 1, because that value was driven onto S
by sets, and PO has never driven a new value onto S. Note that if the 'net'
commands are reordered, 2.5.x would always show 1.
Current LinuxCNC shows 2, because the value of the first pin (regardless
of direction) connected to the signal is copied to the signal, and PO has
never driven a new value onto S. Note that if the 'net' commands are reordered,
linuxcnc would show different values (2, 3, or 4).
I think it should show 3, because pin P0 is the pin that will drive
the signal, and its power-on value is 3. Note that if the 'net' commands are
reordered, this method would always show 3. Specifically, I think that the
condition
for driving the pin's current value onto the signal should be
if (( sig->writers == 0 ) && ( sig->bidirs == 0 )) {
so that, as long as the signal was not yet connected to any pin that could
potentially drive it, the value of the pin being linked is copied into the
signal. But I've revised my opinion about the best fix several times, so I'd
like to get others' thoughts on the matter.
Jeff
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
