LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using digital edge counting as a time source for a timed loop

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.

 

edmonton_0-1610488999770.png

 

 

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

 

0 Kudos
Message 1 of 12
(2,631 Views)

@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.

 

edmonton_0-1610488999770.png

 

 

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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 2 of 12
(2,598 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 12
(2,570 Views)

Hi Kevin,

 

Thanks. I will check my code carefully. 

Gu

0 Kudos
Message 4 of 12
(2,559 Views)

Hi Kevin,

 

It has been for a while, I have not solved the issue. I found a NI web page talking about this topic. 

DAQmx Create Timing Source (VI)

https://zone.ni.com/reference/en-XX/help/370469AP-01/lvdaqmx/mxcreatetimingsource/

It doesn't mention which hardware can support this application.

Regards,

Gu

0 Kudos
Message 5 of 12
(2,466 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 12
(2,457 Views)

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 

 

 

0 Kudos
Message 7 of 12
(2,448 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 12
(2,439 Views)

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 

0 Kudos
Message 9 of 12
(2,429 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 12
(2,415 Views)