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=154622311&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
