11-30-2012 04:09 PM
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!
12-03-2012 09:12 AM
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?
12-03-2012 09:26 AM
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.
12-03-2012 10:41 AM
@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?
12-03-2012 10:51 AM
@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!
12-03-2012 10:55 AM
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?
12-03-2012 11:29 AM
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!
12-03-2012 12:27 PM
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.
02-12-2013 04:41 PM
@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!
02-12-2013 05:07 PM
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.
02-13-2013 06:55 AM
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.
02-13-2013 10:42 AM
@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?
02-13-2013 10:47 AM
@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...
02-13-2013 12:38 PM
@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.
02-13-2013 12:46 PM
@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.
02-13-2013 12:51 PM
@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.
02-13-2013 03:05 PM - edited 02-13-2013 03:13 PM
@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.
02-13-2013 03:24 PM
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 ..
02-13-2013 04:13 PM
@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.
02-14-2013 04:09 PM
@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.
02-14-2013 04:24 PM
@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?