Trouble reading data from NI mydaQ, maybe?

[Zee77]

Hello all, 

I am having an odd problem with my LabView program and I am hopeful someone here could help me figure it out. So here it goes. 

My hardware setup: 

1. A power supply, applying 46V, is connected to the Newport Motion controller/driver SMC100. An actuator is connected to the SMC100. The SMC100 is connected to LabView through a COM port. 

2. A 250gram FUTEK load cell is connected to a FUTEK sensor digital-reader through which it connects to a data card, NI myDAQ. The NI myDAQ is connected to LabView through USB. 

How it works: The load cell is mechanically attached to the actuator. When the actuator moves, the load cell moves with it, allowing me to collect force and displacement data at real time. 

Now, there is no problems with wire connections or the hardware. My LabView program however is the part that I believe has the problem. I wrote it in a way that allows me to control the actuator by choosing the serial port, the start position, the velocity by which it goes to the start position. After choosing the desired previous inputs, I run the program and it goes to the start position. Then it stops. Now I have to the CONTINUE button to start the actual testing. Right when I hit the CONTINUE button, the actuator moves and I get force and displacement real time signals on a waveform chart. Data are collected and written in an excel file at the time. In NI myDAQ, I set up number of samples as 50 and with 1KHz sampling rate. 

The problem:

When I run the program the first time to go the start position, there are no issues at all. But after that, when I press CONTINUE for the actual testing, I get readings of both force and displacement for couple of seconds and then the force signal just drop and the program is stopped by itself. The odd thing here is that every time I run it, it collects data for a different period of seconds and stop. It is not consistent. To clarify the problem more, the actuator I am using moves from 0 to maximum of 50 position. Let's say I used 25 as a start position. I run the program, the actuator moves from 0 to 25 and stops. Then I press the CONTINUE button, and it moved once to 30 and stopped. Once it moved to 40 and stopped. Once it moved to 27 and stopped. And once it gave me error -200279 (The application is not able to keep up with the hardware acquisition). 

The way it should be working is: When I press the CONTINUE button, it should move all the way to 50, allowing me to collect continues force and displacement signals on the waveform chart. 

In the attachment below, I included my VI and a screenshot of the program when it is running and you will see the signals on the waveform chart dropping and forcing the program to stop. 

Any help is much appreciated

Thanks. 

[GerdW]

Hi Ziyad,

your VI is quite hard to "read" because many controls are missing their labels. Please don't delete labels - hide them when you don't want to show them in the FP!

once it gave me error -200279

You configured the DAQAssistent to read 50 samples with 1kHz samplerate: you will read the data each 50ms. When you don't read the data fast enough the buffer may fill up until you get this error…

When I press the CONTINUE button

This is one of the controls with an empty label…

it should move all the way to 50

I don't see this in your code! You set start positions, start speed, test speed. But there is no test for reaching some end position…

[Zee77]

Hi GerdW,

Thank you very much for your reply. 

once it gave me error -200279

You configured the DAQAssistent to read 50 samples with 1kHz samplerate: you will read the data each 50ms. When you don't read the data fast enough the buffer may fill up until you get this error…

What do you suggest I change so that the buffer won't fill up and end up with the same error? 

When I press the CONTINUE button

This is one of the controls with an empty label…

I have always thought that labels can't affect the functionality of the code. I might be wrong. Can you explain to me how could this be a problem? 

it should move all the way to 50

I don't see this in your code! You set start positions, start speed, test speed. But there is no test for reaching some end position…

Well, you are right! However, I am not worried about this right now. I did not include this in my code because the actuator I am using will not go over 50. When it reaches 50, the signals on both force and displacement graphs would go to zero anyway. At that point I would just stop the program and collect my data. So no worries here. 

Thanks again...and I will be waiting for your reply

[GerdW]

Hi Zee,

What do you suggest I change so that the buffer won't fill up and end up with the same error?

Read the data more often - don't block the loop with other stuff like file IO or other slow functions…

I also recommend to read at ~1/10 of the samplerate, so with 1kS/s you should read 100 samples per iteration.

I have always thought that labels can't affect the functionality of the code. I might be wrong. Can you explain to me how could this be a problem?

LabVIEW doesn't really care about those labels (in the sense of "your VI will also run without them"), BUT:

- would you write an equation like a:=b+c in other (text based) programming languages like this "" := "" + "" (variables without labels)?

- once you want to use property nodes it's quite irritating to have (all) property nodes for items named ""

- once you want to filter control references by their control label it starts getting tricky when they all are labelled ""

- it doesn't make a good code documentation when all "variables" are labelled with empty strings!

Recommendation: hide the labels on the FP, but use them for documentation reasons in the BD!

[Zee77]

Read the data more often - don't block the loop with other stuff like file IO or other slow functions…I also recommend to read at ~1/10 of the samplerate, so with 1kS/s you should read 100 samples per iteration.

I tried reading 100, 200, 300, 500 samples per iteration. It took care of the error problem. But the signals still drop off for no obvious reason. As they drop off, the whole program stops. See the picture attached. I also tried running it without the file IO function. It responded the same. 

Thanks for your help,

Zee