News:

  • September 23, 2026, 12:41:02 PM

Login with username, password and session length

Author Topic: POM Ethernet Module  (Read 11320 times)

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
POM Ethernet Module
« on: April 09, 2020, 09:33:18 AM »
Would the POM Ethernet module have less of an impact on the system overhead than the Ethernet native port? I am using multiple interrupts in an application and timing is ultra critical. I believe Bobo said that it was basically a serial module. I was thinking of changing to a serial port going to the HMI, but having the Ethernet connection is much cleaner and convenient.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: POM Ethernet Module
« Reply #1 on: April 09, 2020, 11:31:14 AM »
Would the POM Ethernet module have less of an impact on the system overhead than the Ethernet native port? I am using multiple interrupts in an application and timing is ultra critical. I believe Bobo said that it was basically a serial module. I was thinking of changing to a serial port going to the HMI, but having the Ethernet connection is much cleaner and convenient.

Yes, the ECOMLT is significantly lower load. The CPU to ECOMLT is a 1MB serial connection. Slower than the onboard, but more than adequate for programming and HMI.

We are actually considering creating a 2nd Ethernet POM that would be focused on master side comms. The ECOMLT is just a slave, so it can't do some of the master things that people would like. Mastering is a very different problem, but one that we can probably do with the right hardware.
"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

ATU

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 2126
  • YKPAIHA
    • ATU, Inc.
Re: POM Ethernet Module
« Reply #2 on: April 09, 2020, 11:59:59 AM »
Thanks! I think having a 2nd more capable Ethernet port would be very useful, especially if your native port is working with time critical I/O

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: POM Ethernet Module
« Reply #3 on: April 09, 2020, 12:16:02 PM »
Thanks! I think having a 2nd more capable Ethernet port would be very useful, especially if your native port is working with time critical I/O

We'll see what more capable means. It may just be different capabilities, but master side rather than slave. I would expect remote I/O master to be one of the possible new abilities.
"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

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3626
  • Darth Ladder
Re: POM Ethernet Module
« Reply #4 on: April 09, 2020, 01:09:37 PM »
We are actually considering creating a 2nd Ethernet POM that would be focused on master side comms. The ECOMLT is just a slave, so it can't do some of the master things that people would like. Mastering is a very different problem, but one that we can probably do with the right hardware.

Ooh, that's going to be good for me!    I have one application for using a BRX as a firewall & router to another BRX, and one port needs to email and be a Modbus slave and the other needs to master.  No can do with the current POM.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: POM Ethernet Module
« Reply #5 on: April 09, 2020, 01:33:05 PM »
Ooh, that's going to be good for me!    I have one application for using a BRX as a firewall & router to another BRX, and one port needs to email and be a Modbus slave and the other needs to master.  No can do with the current POM.

ECOMLT has been a big help for redundant servers, but we've kinda struck out with some of the mastering functions. I am inclined to think single function mastering will be a slam dunk (like RIO), and minimal mastering ought to be good. By minimal, I mean a selected subset of masters. We'll see how robust that subset is. It might even not be a subset of available master functions as much as an upper limit on how many at once. Time will tell, but I like the odds.

"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