My .vi will not properly read the waveform. Can anyone tell me why / help?

[Jryan]

The intention of this VI is to set up the scope (Tektronix TDS3034B), then to wait until a waveform has been captured before moving on.  Just before the initiate.vi is run there is a loop that waits until the last setup command has been accomplished, this is being done by querrying the last command until it is the same as what w sent.  Then in initiate ( which I have altered - and attached to this posting) I have added a couple of commands.  DESE 1 sets the DESER register on the scope allowing for the SESR register to provide an indication that an event has occured.  *OPC command tells the scope to set the 0 bit in the SESR when the command following the *OPC command has been accomplished.  The next command (Acquire:state run) informs the scope to start acquisition.  The next loop querries the scope SESR bit until it is set, which happens when the waveform has actually been captured.  From there it goes into the fetch waveform.vi to get the information from the scope.

The program works well until it starts retreiving the data.  I have attached the program as well as the NI-SPY capture.  There is a loop within the get raw waveform.vi (which is inside of the fetch waveform.vo) which reteives the data in 4096Byte chunks - it manages to read 3 before crapping out in an error that I don't recognize.  Can anyone tell me what I should do to get beyond this point?

JRyan  

[Robert M]

What error do you get?

Your capture didn't come through for some reason.  Please attach it as a .spy file.

"Initialize Acquisition1.vi" is missing as well, but I'm not sure that matters as I don't have a TDS3034b.

[Jryan]

The loop inside of Get Raw Waveform.vi continues while the error = 1073676294, which it does for 3 iterations.  On the fourth an error of (-1073807339) is returned.  I have not seen a negative error before, and don't know its significance, but it was negative.  I will try to attach the NI-SPY capture again, but it wouldn't let me do it last time-explaining that the file extension was not allowed.  I just tried it again, with no success.  The allowable file extensions shown does not include .spy.  I will change the extension to .txt, perhaps if you change it back on your end you can get it open?

Thanks,

JRyan

[Robert M]

Positive error codes are generally warnings or user-defined errors, while negative error codes are actual errors.  -1073807339 is a timeout error, and in your case it means that the timeout expired before your instrument responded to ibrd.  How many iterations should the while loop be running?  In other words, how much data should you be getting back and how much are you getting back?  Has this program ever worked beyond the three iterations?

[Jryan]

I added an and gate to the input of the argument for the while loop so that it will continue while the positive error continues and the loop iterations are <2.  This allows for 3 reads, and I get all of the waveform data.  Do you see any problems with this approach?

Thanks,

JRyan

[Robert M]

If you are getting all of the data you want then it sounds like a good solution.

[Jryan]

Robert,

In my vi I would like to notify the user on the front panle that it is alright to discharge (create the input signal).  I have a trigger level command followed by a waiting period inside of a while loop that ends when i=2, triggering a boolean indicator.  The problem is that the indicator does not light until after the waveform is actually captured because they are both inside of the same sub.vi's (Configure 10uS.vi and 200nS.vi), which are in each of the two cases of a case structure.  I will include the main vi & the two sub.vi's.  I need these indicators to light the moment the argument becomes true, and go off when completed.  Any ideas?

Thanks for all the help,

JRyan

[Andy F.]

Hey JRyan,

It sounds like you might want to think about a parallel architecture rather than a serial one.  Since LabVIEW won't update that indicator until it receives its data from the subVI then you won't have an immediate repsonse, as you noticed.  However, if you create an architecture that has two loops, one to handle the processing and the other to handle the user interface updates, then you could have more control over when the indicators are updated.  The easiest method would be to use a global variable, which is written to in your subVI and is read in the display loop.  Yes, this does break dataflow, but since you are going to be reading only or writing only this will not cause a race condition.  This method will not be very scalable however, so if you wanted to you could use a queue instead to prevent any data from being lost.  There is good information in Help, or you could repost!

Andy F.

Message Edited by Andy F. on 04-19-2006 05:06 PM