Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
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. 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=154622311iu=/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=154622311iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
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=154622311iu=/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=154622311iu=/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
Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
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=154622311iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
John, thank you for your elaboration. Two points interleaved below: snip To extend the wire-signal analogy, I think of I/O pins as tri-stateable signals. I don't really get this analogy as there is also a memory hiding somewhere for when everyone it tri-stated. It feels more like a wire with some sort of latch with weak pull-up (and perhaps pull-downs?) on its output. I.e. it remembers the state imposed on it by anything bussed onto it when the driver turns on a strong 3-state buffer 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. It was actually trying to do a manual test that got me into this trouble. I think one needs a special comp with an IO pin to connect to the index-enable to something like a pyVCP button. Is the fundamental concept we want for REQ not an edge-input? The receiver latches this and clears the latch when the action (e.g. count reset by the index) is performed. The requester then has to see an ACK signal, deal with the data, and eventually drop and re-raise the REQ. #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. This wired OR would look neat in the HAL but unless faulting pins (e.g. limit switches) are to be forced to use the mechanism we need an understanding of what an IO pin connected to an input pin does (c.f. a tristated output connected to a TTL input without pull-ups/pull-downs would have an indeterminate value). The limit switch example seems to require making the GPIO pins of Hostmot2 be IO in case they are to be wire-ORed. This seems much more complicated that a multiple input OR - which is perhaps why it is not currently used. Anyhow I think I must code a one-shot, whose output is an IO, to exercise the encoder index-enable input. Thanks again John Prentice -- 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=154622311iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
On 9 October 2014 19:15, John Prentice (FS) j...@castlewd.freeserve.co.uk wrote: Anyhow I think I must code a one-shot, whose output is an IO, to exercise the encoder index-enable input. Is http://linuxcnc.org/docs/html/man/man9/tristate_bit.9.html any help? -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- 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=154622311iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
On Thu, Oct 9, 2014, at 02:15 PM, John Prentice (FS) wrote: John, thank you for your elaboration. Two points interleaved below: snip To extend the wire-signal analogy, I think of I/O pins as tri-stateable signals. I don't really get this analogy as there is also a memory hiding somewhere for when everyone it tri-stated. It feels more like a wire with some sort of latch with weak pull-up (and perhaps pull-downs?) on its output. I.e. it remembers the state imposed on it by anything bussed onto it when the driver turns on a strong 3-state buffer The analogy is getting stretched almost to the breaking point, but: Consider a tri-state signal with no pull-up or pull-down resistor. All pins connected to it are truly infinite impedance when off. All inputs likewise have infinite input impedance. The wire has some capacitance such that when not driven it retains its current value. It was actually trying to do a manual test that got me into this trouble. I think one needs a special comp with an IO pin to connect to the index-enable to something like a pyVCP button. Why not just type sets index-ena 1? That command writes to the signal one time, which is exactly what you want. Is the fundamental concept we want for REQ not an edge-input? The receiver latches this and clears the latch when the action (e.g. count reset by the index) is performed. The requester then has to see an ACK signal, deal with the data, and eventually drop and re-raise the REQ. Yes and no. As normally used by LinuxCNC, an edge-sensitive request would probably work. It is actually a mix of edge and level - the level still matters so that the ACK line works correctly. It works like this: in idle state, REQ and ACK both 0 master sets REQ slave sees REQ change from 0 to 1 slave does whatever it does and makes data available slave sets ACK master sees ACK go from 0 to 1 master reads data master clears REQ slave sees REQ go from 1 to 0 slave clears ACK master sees ACK go from 1 to 0 back in idle state, ready to start again Note that the master cannot clear REQ until it sees ACK go true, since it has no way of knowing if the slave saw the edge. Remember that the master and the slave might be in different threads, either one might run hundreds of times before the other runs once. For the same reason, the slave can't clear ACK until it sees REQ go false, because until then it doesn't know if the master saw the ACK edge. The old way works like this: in idle state, REQ is 0 master sets REQ slave sees that REQ is 1 (prior state doesn't matter) slave does whatever it does and makes data available slave clears REQ master sees REQ go from 1 to 0 master reads data back in idle state, ready to start again Simpler, fewer steps, but still robust, even in the case of master and slave in different threads. This wired OR would look neat in the HAL but unless faulting pins (e.g. limit switches) are to be forced to use the mechanism we need an understanding of what an IO pin connected to an input pin does (c.f. a tristated output connected to a TTL input without pull-ups/pull-downs would have an indeterminate value). If you consider the signal has capacitance model, then a signal driven by 10 tri-stated outputs and connected to any number of inputs will hold whatever value it has until one of those tri-stated outputs is enabled and drives it to a new level. The initial state of a brand new HAL signal is zero. If I was designing a machine, that would be the faulted state, and I would have a reset function (a button or whatever) that would write a 1 to the signal ONCE when the user presses the button. The limit switch example seems to require making the GPIO pins of Hostmot2 be IO in case they are to be wire-ORed. Nope. There is nothing special about GPIO pins. Any pin could be used in this way, by running it through the tri-state component. The pin signal would actually be used to drive the enable of the tri-state component. The input of the tri-state would be tied either high or low. When you hit the limit, the tri- state turns on and drives either a 1 or a 0 onto the output. Note: I believe there is also a floating point tri-state component, and it can be used to make an analog multiplexor in much the same way as the boolean tri-state can do an open-collector fault line. Just enable one of N tri-state components. This seems much more complicated that a multiple input OR - which is perhaps why it is not currently used. Perhaps. Anyhow I think I must code a one-shot, whose output is an IO, to exercise the encoder index-enable input. Nope. Just use sets. Or if you must have a GUI thing, connect a VCP button to the enable input of a tri-state, and setp the input to 1. Regards, John Kasunich jmkasun...@fastmail.fm -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0
Re: [Emc-users] In/Out pin on Hostmot2 Encoder component
Andy and John Thanks TRISTATE_BIT looks great for the job of kicking an encoder index-enable. John Prentice -Original Message- From: John Kasunich [mailto:jmkasun...@fastmail.fm] Sent: 09 October 2014 19:58 To: emc-users@lists.sourceforge.net Subject: Re: [Emc-users] In/Out pin on Hostmot2 Encoder component -- 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=154622311iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
