Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: plcnut on June 25, 2025, 10:34:48 AM
-
Hello Gentlemen! Long time no see.
I am working on a new system with a BRX (BX-DM1E-36ED23-D), and am trying to use the Ethernet POM for an EtherNet/IP connection to a Murrelektronik Premium EtherNet/IP IO-Link master (54631).
I am able to make the pieces work just fine using the OB (on-board) Ethernet port of the BRX, but I have not been able to make it work using the POM.
I have the OB port and the POM on two separate subnets, but they are both connected to an unmanaged switch while I am testing.
NetEdit shows that both the POM and OB have the same IP address (See screenshot).
This happens even though the POM is on a different subnet.
Any Ideas on what I may be doing wrong?
Also, I would really like to turn up the RPI for the EtherNet/IP adapter to be faster than 10ms. I was curious why the 10ms limit.
Thanks!
- Attachments and other options
-
Been a while!!
NetEdit is showing the PLC's internal port settings, not the POM. This is because NetEdit is just for manipulating the IP setup data for internal ports. The ECOM-EX is a secondary NIC on the one-and-only IP stack in the PLC, it is not a coprocessor with it's own stack. It's confusing and unfortunate, but not easy to fix.
-
Also, I would really like to turn up the RPI for the EtherNet/IP adapter to be faster than 10ms. I was curious why the 10ms limit.
Because we would struggle to maintain any determinism at that rate. At best it will take multiple PLC scans and given the IP stack overhead the fastest would likely be 3 or more ms.
-
Been a while!!
NetEdit is showing the PLC's internal port settings, not the POM. This is because NetEdit is just for manipulating the IP setup data for internal ports. The ECOM-EX is a secondary NIC on the one-and-only IP stack in the PLC, it is not a coprocessor with it's own stack. It's confusing and unfortunate, but not easy to fix.
Ok. That makes sense.
Is the EtherNet/IP connection supposed to work over the POM? Or did I misunderstand the documentation?
Because we would struggle to maintain any determinism at that rate. At best it will take multiple PLC scans and given the IP stack overhead the fastest would likely be 3 or more ms.
That is what I thought. It would be nice to push the envelope a bit though... I understand why you have to do what you do.
-
Is the EtherNet/IP connection supposed to work over the POM? Or did I misunderstand the documentation?
Yes, it should. It is not?
That is what I thought. It would be nice to push the envelope a bit though... I understand why you have to do what you do.
It would take a coprocessor. Always a balance of free vs high performance.
-
Is the EtherNet/IP connection supposed to work over the POM? Or did I misunderstand the documentation?
Yes, it should. It is not?
It is not working with the POM.
-
It is not working with the POM.
How is it failing?
Have you Wireshark-ed it?
Can you show your IP config for both ports as well as the config for your target device(s)?
-
Here are screenshots of the settings and config.
I am working on Wireshark now.
BTW: It works perfectly if I swap the IP addresses of the POM and OB ports.
-
Put a non-empty netmask into the POM and don't specify a gateway. It is a single shared stack, multiple gateways are not supported, so routed traffic goes to the first configured one.
-
Put a non-empty netmask into the POM and don't specify a gateway. It is a single shared stack, multiple gateways are not supported, so routed traffic goes to the first configured one.
That was it!
I must have fat-keyed the mask and never noticed it was wrong.
Thank you so much!
-
That was it!
I must have fat-keyed the mask and never noticed it was wrong.
Thank you so much!
Technically that might have worked. 255.255.255.255 defines a network of just the host, where everything outside of it must be routed. Specifying your EIP adapter as the gateway would be a creative (if unconventional) way of creating a point to point. However with our single stack, only the first gateway is relevant, so no.