single poiint of failure? stuck stack

[Efried]

Hi,
after some days working well during the night my old BRE WC has changed IP address (due to a DCHP setting) and the other PLC WC has stuck sending WEBSET to this reconfigured BRE WC. I implemented code stopping to contact the failed BRE WC, but once the WEBSET to the not addressable WC  is in the queue, using WEBSET on the PLC WC for data logging on the server is impossible...
If this situation is verifiable, I need a purge communication stack command....reset is no solution unless the logging happens first...
I also noticed an open FTP port with the BRE WC.
 
thanks

 

[CAI_Support]

Thanks for your post. BRE firmware is old and not have any update for them in the future.
If your board hardware is rev 2.2.2, it might be a good idea to upgrade it to PLC board.  However, for HW 2.0.2 rev board, due to processor differences, it does not have latest firmware, either.
 
Since the Microchip TCP stack is not easy to purge unfinished TCP tasks, we may have to implement a "reboot" command for you, so that once the PLC runs into that, it will restart the board, which effectively purges everything.  However, if your PLC program has some intermediate status needing to remember, those will be purged also.

 

[az1324]

Since the Microchip TCP stack is not easy to purge unfinished TCP tasks

I don't believe that.

TCPDisconnect(MySocket);
MySocket = INVALID_SOCKET;

 

[Efried]

hi, many thanks, but restarting won't help if the wc calls the failed wc same as before. ..

Thanks for your post. BRE firmware is old and not have any update for them in the future.
If your board hardware is rev 2.2.2, it might be a good idea to upgrade it to PLC board.  However, for HW 2.0.2 rev board, due to processor differences, it does not have latest firmware, either.
 
Since the Microchip TCP stack is not easy to purge unfinished TCP tasks, we may have to implement a "reboot" command for you, so that once the PLC runs into that, it will restart the board, which effectively purges everything.  However, if your PLC program has some intermediate status needing to remember, those will be purged also.
 

Thanks for your post. BRE firmware is old and not have any update for them in the future.
If your board hardware is rev 2.2.2, it might be a good idea to upgrade it to PLC board.  However, for HW 2.0.2 rev board, due to processor differences, it does not have latest firmware, either.
 
Since the Microchip TCP stack is not easy to purge unfinished TCP tasks, we may have to implement a "reboot" command for you, so that once the PLC runs into that, it will restart the board, which effectively purges everything.  However, if your PLC program has some intermediate status needing to remember, those will be purged also.

 

[CAI_Support]

From what you described,  you have a PLC board doing WEBSET to a BRE board. When the BRE board lost connection, PLC board stuck on the WEBSET, not moving forward with next WEBSET request.  Is that correct description?
 
We checked our code, if PLC board failed to make connection to the HTTP server after six seconds, it will abandon that WEBSET request.  Are you sure you do not keep sending new WEBSET to that BRE board?
 
Could you please provide us a test case with your minimum PLC code and your WEBSET configuration, so that we can test out?

 

[Efried]

From what you described,  you have a PLC board doing WEBSET to a BRE board. When the BRE board lost connection, PLC board stuck on the WEBSET, not moving forward with next WEBSET request.  Is that correct description?
 
We checked our code, if PLC board failed to make connection to the HTTP server after six seconds, it will abandon that WEBSET request.  Are you sure you do not keep sending new WEBSET to that BRE board?
 
Could you please provide us a test case with your minimum PLC code and your WEBSET configuration, so that we can test out?

Thanks a lot.
I'm trying to give metacode.
The PLC changes OP on the BRE every  20s or so via WEBSET
The PLC updates operational status requesting info from a server every 10 Minutes via WEBSET
 
I'm testing if the WEBSET to the BRE WC is stuck after waiting 750 ms at max, but it is always if I use
    TSTEQ WSRPLY 0  
 
may be the return from the BRE WC is not good? Via browser it works
http://192.168.0.13/setoutps.cgi?0000W11=TTL1+ON0 , trailing 0 is resulting from the WEBSET syntax.
  
 
thanks

 

[CAI_Support]

Please unde4rstand WSRPLY must be formalized in certain format by your server CGI code.
BRE firmware does not respond to WSRPLY, nor PLC firmware,  Checking that from WC boards will always no use.
 
