OpenOutgoingCommunication never timeouts and CPU crashes


#1

Hi,

I am writing a chart to receive a TCP data string from a device that is turned on by an opto22 digital output.
When I try to open the communication handle, the OpenOutgoingCommunication doesn’t timeouts if the device is not responding (ethernet cable unplugged). This ends with the CPU not responding and I have to do a power restart. What am I missing here?

the code is:
sSidusComStr = “tcp:192.168.255.10:10002”;
SetCommunicationHandleValue(sSidusComStr, chSidus_Port);
Sidus_ComStatus = openOutgoingCommunication(chSidus_Port);

thanks for your help,

Pierre


#2

Hi Pierre,
Your string looks fine. Even if it wasn’t, you shouldn’t have to restart the hardware. This sounds a possible bug. Have you contacted our Product Support Group? (It’s FREE!) What version of firmware are you using, and on what hardware? (For example: “Version R9.1b on a SNAP-PAC-R1”)
Thanks,
-OptoMary


#3

Hi Mary,

I am using a SNAP-PAC-S1 with firmware version 9.1b. Seems to be the last one available.

any idea why a socket connection make the cpu hangs?

regards,

Pierre


#4

Hi,

after investigating the problem, I found that the problem comes from the ReceiveString function over a TCP connection. If the connection is lost (unplugged cable), The CPU hangs in the function, The the other charts are still running, but the OPC communication with the supervisor PC is lost and the debug view in pacControl crashes. When I replug the cable, everything comes up again. I tried to protect the call of ReceiveString (with IsCommunicationOpen), it is better, but the problem is still possible.
I am going to try to set the communication timeout value to see if it does anything.
If you have any advice on how to use this function securely, let me know,

regards,

Pierre