On Thursday 09 October 2014 10:23:30 John Kasunich did opine And Gene did reply: > On Thu, Oct 9, 2014, at 09:46 AM, John Prentice (FS) wrote: > > Seb - thank you > > > > HAL IO pins are strange and apparently very rare beasts which don't > > map easily in my mind to the wire -- signal analogy. > > To extend the wire-signal analogy, I think of I/O pins as tri-stateable > signals. > > They have two possible uses: > > 1) as a one-wire handshake, where component A asserts the signal to > request an action, and component B clears it when the action is done. > > 2) to allow multiple components to drive a signal signal. > > #1 is the index-enable case. It could be replaced by a two-wire > handshake, but motion and all the encoder drivers would need to make > the change at the same time, and it would require changing existing > configurations. > > There is one caveat to that replacement. The existing one-wire > handshake works even across thread boundaries. In other words, a > component running in one thread (or even in user space) can request an > index capture from an encoder driver running in a faster thread, and > be assured that the encoder driver will capture the index position > once and only once. That is because the very act of acknowleding the > request also clears the request. > > If the handshake was split into two wires, a request and an > acknowledge, then the requestor MUST see the acknowledge and remove > the request before a second index pulse occurs, or the index position > will be captured twice. In our normal configurations, the requestor > is motion, and it is running in the same thread as the encoder driver, > so this doesn't matter. But it is very handy to be able to test an > encoder by manually setting the request and seeing that when an index > pulse occurs the request is cleared. If doing things manually, there > is a very good chance that two (or more) index pulses will arrive > before you manually clear the request. > > #2 is not currently used by LinuxCNC to my knowledge. One example > that I had in mind for it was a FAULT or ESTOP signal that could be > driven by any of multiple components to force a shutdown, without > having to OR together a bunch of individual signals, one from each > module. This is more like an open-collector than a tri-state output. > Each component that might detect a fault would drive its I/O pin to > the "faulted" state when a fault condition exists, and would not drive > it at all otherwise. One component would be responsible for driving > the signal to the "not faulted" state only one time when the user > attempts to reset the fault.
Tongue firmly in cheek, there is something terribly wrong here, John. I understood this perfectly on the first read! The above text should be incorporated into the Integrators Manual pdf's as it is not explained as clearly as you have done above. > > > If we review HAL (and its documentation) I wonder if IO pins should > > be deprecated. A two signal handshake would seem more transparent > > and allow general interconnection of components rather a special > > purpose connection such as is used between encoder and axis for > > resetting counts. > > > > Thoughts anyone - perhaps I have totally missed the point. > > > > John Prentice > > > > -----Original Message----- > > From: Sebastian Kuzminsky [mailto:s...@highlab.com] > > Sent: 08 October 2014 22:25 > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] In/Out pin on Hostmot2 Encoder component > > > > On 10/8/14 3:18 PM, John Prentice (FS) wrote: > > > Can anyone give an example snippet of HAL to explain how one might > > > exploit this. I cannot wire a signal to set it True (not > > > surprisingly as it is an output). I must be missing something > > > obvious here and need > > > > guidance. > > > > Look at the hm2-servo sample config: > > > > http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=configs/by_int > > erface/ > > mesa/hm2-servo/hm2-servo.hal;h=50a630a0ab84497fbef5c2927a20acfa3510f > > a56;hb=r efs/heads/master#l231 > > > > > > > > -- > > Sebastian Kuzminsky > > Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
