Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Visa Read Error -1073807252

Hi,

 

I have been reading the forums trying to resolve an problem that crops up every five min or so in my VI when I try running it for that long. Thus far, it seems to me that the two solutions are either read faster / buffer size or it might be windows / dell computers

 

In my case, it may be a windows / dell problem as my hardware / software combo is:

Windows XP SP3

Dell Optiplex GX270

LV2010 10.0f2 (32-bit)

 

I do not think that it is a read faster / buffer size problem, because (as you can see in the attached vi - Fall_serial_RW_voltage.vi) I set the read buffer to 64 bytes, even though every serial return from this device is 16 bytes. Additionally, I set the device to 'auto-write' at 19200 baud, and that is the rate I am reading at.

 

Thus I am currently stumped. The VI works perfectly for short duration tests, but when I attempt to run for longer I receive an Error -1073807252 and the VI stops running, and the logging terminates.

 

I do not currently have another (non Dell computer) to test the VI on, so I was wondering if anyone had developed a work around?

 

Any help would be greatly appreciated!

Download All
0 Kudos
Message 1 of 21
(8,284 Views)

You've set up your serial device to transmit at 19200 baud.  How often is it transmitting the data?  Once a second? Once a minute?

0 Kudos
Message 2 of 21
(8,260 Views)

You probably need to read faster. I would suggest getting rid of the express VIs/DAQ Assistant and do the file write in a separate loop. Pass the data to the separate loop with a queue such as in the producer/consumer architecture.

0 Kudos
Message 3 of 21
(8,255 Views)

@Wayne.C wrote:

You've set up your serial device to transmit at 19200 baud.  How often is it transmitting the data?  Once a second? Once a minute?


Hi Wayne, Thanks for your help! In response to your comment / question, I have a load cell. It is set to 19200 baud (see attached jpg from the load cell's software), and it is also set to auto-print so I understand it to be transmitting data at 19200 baud. 

 

If it were not transmitting at 19200 and that was my setting in my VI, would it work initially and then fail after a couple of minutes like I am seeing?

0 Kudos
Message 4 of 21
(8,246 Views)

@Dennis_Knutson wrote:

You probably need to read faster. I would suggest getting rid of the express VIs/DAQ Assistant and do the file write in a separate loop. Pass the data to the separate loop with a queue such as in the producer/consumer architecture.


Hi Dennis,

 

Please see my response to Wayne above, regarding reading data faster. The load cell is set to 19200 baud, and so is the VI. Why would I need to be reading faster? I will give it a try, but I am not sure I understand why that would fix the problem?!

 

With regards to your suggestions, do you recommend that I get rid of all express VIs / DAQ Assistant instances I am using currently, or just the Write to Measurement File express VI?

 

I currently have the DAQ Assistant coming in via a subVI and then I add that to the VISA data I collect, which is all together written to a file. If I understand what you are recommending, I should put the collection in one loop and then pass the Dynamic Data to another loop to be written to file -- not using the Write to Measurement File express VI?

 

Thanks for your help!

0 Kudos
Message 5 of 21
(8,241 Views)

You've set the load cell to "auto-print" which I assume means that it periodically/continuously sends data at 19200 baud.  My question is how often or at what rate does the auto-print occur?

0 Kudos
Message 6 of 21
(8,238 Views)

The load cell's manual tells me:

 

In the “auto print” operating mode, data are output to the interface port without a print command. You can have data output automatically at defined intervals, with or without the stability parameter. The length of a print interval depends
on the weigh cell model and operating mode.

 

The "auto-print" interval I have currently set is "1 display update", as defined in the software and manual for my load cell. Other than that the manual is unclear on the bit-rate (given the 16 bytes I am returning per "print").

 

Pardon me for not understanding, but why is that relevent, if the VISA buffer is 4 times larger than the output being sent? 

 

I will endevour to find out how often or at what rate the auto-print occurs. Thank you again for your help!

0 Kudos
Message 7 of 21
(8,233 Views)

Every time the autoprint occurs, 16 bytes of data is transmitted at 19200 baud.  If your loop can't run as fast as the auto-print rate, then it falls behind and the buffer begins to fill up and eventually will overflow.  It's pretty obvious that your progam is not keeping up with the amount of data coming in on the serial port. 

 

One thing to check is if the rate at which the "auto-print" is occuring makes sense.  Could it be slowed down?  Once you have the auto-print occuring at a reasonable rate, then look at the execution speed of your main loop.  Dennis has given you several good suggestions for improving the execution speed of your program.

0 Kudos
Message 8 of 21
(8,225 Views)

@Wayne.C wrote:

Every time the autoprint occurs, 16 bytes of data is transmitted at 19200 baud.  If your loop can't run as fast as the auto-print rate, then it falls behind and the buffer begins to fill up and eventually will overflow.  It's pretty obvious that your program is not keeping up with the amount of data coming in on the serial port. 


I'm sorry to resurrect a seemly dead thread, but I have been completely unable to resolve this issue relating to the VI erroring out when the buffer overflows. 

 

Things I've tried:

-- slowing down the serial device to 9200 from 19200 baud

-- changing the wait time within the while loop to match the new baud rate 

-- changing the buffer size

-- changing the number of bytes to be read

 

I'm at a bit of a loss. With regards to the program not keeping up, in the main while loop of the program, I have added a wait block, which is set based on (16 bytes per print * 8 bits per byte) / baud rate = # of ms to wait before next iteration.

 

As for the producer consumer architecture mentioned previously, how might I go about abstracting acquiring data from writing it to file? Don't I need to do both of those once per iteration?

 

Thank you for your help!

0 Kudos
Message 9 of 21
(8,098 Views)

Despite Wayne's great explanation, you still don't seem to understand. Each iteration is going to take x amount of time. If that time is greater than how often the device transmits, you will eventually get the buffer overflow. The baud rate - the time between bits is irrelevant. No matter what you set the number of bytes to read, you will read up until a line feed character is detected. That is how you have it programmed. To read more bytes, the loop has to iterate again.

 

Changing the baud rate does not change the auto-print rate. Two completely separate parameters.

 

I would suggest not having any wait at all in the loop and for the time being, getting rid of the Write to Measurement File and all of that stuff with dynamic data/attributes. This is pretty time intensive function. Start with the basics of just seeing if you can keep up with the instrument with nothing else going on. I suspect that your messing around with the wait and the calculations, just made things worse.

 

In the original VI you posted, I don't see where yu are calling the DAQ Assistant. If you actually are calling that, then this is also taking some finite amount of time.

0 Kudos
Message 10 of 21
(8,092 Views)