HTTPCMD Occasionally Stops Working With ST143; Can't Reset

[belias]

Hello,

I have a stage program that runs HTTPCMD to parse a JSON response.  It works great for months at a time, but occasionally will stop working and sets an ST143 error each time the initial HTTPCMD stage is called.

When this happens, I've set an "error handler" program that runs a DEVCLEAR on the associated TCP device, but that doesn't resolve it.

At this point, the only way I've found to fix the problem is to either use the menu item for PLC --> Re-Initialize PLC I/O, or to power-cycle the PLC.

Since it's not critical, I've left it in the error condition for now, hoping that someone has a suggestion I can try that programmatically clears it.  I have confirmed that the JSON response is valid.


Any suggestions would be greatly appreciated.



Thanks.

[ATU]

i know this is a stupid question, but do you clear the ST143 bit?

[belias]

Not stupid at all, and thanks for the reply.

Yes - the "PLC Error Handler" program responds to ST143 by first running the DEVCLEAR (which runs successfully) and then resetting the ST143 bit.

The JSON response program then runs again a few minutes later and the process repeats.  The JSON program stops at the HTTPCMD for about 30 seconds and then fails with a JMP to Error Stage.  The response status code in HTTPCMD remains at 0.

I'm confident the underlying programming is OK, since it runs for weeks to months at a time between issues, and I'm sure that if I reset the PLC it will return to running normally.

[BobO]

First thing to do is turn on debug dumping and run DMLogger, and see what's going on when you do the HTTPCMD.

Enable debug dumping by setting $EnableMsgDump (ST36) and set $SysMsgLevel (DST61) to 2.

Some folks have had Windows firewall issues with DMLogger, so you might have to disable it or make sure the appropriate ports are being passed.

And make sure you are running 2.8.5 firmware. There have been some HTTPCMD fixes along the way.

MSG and LastMSG0-7, ERR and LastERR0-7 will also retain part of the message dump contents if you can't get DMLogger going. I'll just throw those in a DataView sometimes and that might give enough info.

[belias]

Thanks for the quick reply.

I was able to connect with DMLogger and it shows PING and DNS lookup completing, but then times out on HTTP.

Just to confirm I copy / pasted the URL into a browser on a PC on the same subnet (using same DNS, etc.) and was able to receive a normal reply.

I'm using FW 2.8.3...I was hoping to try and figure this out before updating / rebooting (which I'm sure will solve it).  FYI, I don't see 2.8.5 as available.


Any ideas would be greatly appreciated.



Thanks,

Brian

Code: [Select]

192.168.12.110  Port 29298(0x7272) 01:20.7 Operation timed out in HTTPCMD @00000DB7

192.168.12.110  Port 29298(0x7272) 01:20.7 HTTP disconnected!

192.168.12.110  Port 29298(0x7272) 01:20.7 Disconnecting HTTP...

192.168.12.110  Port 29298(0x7272) 01:20.7 Timed out! Disconnecting HTTP...

192.168.12.110  Port 29298(0x7272) 01:16.8 PINGRESP received

192.168.12.110  Port 29298(0x7272) 01:16.8 Sending PINGREQ

192.168.12.110  Port 29298(0x7272) 00:54.4 Received PUBLISH for /HSPLC/FL2HVAC

192.168.12.110  Port 29298(0x7272) 00:54.4 Received PUBLISH for /HSPLC/EntryLock

192.168.12.110  Port 29298(0x7272) 00:50.7 Connecting to HTTP server...

192.168.12.110  Port 29298(0x7272) 00:50.7 DNS lookup complete

192.168.12.110  Port 29298(0x7272) 00:50.7 Beginning DNS lookup...

192.168.12.110  Port 29298(0x7272) 00:47.6 PINGRESP received

192.168.12.110  Port 29298(0x7272) 00:47.6 Sending PINGREQ

[BobO]

I was thinking that 2.8.5 was the latest, but it may be 2.8.4. Regardless, I checked the source and didn't see any changes specific to HTTPCMD from 2.8.3 on, so firmware may not help. There were some changes to the TCP/IP stack to correct issues related to ECOMEX routing.

The next thing I would try is to get a Wireshark trace to see if the PLC is actually sending out the TCP commands to open the connection. That may be more complicated than you are willing or able to attempt. Major issue being that if you don't have a switch capable of port mirroring or some other packet capture capability, you probably won't be able to 'see' the PLC's packets.

[belias]

I was able to grab a Wireshark trace.  I filtered by the IP of the PLC, and then filtered by the IP of the gateway.  The only traffic between the two during the time when HTTPCMD was running is a DNS Query and a DNS Query Response.

Those 2 entries are also the only ones found when I do a string search for the URL.

I can PM you the Wireshark file if that's helpful.

[BobO]

I was able to grab a Wireshark trace.  I filtered by the IP of the PLC, and then filtered by the IP of the gateway.  The only traffic between the two during the time when HTTPCMD was running is a DNS Query and a DNS Query Response.

Those 2 entries are also the only ones found when I do a string search for the URL.

I can PM you the Wireshark file if that's helpful.

Probably won't give me anything more, but I'd like to see it.

[belias]

Thanks.  Just sent PM.