Yes maybe you are right, I finnished my coffe and should continue with some real project in garage so no time for more discussion.
On Thu, 28 Jul 2016 12:36:49 -0500 Jeff Epler <[email protected]> wrote: > On Thu, Jul 28, 2016 at 06:12:07PM +0200, Nicklas Karlsson wrote: > > Reading a unconnected pin should result at least in a warning. I guess > > this could be checked beforehand as soon as linuxcnc is started. > > This is a change that would break virtually all existing HAL > configurations. For instance, run configs/sim/axis/axis.ini. In > whatever branch my current tree is in, only 43 out of 393 IN pins are > linked. > > We had, and still have, simple rules that gives unconnected pins > a well-defined value: It is the value of the pin's "dummy signal". This > "dummy signal" can be driven with a value at several times: > > * Since the original design of HAL: > * Automatically driven to zero / FALSE at pin creation time > * Explicitly driven to a default value by an assignment in the > component > between pin creation time and the call to hal_ready() > * Explicitly driven to an appropriate constant value by explicit > "halcmd setp" after hal_ready() but before "halcmd start" > > * Since the change to hal_link() / hal_unlink() in 2.6: > * Implicitly driven to the current (or at least recent[1]) value of > the previously-linked signal > > I believe the rules for a never-connected pin are simple to explain and > they are good because they > > * Eliminate the need for null pointer checks before pin dereference > (more because of the cognitive load for component developers, not > because of the number of cycles burned for null pointer checks) > * Allow components to give good default behavior (for instance, a > mode pin can default to a mode that is expected to serve a > plurality of users; a velocity pin can default to "no velocity", > and so forth) > * Allow configuration to a different, but constant, value without > the need to introduce a separate "constant" component and a signal > to carry that constant to the component with the input pin > > Making pins NULL by default until linked to a signal means "halcmd setp" > can no longer be used to give a pin a value, and means that for even a > very simple linuxcnc configuration about 350 additional signals are > needed, which in turn would need to be driven by 350 new "constant" > component instances. Not to mention the number of lines of component > source to be rewritten with additional null pointer checks. > > Jeff > [1] Since hal_unlink is not executing in realtime, there's no guarantee > that the signal value read at one point in hal_link is the value still > driven onto that signal at the moment it actually points the pin back to > its dummy signal > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
