LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Stable, software-driven square wave output to DAQ device

G'day,

 

Today is the first day I've really used Labview NXG, and I'm having some issues with a fairly basic task. My DAQ device (PCI-6509) doesn't have any counters, so I'm unable to use the DAQmx Counter functions to generate waveform outputs.

 

As such, I'm trying to create a waveform in software using system timers, which then toggle a digital out pin HIGH/LOW. This approach works to an extent, but only for a very narrow and relatively low range of frequencies. I can't imagine my approach is optimal, but unfortunately all/most of the examples I've found only are .vi files and not useable in NXG?

 

I've attached my .gvi file for reference. Any guidance would be greatly appreciated. For context, the aim is to simulate the output of a hall effect sensor measuring the rotational speed of a motor. The simulated hall effect output should be as precise as possible between 0 and ~400 Hz.

 

Thanks!

0 Kudos
Message 1 of 11
(3,057 Views)

If it makes any difference, I'll be purchasing the Labview Home Edition tomorrow, so will be building this software-driven square wave output in Labview, not NXG. Hopefully I'll be able to find and use a .vi example, or one of the many included with Labview itself.

 

I'd still be very interested to hear if I'm on the right track with the diagram I attached above. Would using an external clock source help in any way? I'd hope to avoid that given how low the required output frequency is, but if it's the difference between having a stable wave and a jittery mess I'll happily do it.

0 Kudos
Message 2 of 11
(3,025 Views)

Hi Jars121,

 

For some reason I had some trouble opening your code.  Would it be possible to add a screenshot of it?

 

In LabVIEW, the "Digital (Pipelined Sample Clock) - Continuous Output" example looks like it may be a good place to start, if I understand your use case properly.  You should be able to find it under the example finder.

Trevor H.
Technical Support Engineer
National Instruments
0 Kudos
Message 3 of 11
(3,004 Views)

Hi Trevor, thanks for your reply.

 

I've now moved to Labview, so unfortunately don't have the NXG file/screenshot to upload. I've built a very simple digital output circuit, the diagram for which is as follows:SimpleOutput.PNGA shift register toggles a boolean value, which is provided as the source to the DAQmx Digital Write for my PCI-6509. The wait timer is controlled by a gauge. I've connected an oscilloscope to the output of this circuit, which shows the frequency of the output square is extremely unstable. I.e. it will jump between x Hz and 1.5x Hz, then 0.75x Hz, etc.

 

I've reviewed the "Digital (Pipelined Sample Clock) - Continuous Output" example, but am not able to run it on the PCI-6509. For that matter, I've searched all examples compatible with the PCI-6509, and am unable to run any of the examples for some reason? For example, "Digital - Continuous Output" appears to offer what I'm after, and is listed as being compatible with the PCI-6509, but when I run it, I get:

 

 

Error - 200077 occurred at DAQmx Timing (Sample Clock).vi:4730001

Possible reason(s):

Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.

Property: SampTimingType
Requested Values: Sample Clock
Possible Values: On Demand, Change Detection

Task Name: _unnamedTask<13>

 

I've gone through the diagram, but can't seem to change the DAQmx Timing parameter to anything which won't produce an error.

0 Kudos
Message 4 of 11
(2,992 Views)

I've been through and adapted just about every example .vi I can get my hands on which deals with signal generation, square waves, etc., and am producing the same result every time. Are software-timed signals just that bad? I'm looking at a ~18Hz square wave on a waveform chart at the moment, which shows outrageous jitter on my oscilloscope. I can't believe that software-driven waveforms are this unusable?

 

Is my only option really to buy a dedicated counter/timing card like the PCI-660x?

0 Kudos
Message 5 of 11
(2,976 Views)

Hi jars,

 

the timing in your example is defined in the task, which is defined in MAX.

Your 6509 only supports "on-demand" (software-timing), so you cannot use a task with a sampleclock defined!

 

Are software-timed signals just that bad?

Generic answer: yes.

The timing here is mainly influenced by your OS (probably Windows)…

 

Btw. it doesn't make sense to connect a DBL value to the wait function!

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 6 of 11
(2,970 Views)

Thanks GerdW, much appreciated!

 

I'm very comfortable with the 'on demand' nature of the PCI-6509, and had taken this into account when making the purchase. The assumption I made at the time was that the OS, even Microsoft (which I am using), would offer at least ~1ms resolution. It would appear that I'm unable to produce a stable toggle at even 5Hz, so either I've set my diagram up incorrectly, or I grossly overestimated the capability of software timing.

0 Kudos
Message 7 of 11
(2,963 Views)

Hi jars,

 

I'm looking at a ~18Hz square wave…

At 18Hz you need a wait of 1000/18=55.56ms (or 27.78ms for 50% duty cycle). Both numbers are not available with the standard wait function you use in your code!

 

was that the OS, even Microsoft (which I am using), would offer at least ~1ms resolution.

You made a simple error: "resolution" is not the same as "accuracy"…

 

I grossly overestimated the capability of software timing.

Well, you did switch off your antivirus software? Disabled any network traffic?

You might try those improvements:

- use a TWL. On Windows it will enforce single core usage…

- increase the priority of your (LabVIEW?) task using the taskmanager…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 8 of 11
(2,952 Views)

Yes use a timed while loop. Disable debugging and automatic error handling.

 

The ms Timer is notorious for jitter.  There is a high res wait in LabVIEW 2018.  but it will be jittery too

 

How often does the gauge really change? is it vital to update the value by switching to the UI thread every iteration?  An event driving a Notifier would only use the UI thread when the value changes.  See Producer Consumer (Events) but use a notifier in place of the queue and use get notifier status (do not ignore last value) to update theTimed Loop Period

 

 like this:

Less jittery DAQmx.pngLess jittery DAQmx2.png


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 11
(2,946 Views)

What you want is a timer card, a card with its own clock that you set and then let it run independent of the PC's clock (and independent of anything that the PC may need to be doing).  Many of these have TTL outputs that could, in principle, drive whatever you were trying to drive with the 96-port DIO card.  These DIO cards are great when used in a LabVIEW RT routine where you have a timed loop driven by a timer card (so the loop, again, runs relatively independently of the rest of the LabVIEW RT code).

 

Bottom line -- for accurate clocks, don't use the PC's clock (but you've already heard that ...).

 

Bob Schor

0 Kudos
Message 10 of 11
(2,939 Views)