Labview program stop after a few while loop

[altenbach]

---

@keysuccess wrote:

. the byte is 1 kb, it should be 67MB.  

---

You are writing only the last data to the file instead of appending, thus the file will always be small. (You wired append=FALSE to the file IO)

What does the error show when the program stops? (you are not displaying the error wire coming out of the file IO)

[keysuccess]

The error message is "VISA Read in Agilent 2000 3000 X-Series.lvlib:Fetch Waveform.vi->Agilent 2000 3000 X-Series.lvlib:Read Waveforms (Multiple).vi->oscilloscopemultichannel.vi"

[Bob_Schor]

I notice that everything is happening in a single loop -- you Read Waveforms (Multiple) then Export Waveforms to Spreadsheet File (which has False wired to "append to file?", so it keeps overwriting the same file), then repeats all this.  How fast are data being acquired, and how much data is there?  Is it possible that the loop doesn't run fast enough, that the unknown "Read Waveforms (Multiple)" is throwing an error because it is unable to run because the loop is too slow?

A Producer/Consumer Design Pattern might help.  But an even simpler thing to try is to simply remove the Export Waveforms to Spreadsheet File function, and allow the data to be "thrown away".  Now you have a simpler loop that only does a Read Waveforms over and over.  If it runs with no sign of error, then "data backup" might well be the underlying problem.

Bob Schor

[keysuccess]

I have  removed the "save waveform to excel spreadsheet", let the data throw out, but after a few loops, the same problem happened.

"VISA Read in Agilent 2000 3000 X-Series.lvlib:Fetch Waveform.vi->Agilent 2000 3000 X-Series.lvlib:Read Waveforms (Multiple).vi->oscilloscopemultichannel.vi"

I set the time out in the "read waveform(mulitple).vi" as 10000 ms, and the while loop wait time as 20000ms.

The data points are 1 million for each while loop.

So it is not the storage problem, it may be the problem of the "read waveform(mulitple).vi"

Attached is the revised VI.

Any suggestions?

[Bob_Schor]

The code looks OK, but as I don't have access to the critical VISA routines that get the data in, I have no idea what's really happening.  You still have all of the processing in a single loop, and the loop still has a "Wait" function inside to clock it.

Let's assume that Agilent know what they are doing and so do you, that is, let's assume that the two Agilent routines work properly (as does your device).  Try running the following routine:

• Start with your last posted routine.
• Hook an indicator up to the index of the While Loop (to watch the loop iterate).
• Remove the Graph -- just throw away the data.
• Remove the Wait -- let the loop run "as fast as Agilent lets it".
• Run it for 10 seconds (more or less) then push the Stop button.  How many loops did it run?  Does that number make sense in terms of the sampling rate and data size you are expecting from your device?

If the above test works, then you've got a good "Producer".  Now design a Consumer and Consume outside the Producer Loop.  If it fails, then you are doing something wrong with the Agilent code.

Bob Schor

[keysuccess]

I did like what Bob suggested. I remove the wait time for while loop and let the while loop run naturally. i also remove the wave form graph. I can see the loop count updates quickly, when it is 25th loop, the same problem happened. I have to restart the oscilloscope in order for the program run again, then it will stop at certain loop. kind of strange...

[Bob_Schor]

That is very strange.  What happens if you just do a single channel?  It's very much looking like a problem with the Agilent routines ...

Bob Schor

[keysuccess]

I tried the single channel before, same problem.

[cstorey]

How long does a single measurement take?  Do all 3 measurements happen simultaneously or successively?

Right now your timeout value of 10s is not connected to the "Read Multiple Waveforms.vi" in the last VI you posted.  Make sure that's connected and make sure it is an order of magnitude longer than all 3 measurements take, since its just a timeout value it shouldn't matter unless you run into a problem.

I suspect that the scope takes several seconds to acquire your traces and on occassion it takes more than the timeout period you've specified.  Why would that happen?  Since you are using a software trigger, the instrument thinks its free to do whatever it wants when there are no commands to process.  If you run into the case where the command to start acquiring data is sent, but the scope is busy some internal processing (auto-zero or auto-calibration that happen every so often) then a timeout may occurs in the Read Waveforms and only some fraction of the waveform data (1.5/3 traces) is available for the VI to read.  This probably causes an instrument error, not enough data available, and that Read Waveform VI doesn't handle those errors properly.   Instrument vendors rarely handle these types of errors in their LabVIEW drivers.  They aim for simple use cases, not fully debugged robust code!

So try connecting the timeout, making it excessively long 100xmeasurement time, remove the loop wait time and just let the instrument work at its own pace. 

I would also look at the internals of the Read Waveforms VI and see what sort of error handling they do and perhaps log those errors a bit better than I suspect they are logged right now.

Good luck!

[keysuccess]

I tried to use the original low level  "read waveform(single).vi" from the driver. the same problem happened, but it seems the problem is from the "initiate.vi". The error will propagate through all other VI. Attached are the pictures of the VI and block diagram.