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. > > 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_interface/ > mesa/hm2-servo/hm2-servo.hal;h=50a630a0ab84497fbef5c2927a20acfa3510fa56;hb=r > efs/heads/master#l231 > > > > -- > Sebastian Kuzminsky > > ---------------------------------------------------------------------------- > -- > 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 > > > ------------------------------------------------------------------------------ > 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 -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ 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
