11-17-2021 02:18 PM - edited 11-17-2021 02:19 PM
Hi all,
I am using NI USB-6212 to receive analog input from the Keyence IR sensor.
In my program, I would like the solenoid to active for 3 seconds after the temperature reaches a certain level or when the time reaches a preset time. The solenoid is connected to the Dev1/port0/line0 of the DAQ.
One of the spot where the solenoid would be activated is when the time has elapsed for 5 second started from the beginning. (The solenoid will stay on for 3 second before it turn off)
As shown in the video attached, however, there is a lagging issue in the analog in during the time where the solenoid is activated.
So I would like to see how to solve this lagging issue. In order words, how do I synchronize Analog in and Digital out so that the analog in and digital out can be happened at the same time ?
Also, is it a hardware problem ?
Thank you all very much!
Please focus on the area circled in RED in the video.
11-18-2021 04:19 PM
How can we understand what you did (that didn't work) if you don't show us what you did? Attach your code. Do not send a "picture" of your code, send the actual VIs themselves. Be sure to tell us which version of LabVIEW (and whether 32-bit or 64-bit LabVIEW) you are using.
Bob Schor
11-19-2021 05:12 PM
Hi Bob,
I apologize for the inconvenience.
I am using LabVIEW 2021 of 32-bit.
The VI is simplified and attached along with the video that shows the lagging problem.
Thank you all for your advice, and I really appreciate with your help 🙂
11-19-2021 05:45 PM
You would need to attach the code in preferably LV 2016 to cover more audience. Very few of the forum members use the LV2021.
11-19-2021 10:16 PM
Here is Kahn's code saved as LabVIEW 2016.
Bob Schor
11-22-2021 10:13 AM
Thank you!
11-22-2021 10:43 AM
Now, to explain why you have the 3-second lag is expected as per your implementation (think DATAFLOW!)
Once the 5-second timeout occurs in the top-level loop, your solenoid control section runs for 3-second, during this time, your execution is stuck doing the solenoid work and cannot capture the temperature during that time.
Now, to fix this, you have to redo the whole structure and eliminate the use of DAQ Assistant.
11-22-2021 11:39 AM
@santo_13 wrote:
Now, to explain why you have the 3-second lag is expected as per your implementation (think DATAFLOW!)
A "slightly Advanced" topic, but crucial to understanding and using LabVIEW ---
I usually teach "The Three Laws of DataFlow". Law 1 -- Data must be present on every Input to a Structure or Function for it to run. Law 2 -- Data are not available at any Output from a Structure or Function until it exits, and then data are present on every output. Law 3 -- within a Structure or Loop, the order of execution of items not connected (output of one to input of another) cannot be determined. Law 3 can be paraphrased as "LabVIEW does its best to process "disconnected" code fragments in parallel (or simultaneously, at the same time).
Here's an example -- you have a While Loop that captures a signal for three seconds, but does nothing else with it, and repeats until you say "Stop". You have a second While Loop that, if given three-seconds of a captured signal, processes it, displays it, saves it to disk, etc., a process that may take 2 seconds. Let's say that the first Loop's 3-second signal results in 3000 data points (you are sampling at 1 kHz, for example), and the second loop's "captured signal" is also 3000 data points.
Start both loops running -- what will happen after 6 seconds? Because the two loops are "disconnected", the Third Law says they will run "independently' and "simultaneously", so Loop 1 will loop 6/3 = 2 times, while Loop 2 will loop 6/2 = 3 times. Now, Loop 1 is a Data Acquisition loop -- DAQ Loops are almost always "clocked" by DAQ Hardware, and (if coded properly) spend 99% of the time just waiting for the Hardware to acquire and present the data. This leaves the "free time" for any other Loop (like Loop 2, doing Data analysis) time to "share" the CPU.
LabVIEW has mechanisms to "almost-instantaneously" transfer data (without overt Wires!) from one Loop to another. Have you learned about any of these?
Again, the secret of Success here is what I've called the Third Law of Data Flow, removing code dependencies to let different parts of the Program process different "chunks" of Data at the same time. Here Loop 1 is "producing" chunks of data, and Loop 2 is "consuming" these chunks -- I'll bet if you do a Web Search for LabVIEW, Producer, Consumer, you might find some reading of interest.
Bob Schor
11-29-2021 04:36 PM
Thank you guys for all the comments.
I will try to do more readings and redo the code by thinking more on the data flow.
I'm sure I will definitely have questions along the way, so I will keep updating with you all.
Thank you once again for your help and being patient with me 🙂
12-03-2021 04:15 PM
It works after I use the Producer and Consumer Structure, thank you all very much!