How to handle a Serial Framing error?

[TG]

Hi Guys,

Quick Q for those who are familiar with VISA serial functions.

My device sometimes returns error after long periods of perfect operation

−1073807253 A framing error occurred during transfer

I have seen this error before but never could figure out why it happens randomly after many thousands of perfect exchanges.

There is not too much I can do about it regarding the connections or the fact that it is going through a USB- Serial converter (Its on a laptop)

I am attempting to deal with this by putting in exception handling code that will catch the error then Close the port then

Open it again for a retry of the operation.

The Q is once an error like this occurs would an approach like this save me from further issues

does anyone have experience doing something similar to recover from a VISA error and will it work long term?

Thanks in advance

[Grampa_of_Oliva_n_Eden]

QUOTE (TG @ Mar 6 2009, 10:44 AM)

Hi Guys,

Quick Q for those who are familiar with VISA serial functions.

My device sometimes returns error after long periods of perfect operation

−1073807253 A framing error occurred during transfer

I have seen this error before but never could figure out why it happens randomly after many thousands of perfect exchanges.

There is not too much I can do about it regarding the connections or the fact that it is going through a USB- Serial converter (Its on a laptop)

I am attempting to deal with this by putting in exception handling code that will catch the error then Close the port then

Open it again for a retry of the operation.

The Q is once an error like this occurs would an approach like this save me from further issues

does anyone have experience doing something similar to recover from a VISA error and will it work long term?

Thanks in advance

Framing Erors are generally due to issue with the transmission medium.

I question the need to close and re-open. Just flushing the port and doing a retry would be my first attempt at handling this situation. Closing and re-opening a VISA session will bite you eventually uless the app is restarted regularly.

[LAVA 1.0 Content]

QUOTE (neBulus @ Mar 6 2009, 10:48 AM)

Closing and re-opening a VISA session will bite you eventually uless the app is restarted regularly.

Why do you think that closing and opening VISA session can cause problems?

[Mark Yedinak]

Your approach to detect the error, close the connection and reopen should work fine. You may lose some data in the process. The framing error is most likely caused by some clock drift. Reestablishing the connection should get you back in sync.

QUOTE (neBulus @ Mar 6 2009, 09:48 AM)

I question the need to close and re-open. Just flushing the port and doing a retry would be my first attempt at handling this situation. Closing and re-opening a VISA session will bite you eventually uless the app is restarted regularly.

I don't agree with this. In our applications we open and close VISA sessions tens of thousands of times and we do not see any problems.

[TG]

QUOTE (neBulus @ Mar 6 2009, 04:48 PM)

Closing and re-opening a VISA session will bite you eventually uless the app is restarted regularly.

Can you elaborate further on this point?

Trust me I am not dissagree with you even if I do not know full answer.

I got this error even though I open/close the port before every exchange

(was required to make it reliable as it currently is)

and many thousands of successful queries on the device yet this error still manage to creep in randomly.

[LAVA 1.0 Content]

QUOTE (TG @ Mar 6 2009, 10:44 AM)

My device sometimes returns error after long periods of perfect operation

−1073807253 A framing error occurred during transfer

Look at http://digital.ni.com/public.nsf/websearch/F3E0621CB71AA16786256F970000FC57?OpenDocument' target="_blank">this, it could be useful.

[Grampa_of_Oliva_n_Eden]

QUOTE (TG @ Mar 6 2009, 10:57 AM)

Can you elaborate further on this point?

Trust me I am not dissagree with you even if I do not know full answer.

I got this error even though I open/close the port before every exchange

(was required to make it reliable as it currently is)

and many thousands of successful queries on the device yet this error still manage to creep in randomly.

When last i looked there where about 1K bytes allocated for every opean which were NOT released until after LV shutdown for every open opeation.

Ben

[crelf]

QUOTE (neBulus @ Mar 6 2009, 11:51 AM)

When last i looked there where about 1K bytes allocated for every opean which were NOT released until after LV shutdown for every open opeation.

Can someone from NI confirm or deny this memory leak? Ben - have you reported it to NI?

[Mark Yedinak]

QUOTE (crelf @ Mar 6 2009, 12:12 PM)

Can someone from NI confirm or deny this memory leak? Ben - have you reported it to NI?

I can only provide anecdotal evidence that there is no memory leak. As I stated earlier in our environment we are constantly opeing and closing connections. If there truly was a memory leak we would have all kinds of issues with our applications.

[Grampa_of_Oliva_n_Eden]

QUOTE (crelf @ Mar 6 2009, 01:12 PM)

Can someone from NI confirm or deny this memory leak? Ben - have you reported it to NI?

Here is Dan Mondrik confirming there was an issue with opening and closing VISA sessions. Yes that post is old but I work across LV versions and there only has to be one version that is buggy for me to adapt my rules. Here is a more recent reference to VISA and leaks that recomends making sure they are the most recent version of VISA. I never said the leak rate was high. I have apps that run for years without restarting so even a slow leak is of concern to me.

I have an LV 8.6 machine running a test to see if this issue exists in a more recent version. So far it holding so that issue may have been fixed.

