05-10-2018 02:20 AM
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!
05-10-2018 05:23 AM
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.
05-11-2018 09:48 AM
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.
05-11-2018 05:16 PM
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:A 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.
05-12-2018 02:11 AM
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?
05-12-2018 08:35 AM
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!
05-12-2018 06:40 PM
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.
05-13-2018 12:31 PM
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…
05-13-2018 02:02 PM - edited 05-13-2018 02:17 PM
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:
05-13-2018 03:11 PM
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