01-12-2021 04:04 PM - edited 01-12-2021 04:07 PM
Hi Friends,
I have a USB 6002, a multifunctional device having analog output (AO) and counter input , and would like to use it as a time source (via edge counting) for a timed loop to avoid Windows OS interruption to a while loop. I found that such OS interruption to a while loop occurs occasionally when a while loop runs at 20-50 iterations/s, the loop contains a VISA reading data from a device register. The interruption is normally approximately less then 2 seconds, posing the reading data for the short time, and then the reading data can resume by itself. The VI with the loop is set at the highest priority to ensure the data acquisition. It is a annoying issue to my project.
My point is to send a square wave signal via a USB 6002's analog output to the counter PFI0 or PFI1, the counter then sends edge counting bits to a DAQmx time source for a timed loop so that the loop can run at specified number of iteration.
I tried around and obtained an error. A simplified VI is attached, which included the error message and the USB 6002 channel description for your reference.
Can some one help me with the settings?
I will post this at different location for a broader exposure, e.g. LabView and counter/timer
Thanks,
Gu
01-12-2021 07:07 PM
@edmonton wrote:
Hi Friends,
I have a USB 6002, a multifunctional device having analog output (AO) and counter input , and would like to use it as a time source (via edge counting) for a timed loop to avoid Windows OS interruption to a while loop. I found that such OS interruption to a while loop occurs occasionally when a while loop runs at 20-50 iterations/s, the loop contains a VISA reading data from a device register. The interruption is normally approximately less then 2 seconds, posing the reading data for the short time, and then the reading data can resume by itself. The VI with the loop is set at the highest priority to ensure the data acquisition. It is a annoying issue to my project.
My point is to send a square wave signal via a USB 6002's analog output to the counter PFI0 or PFI1, the counter then sends edge counting bits to a DAQmx time source for a timed loop so that the loop can run at specified number of iteration.
I tried around and obtained an error. A simplified VI is attached, which included the error message and the USB 6002 channel description for your reference.
Can some one help me with the settings?
I will post this at different location for a broader exposure, e.g. LabView and counter/timer
Thanks,
Gu
I don't think that approach is going to work, since ultimately Windows will be the one to control the timing. The problem is more likely an issue with your code.
01-13-2021 05:08 AM
Further, I doubt that any USB devices support the use of counter signals as timing sources for a Timed Loop. (Just checked your posted code -- yup, sure enough, that error confirms that your device doesn't support such a usage.)
You also probably need independent parallel loops. One for VISA communication to an instrument, another for your AO. And I'll venture a guess that you might be running the AO task in unclocked, unbuffered, on-demand mode. You can get a much more precise and reliable update rate by configuring it as a hw-clocked, buffered task. Try out one of the corresponding shipping examples to see how it's done.
-Kevin P
01-13-2021 10:39 AM
Hi Kevin,
Thanks. I will check my code carefully.
Gu
01-19-2021 07:21 PM
Hi Kevin,
It has been for a while, I have not solved the issue. I found a NI web page talking about this topic.
https://zone.ni.com/reference/en-XX/help/370469AP-01/lvdaqmx/mxcreatetimingsource/
Regards,
Gu
01-20-2021 07:01 AM
I honestly don't know where to find reference info about which hardware devices can or cannot use their timing signals as a Source signal for a Timed Loop. I just have it in mind from general experience and accumulated knowledge that NO USB devices will support that nor any cDAQ system without a CPU in the chassis.
But another bit of experience is that a pretty significant majority of questions that show up here about Timed Loops are solved with an answer like, "you don't need it, there are other (usually better) ways to achieve your end goal".
Many times, it's a user trying to time their DAQ sampling with their loop timing, rather than using the hardware clocking and buffering that the devices are really good at.
So what code do you plan to run inside this Timed Loop? Do you realize that even Timed Loops won't guarantee iteration timing under Windows?
-Kevin P
01-20-2021 11:03 AM
Hi Kevin,
Thank you for your comments. The reason I am looking for using Daqmx create timing source is that I have an analog-to-digital conversion device that is not hardware timed. I have to use a loop to read data via its USB port. The reading data poses for a short time occasionally for less than 2 seconds and then resumes by its self thereafter, I believe the interruption is caused by operating system.
Regards,
Gu
01-20-2021 12:55 PM
The USB-6002 that you mentioned *CAN* be hardware-timed for both analog input and output. Do you have a reason for not doing so? If you don't know how, start by exploring the shipping examples for continuous voltage input and output.
And maybe you should post your real code. Windows *can* interrupt your app for a second or two, but if the symptom is reproducible and only occurs when you run your app, guess what? It probably isn't the fault of Windows -- the delay is more likely due to something in your code.
-Kevin P
01-20-2021 01:22 PM
HI Kevin,
The device I have is already digital numbers output, analog to digital conversion is done inside the device. There is no connection point on the device for USB 6002 analog input.
For the code, I have discussed it with the device manufacture and confirmed that my reading data program has no problem. It is just a VISA read port.
Regards,
Gu
01-20-2021 06:20 PM
There are very few device manufacturers whose LabVIEW code (or opinions about LabVIEW code) I would want to rely on. Further, a lot of the smaller operations (as well as some big ones) produce pretty lousy serial protocols and documentation thereof as well. In my experience, solid serial protocols with thorough and accurate documentation are a rarity.
Maybe yours is one of the rare really good ones, but I wouldn't start by counting on it. If you can post your real code, either I or someone else has a better chance to diagnose possible problems.
The only other thing I can think to suggest is that you switch your mindset about these VISA reads. Instead of trying to *control* the timing of a loop that reads data across a serial connection, switch over to *measuring* the time when that data is received.
This is what I typically do with my instrument handling loops. I find that trying to control timing while gathering data across a communication bus tends to be a losing battle. Instead I just tag each read with a current timestamp. I can still get a good data vs. time relationship, I just have to accept that the time intervals won't be constant.
-Kevin P