The purpose of WSRPLY is for your server to send in commands, so that PLC logic can branch to a different action based on server reply.
BRE board has no way to know what you want PLC to do next, nor PLC firmware, thus they do not reply at all.

 

[Efried]

Please unde4rstand WSRPLY must be formalized in certain format by your server CGI code.
BRE firmware does not respond to WSRPLY, nor PLC firmware,  Checking that from WC boards will always no use.
 
The purpose of WSRPLY is for your server to send in commands, so that PLC logic can branch to a different action based on server reply.
BRE board has no way to know what you want PLC to do next, nor PLC firmware, thus they do not reply at all.

Sure BRE replies with a web page receiving the old style SET  OP command via GET.
But even if it is as you described, then there is no way to check whether single WEBSETs will congest others? 

 

[CAI_Support]

WSRPLY requires a special format reply.  Please read programming guide on our web site for how to format that WSRPLY.
If the reply is not in that format, WEBSET command will ignore it.  Moving on to next one in the queue.
 
I am not sure understand what do you mean by "congest others"?  Your PLC program determine how often to send requests.  Your original post saying the WEBSET failed.  I am not sure seeing that.

 

[Efried]

WSRPLY requires a special format reply.  Please read programming guide on our web site for how to format that WSRPLY.
If the reply is not in that format, WEBSET command will ignore it.  Moving on to next one in the queue.
 
I am not sure understand what do you mean by "congest others"?  Your PLC program determine how often to send requests.  Your original post saying the WEBSET failed.  I am not sure seeing that.

 
ok, thanks . that explains the problem,  wrong return format obstructs my communication status check. webset fails uploadind data to the server since the status change on the second wc via webset is congesting the communication stack.

 

[CAI_Support]

I do not truly understand the part "webset is congesting the communication stack".
Would you please elaborate which communication stack WEBSET congested, please provide more detailed information about the congestion, so that we can help you.

 

[Efried]

I do not truly understand the part "webset is congesting the communication stack".
Would you please elaborate which communication stack WEBSET congested, please provide more detailed information about the congestion, so that we can help you.

Ok next try:
 
LOOP
Calculate time interval and OPs for the two WCs
Wait 10-30 secs
WEBSET OP1 on WC2
WEBSET OP2 an WC2
each ten minutes
WEBSET Server
WEBSET OP3 on WC2
ENDLOOP
if the WC2 is dead, then the Server is not receiving data...

 

[rossw]

Ok next try:
 
LOOP
Calculate time interval and OPs for the two WCs
Wait 10-30 secs
WEBSET OP1 on WC2
WEBSET OP2 an WC2
each ten minutes
WEBSET Server
WEBSET OP3 on WC2
ENDLOOP
if the WC2 is dead, then the Server is not receiving data...

 
From my feeble understanding of things, and given CAI have already said that the stack clears/purges itself after some 6 seconds, I would suggest you rewrite your code such that the webset to "Server" is not attempted within 6 seconds of a write (or attempted write) to WC2.
 
There are many ways to do this, but I'm sure you'll either figure it our, or demand someone re-write the WC code for you.

 

[Efried]

From my feeble understanding of things, and given CAI have already said that the stack clears/purges itself after some 6 seconds, I would suggest you rewrite your code such that the webset to "Server" is not attempted within 6 seconds of a write (or attempted write) to WC2.
 
There are many ways to do this, but I'm sure you'll either figure it our, or demand someone re-write the WC code for you.

thanks so much for the hint. From my first code walk through there is a pause before the server is addressed. For the process however sometimes I cannot wait more than the minimum time of 10 sec. in some cases before addressing the second WC.
I have to do more communication analysis to prove that, but would prefer having the ordered new WC32 with a purge stack function.

 

[rossw]

 For the process however sometimes I cannot wait more than the minimum time of 10 sec

 
The problem appears not to be the wait time before accessing the second WC, but AFTER accessing it and BEFORE accessing the server.
Sounds to me like you need to work on your code. There are any number of ways to achieve stability under the conditions you are struggling with.
 
Rather than expecting CAI to implement a "purge stack" command that will be useful to perhaps exactly ONE customer, you'd be better trying to convince them of the value of user-defined timeout periods. There are times 6 seconds may be too short, just as you claim it's too long. Sounds to me like the far better solution would be for some arbitary but user-specified timeout.