BRX Looses Comms, No response to DmD, Modbus TCP

[Mike@Forshock]

Understood.
The unfortunate reality of radio, it will go down at times.  When first deployed it was great, then houses were built everywhere and short of a 40ft+ tower we are not getting over them and there are powerlines directly over the site 

Good hunting!

FYI: Reboot instruction added and brought devices back online.

[BobO]

I do see something that bothers me a bit at one of the lower layers (there's like 5 layers). I don't know for certain that it's an issue, but I'm also not certain that it isn't, and it was changed at some point in the last few years. Developing...

[BobO]

Not recent. The thing I found was changed in Do-more 1.3.

Might still be a hole though, but not new.

[Mike@Forshock]

Thanks for the update and for getting testing started quickly.

[BobO]

Thanks for the update and for getting testing started quickly.

It's entirely possible that this is an old problem that has only become obvious due to your network infrastructure changes/issues. If we can find a way to duplicate it, we can feel much better about the fix, so that is the focus for now.

[www.SystemsIntegrator.mobi]

Yes wireless links are bad

Run two do-mores sending two data streams and two wireless links  if the pump cant be off for the 5 seconds it takes to reboot 

This will also test for a hardware failure in case this is a new symptom and you will now have something to test the old system against



Having two systems you can use the instruction for failed communications to enable the second system just like our eastern pipeline should have had before it got hacked

"ST153
 $EthMasterError
 Status
 Will be ON when the Ethernet I/O Master detects an error with one of its Ethernet I/O Slaves - most likely an Ethernet I/O Slave is offline
 "
When ST153 is on enable 2nd Do-more System

If not used contact on PING error

"Colonial Pipeline Cyber Attack: Hackers Used Compromised ...
https://www.bloomberg.com ? news ? articles ? hackers...
Jun 4, 2021"

"Two is one....one is none"

This is used in Marine's training

"https://www.forbes.com/sites/work-in-progress/2011/06/21/two-is-one-and-one-is-none/?sh=559c7d968a8c"



Here is how to program it and two professional examples of how and why it should be used 

[Mike@Forshock]

Yes wireless links are bad

Run two do-mores sending two data streams and two wireless links  if the pump cant be off for the 5 seconds it takes to reboot 

Not sure how that helps in any way?

Links are not down for long durations, simple low quality (retries).
The DoMore running the comms is the PLC controlling the well output (locally).  When it reboots, the relay drops.  It is unaffected by the wireless link.

At this time DoMore does not support "native" hot-standby, so sending two commands from two units across two wireless links is asking for command collisions.

[Garyhlucas]

Why not latch the relay and add a second output to unlatch when you want the pump to go off? Reboots won?t shut the pump down.

[RBPLC]

Potentially related to this topic and the previous topic with the non-responsive Modbus/EIP comms that was attempted to be addressed with the latest firmware:

I hooked a system up this morning with a BRX serving as an EIP slave to an BRX EIP master (whatever the correct terminology is for explicit EIP master/slave relationship). The master has been powered on for about two months and the slave has been powered off during this time. I reapplied power to slave. Could see the slave immediately in DmD but the master explicit EIP messaging was unresponsive. Power cycled the master and comms to the slave came back immediately. Seems like a continuation of the seemingly "fixed" problem from a little while back.

[BobO]

Potentially related to this topic and the previous topic with the non-responsive Modbus/EIP comms that was attempted to be addressed with the latest firmware:

I hooked a system up this morning with a BRX serving as an EIP slave to an BRX EIP master (whatever the correct terminology is for explicit EIP master/slave relationship). The master has been powered on for about two months and the slave has been powered off during this time. I reapplied power to slave. Could see the slave immediately in DmD but the master explicit EIP messaging was unresponsive. Power cycled the master and comms to the slave came back immediately. Seems like a continuation of the seemingly "fixed" problem from a little while back.

The most recent corrected issues are related to adapter routing, and were a side effect of adding the new ECOMEX. As far as I know, those are all resolved.

With regard to the Modbus client instructions not completing, there are a couple of possibilities as to why that might be happening, but so far we've been unable to duplicate it. I am nearly certain we can come up with a fix, even if it is a higher level bandaid, but I would prefer to dupe the problem and determine exactly what isn't working right first. I know that as users it really doesn't matter as long as it works, but I'm never confident I've fixed an issue until I understand the issue.

[RBPLC]

With regard to the Modbus client instructions not completing,

I'm assuming EIP messaging would also be affected?

[BobO]

With regard to the Modbus client instructions not completing,

I'm assuming EIP messaging would also be affected?

Depends on what the cause is, but likely yes. The issue is almost certainly in lower level code that would be common to both.