Thanks for the link -- it helped a lot, though I'm still feeling just a little thick-headed. I'm intrigued enough now that I want to be sure I *really* understand it. I think the key sentence for me is: "The DAQ devices synchronize each DI signal to 80MHzTimebase, and then sends the signal to the change detectors." Here's what I *think* it means -- could you correct me where I'm wrong?
1. The "Sync" block passes its input (P0.0 or whatever other bit) through to its output on each active edge of the 80 MHz internal timebase. Any input-side changes that happen in between active edges are not passed through. Only the state at the instant of the active edge.
2. The result of all edge detectors are OR'ed together. (Only enabled edge detectors can produce a True output.)
3. ??? The "change detection" output becomes True. But for how long? Won't it stay True for at least a full 12.5 nanosecond period? Will it then need to go False for 12.5 nsec before it can go True again?
In other words, does the "change detection" output need to generate edges for edge-sensitive circuitry? Or does it just need to generate a state which will be latched/sampled by some other internal signal (such as perhaps the 80 MHz timebase)?
I'm really curious about this stuff because one of my prior apps involved creating a bunch of simulated digital logic subvi's (latches, timers, edge-detectors, one-shots, etc., most with separate inputs for Signal, Enable, Reset, and Trigger). Some of the customers' requirements led to some really tricky implementation issues. For example: the logic vi's must have a reset input. The reset input must be rising edge sensitive NOT high state-senstive. The reset functionality must be able to be tripped on consecutive clock cycles. Well, riddle me this: how do you create 2 consecutive rising edges with no falling edge between them?
Anyway, I was never able to effectively convince the customer that in many cases the edge-detection was not only unnecessary but actually a huge complication and detriment. The fact that the software must iterate in a loop and that the blocks execute in a sequence determined by dataflow made many of these digital states INHERENTLY synchronous. An additional level of edge-detection was not needed for synchronization, and actually produced many confounding dilemmas, such as the consecutive rising edge issue above.
But if the customer insists and the customer pays, well, what're ya gonna do? In the end, I was able to make the required behaviors possible though frankly, the complexity got so high it was quite difficult to wire several different "chips" together and predict exactly how it would all behave with some unusual input sequences. Even the stinkin' edge-detector wound up having: a Signal input, an Enable input, a Reset input (which was internally treated as edge-sensitive, not state-sensitive), an initial state input (defining the assumed "prior state" of the Signal input) and a boolean input controlling whether to use the initial state input on a reset. Internally, there was also a First Call primitive that acted like a forced reset but which always used the initial state input. And the logic made it possible to produce a True edge-detect output on the very first call, or on the same call that a reset was occurring, or the first call with Enable true after having been reset while Enable was False, and so on.
It's exhausting just thinking back on all the scenarios. And that's just for an edge-detector that I'd normally do in about 30 seconds with a single shift register. Maybe a couple minutes to add a "First Call?" primitive and make a text icon. But that's why I'm intrigued by the exact details of the change-detection behavior on the M-series boards. Knowing exactly which parts of the circuit are edge-sensitive and which parts are state-sensitive can sometimes matter.
-Kevin P.
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
![Ryan_V[DE]](http://forums.ni.com/attachments/ni/170/152606/1/V-ferret.jpg "Ryan_V[DE]"){kind=avatar}
