LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

xy graph

I'm developing an LV(7.1) application to perform automated testing of our company's pneumatic valves.  Two of the inputs to the application are disk shaft angular position, which is being monitored by a rotary encoder via a serial port (com1), and servo current, which is being monitored via the voltage drop across a resistor.  These two inputs are then sent to individually to respective displays, and also to an XY graph (disk angle on Y axis, servo current on x axis). 
 
Although the individual displays appear to be working fine and display the status of both of their respective signals accurately in real time, the XY graph quickly develops a "lag" in the X axis. 
 
All of the displays and the graph are within the same while loop, and therefore should be receiving their data points at approximately the same time.  Sometimes the graph will work fine for one test cycle (approximately 40 seconds) where the servo current is programatically ramped from 0 to 100 mA and back to 0.  Then on the 2nd or 3rd cycle the data that shows on the xy graph reflects the current disk position matched with the servo current of 1, or 3, or several seconds ago.  Sometimes (particularly the first run after starting LabView and or starting this particular VI) the problem will occurr right from the beginning. 
 
I've tried changing the loop "Wait 'til next mS multiple" from 1 to 10 to 100, but the problem stays, and even seems to get worse as the loop time is increased. 
 
It kind of ruins the purpose of the graph, that of displaying the disk position vs. servo current profile of the particular unit under test.
 
Any ideas on how to combat this problem?
 
Thanks in advance.
0 Kudos
Message 1 of 5
(3,033 Views)
Hello Ed,

how do you (try) to get accurate correlation between these two signals? It looks like the settling time of the DAQ is doing no good to you. What you could to is measure all DAQ signal after getting the serial answer and using the last sample(s)

Could you show some code?

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
0 Kudos
Message 2 of 5
(3,024 Views)

You may be right about the DAQ issues.  While collecting info to reply to you, I discovered that the DAQ reading of the servo current doesn't correspond in a timely manner to the reading seen on a multimeter in series with the servo.  Since the commanded servo current matches that of the actual servo current, I am able to "get around the problem" for now by using the commanded servo current (not that read by the DAQ) as the X axis input to the graph.  I'll have to address this some time later, as I'm coming up on a deadline and must focus on getting the rest of the application developed.  Thanks for the info.

 

0 Kudos
Message 3 of 5
(3,014 Views)

I thought I'd share with anyone interested enough to read this thread, the solution to the problem I was having as described above. 

The experienced users of LabView (most of the regulars here on the forum) will find this to be a rather obvious "gotcha", however I am a relatively inexperienced LV user and this is intended to point out to users like myself to look out for these things.

The DAQ hardware involved here is an IO Tech DaqTemp PCI board and module.  I believe the reason the servo current readings were lagging behind the commanded values was because the DaqTemp vi's supplied by IO Tech were sampling at a higher rate than the rest of the vi that I wrote to run this test.  As the data was collected, the IO Tech vi buffered the data and sent one data point at a time to my vi as the main "while" loop executed.  So, as data was buffered by the IO Tech vi, the data points sent to my vi were increasingly "old" as compared to the data I was collecting or creating in my vi.  After watching the program run for a minute or so, it became clear that something was seriously out-of-sync.

My solution to this problem was to change the speed/timing/sample rate settings within the IO Tech vi such that its data rate was less that the speed at which my vi was looping, therefore my vi would be waiting (hopefully for only a brief period) for fresh data from the IO Tech vi instead of data that had been buffered some time earlier.  All appears to be working fine now, however I will look into directly synchronizing the two vi's for future reference.

Message 4 of 5
(2,959 Views)

Hi Ed,

Thank you for sharing this very valuable information.  Yes, you are correct in your description.

Another solution to this is to use the Producer / Consumer loops, with software (LV) buffers.  This way, you can read the values from the DIO board and minimize data loss due to mismatch in acquisition and processing (analysis) speeds. 

There may be some example of these available in the example finder.  I can also post an example if needed.

RayR

0 Kudos
Message 5 of 5
(2,950 Views)