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
(7,315 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
(7,291 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
(7,286 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
(7,277 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
(7,272 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
(7,269 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
(7,264 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
(7,256 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
(7,129 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
(7,123 Views)

tiki12revolt wrote:

 

The load cell's manual tells me you can have data output automatically at defined intervals,


What interval is presently defined and what are the available options.  BAUD rate and interval are not the same thing.  Think of this process as a continuous series of bursts of data.  The BAUD rate determines what happens inside the burst.  The interval determines how often the bursts are transmitted.

0 Kudos
Message 11 of 21
(1,989 Views)

@tiki12revolt wrote:

@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?


On a serial device?... This begs one unasked question.   Is this connected VIA a USB to RS-232 adaptor? If so did you change the USB hub power mangement options to keep Windows from shutting off power?


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 21
(1,979 Views)

@JÞB wrote:
On a serial device?... This begs one unasked question.   Is this connected VIA a USB to RS-232 adaptor? If so did you change the USB hub power mangement options to keep Windows from shutting off power?

Jeff never misses an opportunity to talk about the USB power settings.  Must have bit him really hard recently...


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 13 of 21
(1,977 Views)

@crossrulz wrote:

@JÞB wrote:
On a serial device?... This begs one unasked question.   Is this connected VIA a USB to RS-232 adaptor? If so did you change the USB hub power mangement options to keep Windows from shutting off power?

Jeff never misses an opportunity to talk about the USB power settings.  Must have bit him really hard recently...


Smiley LOL. Actually its never bit me! But I've watched a LOT of people get burned by those power options. The one that did get me was a USB cable someone had zip-tied too tight causing the CPU to reset when Windows turned on HUB Power. (There's a day I'll never get back)

 

For some reason these types of issues roll in waves. I hadn't seen one for about 6 months before this last round. I suspect that USB devices are becominng a larger percentage of the Test and Measurement market and some people are just now adoping the technology. and the USB port is more accessable than the serial port on most machines these days right on the front no need to get dusty digging into the back side of the machine.  Its easier to find a USB adapter too, it beats searching all over for that null modem cable (Or does this need the other kind?)

 

There was a time I couldn't go a day without posting another link to "Time to Excel" but I haven't needed that for most of a year now. and I must have linked to "Round Color Box.ctl" an even 1/2 dozen times in the six months after it solved one of my problems. Eventually, the search starts becomming useful when enough people post the same issue worded differently.


"Should be" isn't "Is" -Jay
0 Kudos
Message 14 of 21
(1,966 Views)

@Dennis_Knutson wrote:

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.


Thank you for the explanation. It was unclear to me until now. I will try to run a vi just reading the serial device and see if I can keep up with it indeterminatly (at least for longer than the current 5 or 6 min before the vi buffer overflows).

 

With regards to the auto-print rate, the documentaiton for the device does not specify what it is, which is why I thought that it was somehow related to the baud rate set. 

 

The DAQ Assistant is called from a sub vi to read in a number of other signals such as voltage and temperature via a USB compactRIO. I use the subVI to extract all that logic and just merge the serial device signal and the output from the sub vi before logging to file.

0 Kudos
Message 15 of 21
(1,965 Views)

@JÞB wrote:

@tiki12revolt wrote:

@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?


On a serial device?... This begs one unasked question.   Is this connected VIA a USB to RS-232 adaptor? If so did you change the USB hub power mangement options to keep Windows from shutting off power?


So. The main VI reads a serial device (a load cell) over an honest to goodness RS232 serial port. It then merges that data with the data from a compactRIO collected via a DAQ assistant to then be written to file with one line per timestamp.

0 Kudos
Message 16 of 21
(1,961 Views)

@Decoratively wrote:

@Dennis_Knutson wrote:

 

 

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.

 


Thank you for the explanation. It was unclear to me until now. I will try to run a vi just reading the serial device and see if I can keep up with it indeterminately (at least for longer than the current 5 or 6 min before the vi buffer overflows).

 


With regards to "keeping up with the auto-print", I used a stripped down version of my vi from earlier which only included the read / write to serial components (enclosed) and was able to run it for 30 min. (which is longer than I will ever need, before I manually canceled the execution) at both 1200 and 9200 baud. 

 

note: I removed the sub vi which had the DAQ assistant in it, as well as the write to file vi.

0 Kudos
Message 17 of 21
(1,952 Views)

So. The main VI reads a serial device (a load cell) over an honest to goodness RS232 serial port. It then merges that data with the data from a compactRIO collected via a DAQ assistant to then be written to file with one line per timestamp.


With regards to "keeping up with the auto-print", I used a stripped down version of my vi from earlier which only included the read / write to serial components (enclosed) and was able to run it for 30 min. (which is longer than I will ever need, before I manually canceled the execution) at both 1200 and 9200 baud.

 

note: I removed the sub vi which had the DAQ assistant in it, as well as the write to file vi.

 


 

Two clues:

One more question.

Did you disable power management on the USB hub to the cDAQ?  Timeouts would rally delay your loop rate ..


"Should be" isn't "Is" -Jay
0 Kudos
Message 18 of 21
(1,941 Views)

@tiki12revolt wrote:

@Decoratively wrote:

@Dennis_Knutson wrote:

 

 

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.

 


Thank you for the explanation. It was unclear to me until now. I will try to run a vi just reading the serial device and see if I can keep up with it indeterminately (at least for longer than the current 5 or 6 min before the vi buffer overflows).

 


With regards to "keeping up with the auto-print", I used a stripped down version of my vi from earlier which only included the read / write to serial components (enclosed) and was able to run it for 30 min. (which is longer than I will ever need, before I manually canceled the execution) at both 1200 and 9200 baud. 

 

note: I removed the sub vi which had the DAQ assistant in it, as well as the write to file vi.


So now that you can keep up with the serial, you can determine the time of the current auto-print. With a tick count and a shift register, you can get the loop iteration time. This should be fairly constant. This will tell you how fast the loop must run before you get buffer overflow problem if you cannot or do not want to change the auto-print time. Then you can add pieces back, one at a time and see which function is affecting the loop rate. You may end up with separate loops for the serial read and for the DAQ.

0 Kudos
Message 19 of 21
(1,932 Views)

@JÞB wrote:

 

Two clues:

One more question.

Did you disable power management on the USB hub to the cDAQ?  Timeouts would rally delay your loop rate ..


Yeah, I did double check power managment in Windows by disabling it via devmgmt.msc and re-running the VI and got the same timeout. Great thought though, I had not considered that usb timeout might be the culprit. 

0 Kudos
Message 20 of 21
(1,912 Views)

@Dennis_Knutson wrote:

So now that you can keep up with the serial, you can determine the time of the current auto-print. With a tick count and a shift register, you can get the loop iteration time. This should be fairly constant. This will tell you how fast the loop must run before you get buffer overflow problem if you cannot or do not want to change the auto-print time. Then you can add pieces back, one at a time and see which function is affecting the loop rate. You may end up with separate loops for the serial read and for the DAQ.


Thank you for all your help. So the timing for just the serial read/write portion of the loop is 0.19 - 0.2 sec. The full version, before it times out is 0.25 - 0.26 seconds. The write to file is approximately 4 ms (0.04 sec) per loop. The sub-vi where I use a DAQ Assistant and Set Dynamic Data Attributes seems to be consuming the remainder of the 0.02 second (20 ms) difference.

 

Might you have any suggestions as to how I would I use different loops and still be able to get one 'line' of output data per serial device autoprint?

0 Kudos
Message 21 of 21
(1,100 Views)