I started to write a "quick" reply, but the deeper I look
the more complex it gets - and I have to be somewhere.
I'm going to post this partial reply now and hope to get
back to it later...
On Thu, Jul 21, 2016, at 11:00 AM, Jeff Epler wrote:
snippage
>
> 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.
This is a key point.
The "default" values mentioned in that commit message
were never intended to be defaults. The struct member
name is "dummy", not "default".
HAL pins are nothing more than C pointers. Once connected,
they point to the value, which is part of the signal struct.
Since HAL was intended to be simple, clean, and fast, I didn't
want to force every pin reference to do NULL pointer checks
to handle unconnected pins. So an unconnected pin still needs
to point somewhere. The "dummy" field is that somewhere.
HAL pin pointers must never be NULL.
When HAL component code reads a pin, it reads from the
pointer. If the pin is connected to a signal, the component
reads the signal value. If the pin is unconnected, it reads
the dummy value.
When a HAL component code writes a pin, it writes to the
pointer. If the pin is connected to a signal, the write goes
to the signal value. If the pin is unconnected, the write
goes to the dummy value.
The component code neither knows nor cares if the pin is
connected.
Sorry if the above is already common knowledge, but knowing
the implementation makes the behavior easy to understand:
"sets" ALWAYS modifies the value of the signal. If the signal
has no writers, the "sets" value will persist. If there is a
writer the value will be over-written by that writer sooner
or later.
"setp" modifies the target of the pin pointer. If the pin is
connected, it modifies the value of the signal, just like a
"sets". If the pin is unconnected, it modifies the dummy
value.
> 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
We need to think about input and output pins separately (bidir pins
too, but they are a mix of both and come later)
For all types of pins, I like to think of components as if they were some
kind of hardware. Many people have experience with hardware components,
and the "principle of least astonishment" applies. HAL components should
behave like regular hardware would, when possible.
For INPUT pins: think about the inputs of say a stereo amplifier.
Typically the input impedance is very high - the input doesn't drive
anything, it is driven by other things. However, there is usually a
weak pull-down to ground so an unconnected input doesn't go
floating off.
For an unconnected input, ideally the value would be STARTVALUE.
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
--
John Kasunich
[email protected]
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
