LabVIEW
Trigger an Event from I/O
Solved!
TAmbriole wrote:Is there a better way to pull the relays low for a longer period of time than the several writes that I am running? I would guess that is somewhat processor intensive as well. I just found that if I only had a single write, then the relay was not pulled low long enough for the program to catch the event.
I'm guessing what you mean is the sequence visible in for example the start case, with a bunch of consecutive single point writes having the same value (e.g. false)?
If so, you have a couple of choices. Given what seems to be a fair lack of precision (not a problem, just a comment) on the duration of the false signal, you can use a flat sequence structure (this is one of the few good times to use one) to place an error wire in on the left side and out on the right, with a Wait (ms) node inside the single frame. This effectively creates a Wait function with a pair of error wires to enforce ordering.
If you had a situation in which the timing was more specific, or you had a more complicated pattern, you might consider adding a DAQmx Timing node to set a sample rate and then wiring an array of booleans or a digital waveform to the DAQmx Write function. (I'm writing from my phone but I think both are possible - check the valid inputs to the Write with the digital output). Then you could have an array with the same values you currently have, but would know how long they would take per write.
@TAmbriole wrote:
Interesting. I suppose I assumed that would be done more so programmatically than via hardware. I would think that it would simply be a matter of reading the port and assigning a Boolean value based on the value of the reading. Said Boolean would trigger an event called Testing, Pass or Fail.
If you have the Read nodes in the loop (outside of the event structure) then they're being called every iteration, most of which probably end with the timeout case for the event structure. This is a polling system, not event driven (even though the start button and so on are using events).
At present, effectively you are simply reading the port and assigning a boolean value. It's just that it requires time to read the port (but not much - did you already try moving the Create Virtual Channel node outside of your while loop and just wiring the purple Task wires into the loop?). The Read nodes need to remain in the while loop - you want to read them every iteration to update the indicators, even if you're updating them with an unchanged value. Without some hardware support, you probably can't avoid polling, but one value every 100ms as you described (or even 3) shouldn't be a problem with cpu on anything even vaguely modern I wouldn't have thought. If you're still having problems even with the Create nodes outside of the loop, then it's probably something else eating your cpu time. I'll check again tomorrow morning.
Good luck!