Ben

[crelf]

QUOTE (neBulus @ Mar 6 2009, 02:12 PM)

I never said the leak rate was high. ...even a slow leak is of concern to me.

A leak is a leak, and if we loose 1kb every time we open/close then that needs to be fixed.

[Val Brown]

QUOTE (crelf @ Mar 6 2009, 11:35 AM)

A leak is a leak, and if we loose 1kb every time we open/close then that needs to be fixed.

Absolutely!

[crelf]

QUOTE (neBulus @ Mar 6 2009, 02:12 PM)

I'll leave this running over the week-end because I really don't like talking bad about LV if I don't have to.

Me either. Although this might skew the results, can you log the available memory while you're doing this? (assuming there are no issues with the logging code )

[Mark Smith]

QUOTE (neBulus @ Mar 6 2009, 12:12 PM)

Here is Dan Mondrik confirming there was an issue with opening and closing VISA sessions. Yes that post is old but I work across LV versions and there only has to be one version that is buggy for me to adapt my rules. Here is a more recent reference to VISA and leaks that recomends making sure they are the most recent version of VISA. I never said the leak rate was high. I have apps that run for years without restarting so even a slow leak is of concern to me.

I have an LV 8.6 machine running a test to see if this issue exists in a more recent version. So far it holding so that issue may have been fixed.

Ben

PS After running a VI that opnes a VISA sesion, read zero bytes then closes the sesion in a loop for about an hour and a quarter the jury is still out.

Task manager memory showed (Kbytes)

start 1450404

end 1439120

So there is now about 10M less memory available. No there is nothing else running on that machine and I have let it run with the Windows Task manager up. I'll leave this running over the week-end because I really don't like talking bad about LV if I don't have to.

Ben,

If you get Process Explorer from

http://technet.microsoft.com/en-us/sysinte...7c5a693683.aspx

you can get more detailed info about just what is using the memory than from the task manager - it will show the actual memory consumed by a specific process and may lead to an answer quicker.

Mark

[Grampa_of_Oliva_n_Eden]

Results of over- the week-end test

Task manager memory showed (Kbytes)

start 1450404

end 1407336

That's 43M over the week-end.

Ben

[crelf]

QUOTE (neBulus @ Mar 9 2009, 02:42 PM)

That's 43M...

...of memory released - your end amount is less than your start amount. Or is that the amount of free memory?

[Grampa_of_Oliva_n_Eden]

QUOTE (crelf @ Mar 9 2009, 06:08 PM)

...Or is that the amount of free memory?

Exactly.

Ben

[crelf]

QUOTE (neBulus @ Mar 10 2009, 05:45 AM)

Exactly.

Have you reported it to NI? If so, do you have a CAR#?

[Grampa_of_Oliva_n_Eden]

QUOTE (crelf @ Mar 10 2009, 10:45 AM)

Have you reported it to NI? If so, do you have a CAR#?

No and no.

BTW: DAQmx Tasks will do the same thing (but you will have to trust me on that one. ) That behaviour SEEMS to apply to every resource allocated by LV. I think it has to do with hedging against the possiblity that someone that doesn't know what they are doing cloising a ref and then latter trying to use it (trap catcher?), but NOW I AM speculating.

Ben

[TG]

QUOTE (neBulus @ Mar 10 2009, 05:33 PM)

No and no.

BTW: DAQmx Tasks will do the same thing (but you will have to trust me on that one. ) That behaviour SEEMS to apply to every resource allocated by LV. I think it has to do with hedging against the possiblity that someone that doesn't know what they are doing cloising a ref and then latter trying to use it (trap catcher?), but NOW I AM speculating.

Ben

Thanks Ben

All I know is when I put the exception handler in and ran it over the weekensd it worked ok however

when I exit the program (The LabVIEW executable I built)

Monday Morning Windows was acting funky like it was out of memory.

It is a low price IBM laptop with 512MB like the 1970's but..

BTW Thanks for doing the testing and reporting to us.

You say simply clearing the buffer works and no side effects?

Do you also keep ythe default (4096) buffer size?

[Grampa_of_Oliva_n_Eden]

QUOTE (TG @ Mar 10 2009, 12:58 PM)

Thanks Ben

All I know is when I put the exception handler in and ran it over the weekensd it worked ok however

when I exit the program (The LabVIEW executable I built)

Monday Morning Windows was acting funky like it was out of memory.

It is a low price IBM laptop with 512MB like the 1970's but..

BTW Thanks for doing the testing and reporting to us.

You say simply clearing the buffer works and no side effects?

Do you also keep ythe default (4096) buffer size?

Maybe more than one issue but focus on serial.

It is rare that I have to mess with the buffer size, but I'd keep it the same. Generally just checking the number of bytes waiting at the port and reading those is enough to clear the garbage. If your device is spewing data at a hight rate and you think there would be data in the serial ports hardware buffer then the Flush will take care of that.

But technically speaking this is just putting a bandaid on a wound. Framing errors are usually due to corruption of the serial data because there is something less than ideal about the physical connection.

Take care,

Ben