Am 16.03.2014 um 23:48 schrieb Peter C. Wallace <p...@mesanet.com>: > 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.
I see the problem, but not sure this is the issue when using an IO pin as a changeable parameter the basic issue I see is: if you _could_ connect two IO pins without an intervening signal, you would get undefined behavior because it is unspecified which of the two 'O's gets precedence now you cant do that, you have to go through a signal, which gets precedence over the pin value, meaning the signal destroys the pin default value, which is counterproductive in the 'pin as parameter' use case one option would be to add a pin attribute (valid for HAL_IO pins only) say HAL_DRIVING_VALUE which determines value resolution during linking - basically it says this pin's value has priority over others linked to it: - if there is one HAL_IO pin with HAL_DRIVING_VALUE set in a 'net' statement, it will determine the value of the signal linked to that signal (and consequently of all the other HAL_IO pins) - it is an error to link more than one HAL_IO pin with the HAL_DRIVING_VALUE to a signal. This flag is considered only at 'net' time. This would retain the 'compiled in default value' requirement, and take care of the 'netting destroys the pin default' issue would that help with your problem too? - Michael >>> >>> 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 >>> jmkasun...@fastmail.fm >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> Emc-developers@lists.sourceforge.net >>> 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 >> Emc-developers@lists.sourceforge.net >> 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 > Emc-developers@lists.sourceforge.net > 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
