BRX to H2DM1E peer to peer error

[JeffS]

I have a BRX running firmware 2.9.9 and communicating over ethernet to a H2DM1E also running 2.9.9 and keep getting a peer to peer RX error:

Received DMPP error response from server in RX @00006B75

Initially the BRX was running 2.7 firmware and the H2MD1E was running 1.4 giving the same error so I updated both to latest.  I have since rebooted both PLCs but the errors persist and all RX/WX from the BRX to the H2DM1E fail.

Any ideas what could be causing this?

[rlp122]

Got a lot of Data Views running or multiple programs using the Ethernet port or possibly you are running over VPN or Modems?  Offhand guess is a Ethernet resource issue.  25 pounds of potatoes in 5 pound sack.  It takes a lot less to fill up an Ethernet stack than what you probably think it does.

[franji1]

Post a screen shot with status of the RX instruction causing the error.  Zoom in so the status/elements are larger and more readable (Ctrl+Mouse wheel).

[JeffS]

These two devices are on the same local network together.

There aren't many other devices talking to this particular PLC so I really don't think it is overloaded.  I have other locations that the same PLC is talking successfully with many more BRX and H2DM1Es.

Let me know what else you might need.

[franji1]

The requests looks good.

Subnet Masks are set properly for both PLCs (they both are on the same subnet, e.g. both are 10.x.x.x or 10.52.18.x or whatever)?
Default (no) Password on remote PLC can READ DATA?
Any wireless comm or strange networking?
Can Designer talk to both with Designer PC on the same subnet 10.52.18.x/whatever?
What is the DMPP Timeout settings for your BRX?
What are the PLC scan times for the BRX and for the 205?
I presume you rarely are JMPing out of that Stage since you are polling the PLC (not edge-triggered).  If you JMP out BEFORE it finishes, you will get errors (this is true regardless of polling or edge triggered, but errors can happen more easily when it's polling).

White List is for the Slave/Server side, which is the 205, which does NOT support White List, so that's not it.

[franji1]

EDIT - THIS IS SECONDARY TO YOUR COMM ISSUE ASSUMING YOU AREN'G JMPing OUT FREQUENTLY (if you ARE JMPing out too soon, you will get errors all the time)

Some more detail on the polling RX instruction.

You probably want to drive the RX with some condition that is initially ON
// upon entry to S3, turn on C100
STRPD S3
SET C100

STR C100
RX

Then, when you want to transition OUT of the stage, turn OFF C100
STRPD whatever condition to exit stage
RST C100

don't JMP until you see C100 OFF and either Success or Failure ON - let it take however many PLC scans for the polling RX (up to a second?) to finish THAT poll
STR C3751
OR C3752
ANDN C100
JMP S4 // or wherever

[BobO]

Another approach is to use two stages. Poll in one, which jumps to the second when complete, then jump back to the first as long as you want to poll. When you are done polling, don't jump back.

[JeffS]

So this stage with the RX actually stays on all the time, unless it fails for a minute straight.  Then I reset this stage and then attempt to ping the device.  If the ping succeeds I return to this stage and will attempt to talk to it continuously.  If it fails for a minute, then repeat the process.

So currently I am getting 60 some odd errors before I reset the stage, wait a minute, then ping the device, and if successful proceed to talk to it every second.

@IntEthDMPPClient Settings haven't been altered from default.

DMPP ACK timeout is 50ms
Command Timeout 250 sec?
Retries 2

Pings show a 4ms round trip.
7.5ms avg scan time on the initiating BRX.
0.5ms avg scan time on the 205 domore.

And it was at this point I found that for some odd reason, this particular PLC had Default with No permissions... No idea how that happened.  I fixed this and now it is talking. 

The only thing I found that was strange with this particular PLC was that the dip switches had a few set on.  Any of these switches affect the PW permissions in some way?  Doesn't look like it from the manual.  It had DIP 0, 2, 5 ON.

Thanks for the help sorting this out, and I look forward to hearing if the dip switches could possibly cause this.

[franji1]

And it was at this point I found that for some odd reason, this particular PLC had Default with No permissions... No idea how that happened.  I fixed this and now it is talking. 

That would do it.  You shut out anything that doesn't know the secret handshake.  That was done for a reason - I wouldn't change that.

I would recommend adding a "Remote PLC" user password in your 205 that ONLY has permissions to Read Data and Write Data (RD and WD, NOT the program).  Then have your BRX use that "Remote PLC" password in its RX/WX instruction.  Designer would not even be able to connect to your 205 with that specific "Remote PLC" password since it requires (minimally) Read Program and Read Data in order to establish a session with a PLC (yes, it does not have to be able to Write to the program or data, think MONITOR ONLY user).