News:

  • October 12, 2024, 03:14:38 PM

Login with username, password and session length

Author Topic: BRx HTTPCMD failing  (Read 273 times)

EliWaldner

  • Jr. Member
  • **
  • Posts: 16
BRx HTTPCMD failing
« on: September 24, 2024, 12:22:52 PM »
Hello,
We are running into an issue where the HTTPCMD instruction keeps failing. Would anybody have any recommendations or remedy for the issues in the attached screen shot....?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: BRx HTTPCMD failing
« Reply #1 on: September 24, 2024, 12:34:38 PM »
Hello,
We are running into an issue where the HTTPCMD instruction keeps failing. Would anybody have any recommendations or remedy for the issues in the attached screen shot....?

Might be taking too long in the PLC and the server is timing out. The default TLS timeslice is 1500us, but can be increased to dedicate more time to the effort. Bottom center of the CPU Configuration page in the System Configuration dialog. Raise it to 3000us and see if it gets any better.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

EliWaldner

  • Jr. Member
  • **
  • Posts: 16
Re: BRx HTTPCMD failing
« Reply #2 on: September 24, 2024, 12:45:45 PM »
Thanks for the reply! We have already increased the TimeSlice to 5000. Did not seem to help. Still keep getting the same error. What causes the "Device driver error- $DriverError (ST143)"?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: BRx HTTPCMD failing
« Reply #3 on: September 24, 2024, 01:22:26 PM »
Thanks for the reply! We have already increased the TimeSlice to 5000. Did not seem to help. Still keep getting the same error. What causes the "Device driver error- $DriverError (ST143)"?

That is a general failure that gets set any time a driver-centric instruction (like HTTPCMD) fails and sets the On Error state instead of the On Success state.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

EliWaldner

  • Jr. Member
  • **
  • Posts: 16
Re: BRx HTTPCMD failing
« Reply #4 on: September 26, 2024, 10:53:53 AM »
I don't think it is a time out issue.......? But I will let myself be corrected if needed. How do we fix the "SSL/TLS handshake failed" problem (see the attachment)? Is it possible that we are using this ethernet port for too many instructions? We are using it for 4 HTTPCMD, 3 MQTT, and 25 MRX/MWX instructions. Plus communication to an InduSoft SCADA. I would think a single ethernet port should be able to handle that? Just throwing ideas out cuz I do not know what else to try anymore?

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6040
  • Yes Pinky, Do-more will control the world!
Re: BRx HTTPCMD failing
« Reply #5 on: September 26, 2024, 11:28:13 AM »
I don't think it is a time out issue.......? But I will let myself be corrected if needed. How do we fix the "SSL/TLS handshake failed" problem (see the attachment)? Is it possible that we are using this ethernet port for too many instructions? We are using it for 4 HTTPCMD, 3 MQTT, and 25 MRX/MWX instructions. Plus communication to an InduSoft SCADA. I would think a single ethernet port should be able to handle that? Just throwing ideas out cuz I do not know what else to try anymore?

The issue certainly isn't Ethernet bandwidth, but when there are TLS handshake issues it is frequently that the PLC can't compute the crypto stuff fast enough to satisfy the server. That's why we allow you to increase how much time is dedicated to the handshake.

A Wireshark trace might give some insight whether the server is dumping the PLC, which is frequently the issue. BRX only supports up to TLS 1.2, so if the server is forcing TLS 1.3, that could also be an issue.

The IT world routinely sets standards that OT can't adhere to. Small embedded systems simply don't have the memory or computational power that PCs do. It's a real problem.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO