Visa Read Error -1073807252

[Wayne.C]

---

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.

[JÞB]

---

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

[crossrulz]

---

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

[JÞB]

---

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

---

. 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.

[tiki12revolt]

---

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

[tiki12revolt]

---

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

[tiki12revolt]

---

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

[JÞB]

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 ..

[Dennis_Knutson]

---

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

[tiki12revolt]

---

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