LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

auto index array

I have built a motor tester that gets 2 arrays of data from a power meter. This data is eventually stored in a TDMS file. I have light curtain that is acting as a duel purpose. First, it is instantly grounding the motor when the light curtain is broken for OHSA safety purposes. Second, it is sending a 9 volt DC voltage to signal the VI that the test is complete and to record the data to the TDMS file.

 

The problem I am having is about 10% of the time the readings recorded to the TDMS file are incorrect due to the motor being grounded as the data is being gathered from the power meter. What I want to do is store the last three sets of data from the power meter into an array and then when the light curtain is broken, the oldest data in the array is passed on to write to the TDMS file. This should prevent bad data from being recorded to the TDMS file since it will be two iterations of the state before the motor was grounded.

 

What would be the best way to accomplish this task?

 

 

0 Kudos
Message 1 of 7
(2,697 Views)

Screen shot of State

0 Kudos
Message 2 of 7
(2,652 Views)

Some added information I have gathered from experimenting.

 

The VI does not always pick up the light curtain break on the first iteration. It seems there is some residual time for the current and voltage on the 9 volt sensor circuit. The reason for this is that the safety relay that the 9 volt signal uses is a SPST. This does not allow me to ground the  9 volts signal going to my NI 9205.

 

I may have to back more than a couple iterations to get accurate data.

0 Kudos
Message 3 of 7
(2,625 Views)

Hi,

 

Just to confirm, the signal from the light curtain is acting as a trigger just for the logging option? I mean, you are continuously acquiring data and want to record all the information before the signal from the light curtain occurs.

 

Could you post the VI? With the image attached is not possible to visualize the rest of the states.

 

Regards,

0 Kudos
Message 4 of 7
(2,589 Views)

I have this state in a loop so it repeats and gathers new data each iteration. This is to allow the readings to stabilize. Once the operator is satisfied the readings are stable they reach into the light curtain to remove the motor under test. I am trying to capture the last stable reading and record it to a TDMS file.

0 Kudos
Message 5 of 7
(2,571 Views)

Hi,

 

There should be many approaches to solve this issue. However, I think the most recommendable solution will be to use a FIFO queue. Considering that you will be acquiring data for certain amount of time until the readings begin being stable (we don’t know when that is going to happen) is not a good idea to record all the readings (memory considerations). Using a FIFO will allow you to maintain in memory a specified amount of readings. When the FIFO is full, the oldest reading will be discarded.

 

When you detect the signal from the light curtain, we are supposing that there will be invalid information in the queue. However, you will be able to select just the readings of interest using the array functions.

 

 

queue.png

 

 

I found the next example in the community that shows how to use the LabVIEW queue as a FIFO.

 

https://decibel.ni.com/content/docs/DOC-12057

 

Regards,

0 Kudos
Message 6 of 7
(2,536 Views)

@MwMonty wrote:

I have this state in a loop so it repeats and gathers new data each iteration. This is to allow the readings to stabilize. Once the operator is satisfied the readings are stable they reach into the light curtain to remove the motor under test. I am trying to capture the last stable reading and record it to a TDMS file.


Just an FYI - I don't like things like "when the operator is satisfied..." because it leaves too much room for subjective opinion (which sometimes leads to intense discussion and bruising of egos, as well as making it easier for the customer to reject a part).  I would change the test requirements to something quantifiable, like "rate of change +/- 1 mV over ten readings" or whatever it is that the test engineer feels is apporpritate.  The tester should be telling the operator it is ready to start the test, not the other way around - if possible, that is.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 7 of 7
(2,491 Views)