how to recover from an intermittent TCP timeout exception

[tmcolby]

What is the proper way to recover from a snap7 exception ISO : An error occurred during recv TCP : Connection timed out?

If I place a db_read() into a try/except clause to keep the application from aborting on TCP timeout, subsequent db_read() become out of sync. It seems somewhere the calls are queued. Probably in the native snap7 thread.

For example: If I have three locations I am reading from a PLC
3,260,4 contains value 100
3,272,4 contains value 200
1,104,4 contains value 300

-the first db_read(3,260,4) call successfully returns a value 100
-second db_read(3,272,4) call times out with TCP timeout exception
-third db_read(1,104,4) call will return value 200 (Not 300 like you would expect)
..
-a fourth call of db_read(3,260,4) will return the value from the third call above (300)

It seems the method calls get spooled into a queue and for every call that times out, the data returned will be delayed that many calls in the future.

Is there a way to throw away the buffer on a tcp timeout? Or is there some other philosophical approach I should be taking? It seems very dangerous to call a function with specific arguments and get the wrong data back. Thanks for any suggestions.

[gijzelaerr]

hm, interesting. To be honest, I don't know. python-snap7 is just a thin wrapper around the snap7 library, I think we need to ask the original snap7 author what the idea behind this is. Can you open an issue on the snap7 bugtracker, and keep this issue updated?

[tmcolby]

Sure, I'll do that. I did scour the python wrapper some and see that it does not implement anything beyond the original snap7 library.

…

On Mon, Feb 27, 2017 at 10:28 AM Gijs Molenaar ***@***.***> wrote: hm, interesting. To be honest, I don't know. python-snap7 is just a thin wrapper around the snap7 library, I think we need to ask the original snap7 author what the idea behind this is. Can you open an issue on the snap7 bugtracker, and keep this issue updated? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ7SAulnzpmocOD8KCi_gjZJAg_KygB4ks5rgxXHgaJpZM4MNcla> .

[tmcolby]

See the discussion on sourceforge

I duplicated the issue I was having with my python application by replicating it in C. Apparently there are certain types of error's, a TCP timeout being one of them, that require a re connection to the plc. Davide is very responsive. Big thanks for his support.

[gijzelaerr]

ok great. So can we close this issue?

[lautarodapin]

See the discussion on sourceforge

I duplicated the issue I was having with my python application by replicating it in C. Apparently there are certain types of error's, a TCP timeout being one of them, that require a re connection to the plc. Davide is very responsive. Big thanks for his support.

Could you replicate the code to handle the error? I'm having hte same issue.

[spreeker]

We should add some connection checks / handle network errors properly.

void CheckConnection()
{
    while(!ChannelStatus)
    {
        ChannelStatus=CliConnect();
        if (!ChannelStatus)
            SysSleep(1000);         
    }
}

bool TcpError(int Error)
{
    return (Error & 0x0000FFFF)!=0;
}

[Momoben3434]

Do you found a solution for this issue as I have a similar issue . Please advise ?

[jarkowski]

Same here. I would like to implement something like a timeout that I can pass with the connect.

My skills are limited, but what i have in mind is something like this:

siemens_logo_plc.connect(logo_ip, TSAP_CLIENT, TSAP_SERVER, timeout)

Currently, I wrap the connect in Try,Except. That is working, but not an elegant solution.