Hello,
I am using a U6 module with labview 2011 and XP. I am measuring and recording 14 analog inputs (1000 samples at 1 kHz). Things are working fine at the begining, but after a few days (sometimes 3 days sometimes more... up to a week) we suddenly get a shift of the inputs : for instance, the signal of sensor 6 connected to input 6 is measured and displayed on input 5 and stays this way until we restart the program. From a hardware point of view, an external voltmeter connected to pin 6 shows the correct voltage of sensor (but the program sees it on channel 5).
When this occurs, all channels are shifted to the left at the same time. We have experienced a shift up to 4..for all channels at the same time.
I have attached one example (.zip) that shows the problem : everything fine until "15/03/2017 18:39:00", then there is a shift of the measurement to the left. Restarting the program gets things back in order until the next shift. Column P is a measurement made with a sensor that is connected through RS232, no shifting occurs. AIN9 is connected to GND, no sensor connected, and the value is displayed in column K, starting with the value 0.000401V. this value is alos shifted like the other ones, as you can see on the excel file.
I have also attached the labview part of my program that makes the measurements using the U6 module.
We have been using the U6 modules for years and we have never seen this before. Do you have an idea what is going on? We have tried with another U6 modules and got the same behaviour.
Thank you for your help.
User
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
We don't have a compatible LabVIEW version to view your VI. If using stream mode there was a issue in the UD driver that could cause shifting samples if autorecovery (caused by a stream buffer overflow) occurs. That was fixed starting with driver version 3.49. Try installing the latest UD driver and see if that helps the issue:
https://labjack.com/support/software/installers/ud
If not, please provide a screenshot of your VI's block diagram.
Thank you for your answer. Here is the setting of the U6 unit :
Firmware Version : 1.390
Bootloader Version : 6.150
Hardware Version : 2.000
I have just installed the latest UD driver and started my program to see how it goes now. I have also attached a Labview version 11 of my program.
Best regards,
User
I have been running the program with the "Wait until next ms" set to 1000 ms and without it, and in both cases I get a reading problem :
#scans read = 0
Device backlog 45.70%
#skipped scans : 21474830
UD Backlog = 11956 samples
I guess I am not reading out the measurement quickly enough. Do you have any advice a part from deleting the 1000 ms "Wait until" which didn't have an effect? Should I just reduce the number of samples to measure? for instance 100 instead of 1000 should help? I usually use this kind of program bit have never tested it with so many inputs.
Thanks.
User
We use LV 7.1, so still can't view your LV 11 VIs. Can you post a screenshot showing your stream configuration and another showing your stream read loop:
https://labjack.com/support/app-notes/screenshots
What wait mode are you using? Our LabVIEW examples all use SLEEP mode and when using SLEEP mode the read call controls timing so you don't want to add other timing control to the read loop. Read about wait modes here:
https://labjack.com/support/datasheets/u6/high-level-driver/example-pseu...
Also, you should be watching Device Backlog and UD Backlog as shown in "U6 easy Stream Full.vi" and "U6 Stream Example LJ_swSLEEP.vi". These parameters might bounce above 0 a little, but should not be growing over time.
For comparison to your program, you can run either of those examples or LJStreamUD.
I will look at your examples. I have attached a simplified version of my program.
User
You are using easy stream read which uses SLEEP mode so you definitely don't want the wait-until-next-ms in your read loop.
You are using scanrate=1000 and scansperread=1000, so your loop will execute about once per second without the wait-until-next-ms. That is normal. Changing scansperread to 100 would generally require more processing effort.
When you add the backlog displays, if you see them growing I would first try getting rid of the serial port code you have in parallel. It does not look bad as you are controlling the read loop to only happen every 500ms, but you never know. The other thing to look at is your processing code in the 2nd frame of your stream read loop, but it does not look bad at all to me. One thing I don't understand is where the 4 shift registers on the right side are going?
Hello,
Sorry for my late response, been working on other projects and running some tests to try and solve this problem.
To answer your last question : the 4 shift registers have no use here since I have deleted some stuff for the purpose of the screenshot for my question here.
Following your advice I installed the latest Driver and since then the shift problem that I was discribing has completely gone. Thanks.
However, the other problem remains. After roughly 1 week or a bit more of runinng ,input readings stopped yesterday with the backlog showing :
#scans read = 0
Device backlog 45.70%
#skipped scans : 21474836
UD Backlog = 13678 samples
The wilhe loop controling the serial measurement was set to 1000 ms (instead of 500 ms) and the property node was set outside the while loop this time as you can see on the attached file.
Do you know what else I could try ? If there is no straight forward solution, is there a way to restart easily the U6 module when an error message comes up?
Thanks.
User
Did you get rid of the timing in your stream read loop? That was the big point from my post #7.
Sorry, forgot to say the timing has been deleted. I don't have the problem when I don't run the parallel loop that takes care of the serial measurement.
Since timing isn't a problem in my situation, I wonder if I shouldn't just use the Streaming burst example and run the serial measurement just after as you can see on the screenshots?
User
I definitely recommend showing the "Stream Parameters" cluster output on your front panel so you can watch Device Backlog and UD Backlog. They will typically bounce around a little, near 0, but should not be growing over time. I made a new attached example that does more time analysis. If you do the same with your added serial read it might lend some insight. You will see that the stream read only needs a few milliseconds each iteration to do its thing.
What is the first errorcode you get? 2008 or something else?
If you don't need continuous data, then you could certainly use stream-burst in series with your serial read.