06-04-2012 03:23 PM
Hello.
I have a piece of machinery that my system is connected to. Every time it reaches a proximity sensor (It's a reciprocating unit), I need to do a single pulse of 5v out of my analog output. It has to be fast, it has to stop until the sensor is reached again, and it can't stay 'on' for long.
I've attached my VI. I'm using a voltage input via DAQ assistant, routed through some logic to produce a 'true' boolean every time that sensor is reached, and that boolean is connected to a case structure with voltage out tasks created in DAQmx.
My problem is that the machine won't reverse while the case is still true and there's still the 5v being called by the true case on the case structure. It has to pulse, then stop, then be allowed to come back when the proximity sensor is reached again. As it is now, the machine reaches the prox and then the whole system stops, as the 'true' condition on the case structure, and subsequent voltage output, remain high.
I've attached the VI and heirarchy as well.
I've tried a few different things here, as well as just using a DAQ assistant with N samples, but that would just retrigger when the loop repeats anyway.
I'd love to sit and bang my head against this til I get it, but I'm under a time constraint. Help!
Solved! Go to Solution.
06-04-2012 04:20 PM
Ralph, without knowing the exact DAQ card that you are using, it is difficult to give you the best solution. If you want to continue with the solution that you currently have, try adding a shift register to the outer while loop to track the previous value of the boolean. In this way, we can keep multiple values that are above the threshold from causing multiple pulses. Next add a time delay after the DAQmx Write, then add another DAQmx Write to set the output back to your low value. Remove all code from your "false" case. See attached VIs. Please let us know what model of DAQ card you have as we may be able to do something clever like a retriggerable pulse train if your card can support it.
Charles Chickering
06-04-2012 04:31 PM - edited 06-04-2012 04:32 PM
Try something like this. Set the input to the "Time Delay" function to be however long you want your pulse to be (within reason). You did not specify a value for "fast". I initialize your analog output line to 0...it's a good idea but it's up to you whether you want to do that or not.
06-04-2012 04:50 PM
First you don't need to convert your dynamic data in your subvi, since you are using the numeric data. It will only give you one element, so what's the point of it.
What does "it can't stay on for long" mean? How long do you want it to stay on. We can't define that parameter for you. You have to know this.
Turn the pulse on when a True is present on the output of your sub-VI. Enable an Elapsed Time Express VI like the attached. You may need to play around with this to get the timing right. You will need to consider the 50ms delay as well. The timer starts on the next iteration, so there will be at least a 50ms delay built into this. The express VI is set to 100ms currently.
06-05-2012 06:36 AM
I suppose 'it can't stay on for long' really means 'just long enough to trigger the relay' which is probably somewhere around 50ms.
The card is PCI-6221.
I think that example with the time delay may work, but won't that cause it to keep returning the true condition and renewing the state, regardless of delay?
06-05-2012 07:32 AM - edited 06-05-2012 07:33 AM
Ralph@NES wrote:
I think that example with the time delay may work, but won't that cause it to keep returning the true condition and renewing the state, regardless of delay?
What example are you referring to? Three people have recommended the use of a time delay, including myself.
06-05-2012 08:31 AM
06-05-2012 12:10 PM
Did you code up what I showed you in my earlier post and actually try it? It would appear you didn't.
Since you actually had your conditions reversed (according to your last post), modify my code as follows:
Outside the loop, initialize your analog output channel to 5V.
In the "True" case of your case structure, wire a "0" (or "1", or whatever) to the first "DAQmx Write" function. Wire "0.05" to the "Time Delay" function. Wire "5" to the second "DAQmx Write" function.
In the "False" case of the case structure, just run the task and error wires through.
Your analog output will start at 5V. When your logic subVI returns a "T" value, the "True" case will execute and you'll get your pulse. When your logic subVI returns a "F" value, your analog output will just stay at 5V.
Create and clear your DAQmx tasks outside your loop, as I have shown.
I don't understand why you're confused when you've been given three solutions...?
06-05-2012 04:19 PM
Diane,
I ended up trying a few different combinations of the options provided me in this thread, although I have to admit I did all of them with all the task work in the case structure.
I ended up not using shift registers (Shift registers seemed to make it so that there needed to be a double 'hit' of the 5v from the proximity switch in order to reverse the motion). Ended up getting basic functionality, but either I have latency somewhere in the circuit or having all the task work in the case structure caused issues.
The machine is responding, just peculiarly (Seems like a big pause between direction switching) and not quickly. I suppose I will give it a go with putting the task work outside the loop and see what I get.
By the way, the 'Really, really confused' line is my signature as it sums up my state of mind in 2006, when I first started, and to this very day.
06-05-2012 05:41 PM
Ah, I didn't realize that your "really, really confused" was your signature line.
Can you post your code? I'm wondering how often your loop iterates. If your logic subVI executes slowly, you'll obviously have a slow machine response. Also, you'll probably want a small time delay in your "False" case so that you don't wind up with a greedy loop. Greedy loops, which take up the entire CPU, will also cause problems.
The task creation / clearing does need to take place outside your loop. Creating and clearing a task every time you run it is extremely inefficient and has been known to cause memory leaks, leading to a degradation in performance.