On Sun, Mar 16, 2014, at 06:16 PM, Michael Haberler wrote: > > 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 > > 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.
I was overly broad in the "only legitimate" statement above, which I acknowledged in my next message. I'm with Andy in believing that PID gains should not be I/O pins, they should be IN pins. Perhaps I should have said "I don't believe that PID gains are a legitimate use of IO pins". In any case, I was not defending the historical decisions, I was simply trying to provide background. In fact, I said that I think parameters were a mistake. A couple messages ago I wrote: >> The distinction between pins and parameters >> was my fault - at the time I thought it was >> useful, but in hindsight not so much. We started resolving that mistake in 2007, when the PID gain parameters were changed to pins. At that time we discussed the idea of completely eliminating parameters from HAL. I don't know if a valid use case was presented for keeping them, or if it was a matter of inertia and the work needed to turn them all to pins. In any case, we still have both parameters and pins. Several message ago, Chris Morley said: >>> Why not change all params so they are read or write (not rw) and can have >>> signals connected to them. And you (Micheal) said: >> that is what I'd suggest too Two points about that: 1) the discussion isn't about parameters - the PID gains were changed to pins 6 years ago. 2) "can have signals connected to them" is pretty much the definition of a pin (as opposed to a parameter). I agree with Chris (and you) - I think all params should be changed to pins, after a discussion and good search to make sure there aren't any use case that would benefit from keeping params. > Fact is: there are valid use cases which are not covered by the historic HAL > design, and Agreed. Please, in plain language, exactly what is the use case we are discussing? As I understand it, the original problem posted by Andy is: 1) there is a PID block 2) he wants to hook a scale widget to it for tuning 3) the scale widget has an OUT pin 4) the PID gain is an I/O pin 5) halcmd won't let you connect them. As the thread has progressed, it has changed a bit. I think it is something like this now: 1) there is a PID block 2) it's gains have been set to some non-zero value, either by compiled in defaults or setp 3) someone connects a tuning GUI widget to the gain 4a) the gain becomes zero, OR 4b) the gain becomes whatever the widget default is both 4a and 4b are undesirable, since both entail sudden changes in the gain. If I've been following correctly, the desired behavior is: 4c) the tuning widget presets itself to the current value of the gain and then allows you to change it Is my understanding of the use case correct? In one message you wrote this: >> I'm lukewarm about instantaneous 'parameter' pin changes caused by linking >> to a signal - nasty surprises possible. I agree - as stated above, 4a and 4b are undesirable for that reason. > I am less interested in discussing the past, rather a possible future > approach, which I cannot discern yet from contributions so far. I made a proposal in my last message: >> 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. That is a clear, precise, unambiguous proposal. I could code it in an hour (if I had a current git checkout and dev system set up.) Its behavior can be easily understood, and we can discuss any possible bad side effects here before we make the change. It would ensure that any non-zero value given to the gain in step 2 above would propagate to the signal in step 3 above. Whether the widget uses that value to preset itself as in step 4c is up to the widget designer. In this exchange, I think Andy and Micheal were talking past each other: On 16 March 2014 13:36, Michael Haberler <[email protected]> wrote: >> well in that case a HAL widget like a scale.with an IO pin is the way to go Am 16.03.2014 um 14:52 schrieb andy pugh <[email protected]>: >> Given that the PID component never changes its own gains, I think that >> the switch to IO pins was a mistake, pure and simple. On 16 March 2014 14:15, Michael Haberler <[email protected]> wrote: >> Sure - with the consequence that you cannot connect a modified scale with >> an IO pin to the pid comp and have the proper semantics for initialisation >> of the scale with the current value as used by pid I agree with Micheal: The scale pin certainly can be IO, if the scale is intended to read the current value and preset itself to that value. I agree with Andy: The PID gain should not be IO - the PID module doesn't set it. I disagree with Micheal: There is nothing that prevents a scale widget's IO pin from being connected to a PID gain that is an IN pin. The thread started after trying to connect a scale widget's OUT pin to a PID gain that is an IO pin. Changing the PID gain from IO to IN would allow either the existing scale or Micheal's new ScaleIO to be used. The latter would be able to get the prior pin value, if my proposal to copy dummy to signal on first link were adopted. -- 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
