Framing error in VISA

[Nikunj]

Hi,

I am getting a framing error of VISA while receiving strings of numbers dynamically from hardware. What could be the reasons for that error? Plz tell me.

[Nikunj]

Hi,

There is one hardware connected to pc, which is continuously sending values for load and deflection

in form of string. I've successfully plot those values but i am getting the framing error

"Error-1073807253 occurred at VISA Read

Possible reason(s):

VISA: (Hex 0xBFFF006B) A framing error occurred during transfer.

I am getting framing error while using serial visa port. I've checked all the serial settings i.e. baud rate, parity, data bits etc.,

I've tried many alternatives but those all doesn't work. I tried flush i/o buffer, set input buffer size and clear errors function. 

I also tried to ignore the errors from options in tools menu in block diagram. Can you tell me which mask value i should use in

flush buffer? I've also used error handler vi. All of these doesn't work.

I am sending my vi. Can you help me plz?

Plz also tell me where to put some of the blocks incase I've put clear errors block or flush i/o buffer at wrong place.

Thank You.

[Justin Goeres]

I've seen errors like this in a few different situations:

1. When I was using a cheap USB->RS232 adapter, and either the adapter hardware was no good or the drivers were no good. The solution was to try a different (and usually more expensive) adapter.
   
2. When I was running a USB->RS232 adapter at a higher baud rate than it actually supported, and didn't realize it. The solution was to change the speed of the port.
   
3. When the CPU my program was running on was really heavily loaded. (this is probably not your problem; I mean really heavily loaded, like 100% CPU usage for 30 minutes straight)
   

I suppose it could also be a problem with your sensor device, but that's unlikely.

[LAVA 1.0 Content]

QUOTE (Justin Goeres @ Dec 31 2008, 09:21 AM)

I've seen errors like this in a few different situations:

1. When I was using a cheap USB->RS232 adapter, and either the adapter hardware was no good or the drivers were no good. The solution was to try a different (and usually more expensive) adapter.
   
2. When I was running a USB->RS232 adapter at a higher baud rate than it actually supported, and didn't realize it. The solution was to change the speed of the port.
   
3. When the CPU my program was running on was really heavily loaded. (this is probably not your problem; I mean really heavily loaded, like 100% CPU usage for 30 minutes straight)
   

I suppose it could also be a problem with your sensor device, but that's unlikely.

Framing errors are (provied the baud rate, parity and num start/stop bit is correct) an indication that the signal on the wire is bad. This can be wire-run too long, external noise, bad grounds etc.

If available I suggest putting an O'scope on the recieve line and inspect the data carefully.

Ben

[AlexH]

I've just spent a very long time trying to debug something giving similar errors only in LV8.6 and not in 8.5.  It seems that the way VISA references are opend and disposed of is different in 8.6.

The situation was a single nonreentrant VI, BusCommand.vi, was called from various places in the main program, but internally it only set the serial settings (stop bits etc.) the first time it was run, and didn't properly link all its calls to the serial port using VISA reference wires.  Put a probe on any VISA reference wires you have in your program to check that the stop bits etc. remain as you wanted them.

Here is my description of the problem:

I think the problem was with the behaviour of the VISA open 

node. You will notice that it has an "access mode" option. For some 

reason the default setting causes the serial port settings to revert 

to VISA defaults (n.b. NOT the same as those set in measurement and 

automation explorer), but only if no other VI is running which has an 

open VISA session which has been correctly configured.

What was happening was that any call to read/write to the serial port 

would open a VISA session with the access mode set to VISA defaults, 

not MAX defaults. For reasons I don't understand it was ok if the 

serial settings had just been defined, but not when another vi which 

used BusCommand.vi was unloaded from memory (say a subpanel which 

called it was closed). This destroyed the VISA reference, which might 

happen half way through another BusCommand call. So the next "VISA 

open" used the default values (i.e. 1.0 stop bits).