PM8000 ethernet daisy chain advantage?

[sesa272464]

Has anyone used the PM8000 Ethernet daisy chain capability? Would anyone recommend that over using the 2 wire serial daisy chain?

I have a customer that is planning on purchasing a bunch of these PM8000s.. wondering if I should suggest them daisy chaining the groups of meters together or just use 1 as a gateway and serial daisy chain the rest.

From my understanding - using the Ethernet daisy chain is basically using all the meters as Ethernet devices connected to a switch or hub, but we just no longer need the hub.

[Hal_Etheridge]

From a software perspective the difference in effective bandwidth is massive.  If you use a serial loop the bandwidth is capped at the baud rate of the loop.  With ethernet not only is the bandwidth considerably higher but if a single device is having problems (out of service, slow to respond, etc) it does not impact the performance of the other devices.  The difference in usable bandwidth is likely several orders of magnitude.  The effective bandwidth in practice will not be that much but it is still considerable.

Given the amount of log memory on the latest generation of devices using them on a serial loop is probably not going to result in an enjoyable experience if you use all the features of the device.  The raw bandwidth available on a serial loop just is not enough to download the logs for more than one or two devices.

If you value fast alarm updates, fast log updates, large amounts of log records available then go with a pure ethernet based system.  It will also likely be cheaper to install because there will be minimal debugging of an ethernet based network compared with serial and everyone is familar with how to plug in an ethernet cable vs wiring a serial RS485 port.

[sesa272464]

Another question I had was - what is the appropriate gateway to use if we were to use a comm gateway instead of using the onboard Ethernet as the main gateway?

Would it be egx? lantronix? or comx510?

I was told that the PM8000s have the same ION type feature so using an EGX essentially remove those ION features from the meter?

[sesa256952]

While having every single meter connected directly to an Ethernet port seems enticing, there are some possible downsides to consider:

1. IP addresses are a finite resource. We are typically given a subnet of a fixed size.
2. The more Ethernet devices there are on a network segment, the greater the chance of collisions that will limit the effective bandwidth. This is because Ethernet is a non-deterministic peer to peer network.
3. If the network uses wireless protocols, then effective bandwidth by comparison to the posted bit rate is often as low as 10% and that's assumeing you are able to use the best modulation scheme available ( say QAM256 and not something like FSK).
4. Protocols all add overhead to data transmissions that reduce the effective data throughput. Ethernet uses up a percentage of a packet, then TCP/IP goes on top adding overhead and then we add Modbus over that as a minimum. If the data packets are small, then the overhead can be a far greater percentage of the actual packet than the data.
5. We are often given a VLAN and this makes it look like we have a dedicated network for our use. In reality we are sharing a backbone with a number of other VLANs and this will impact our throughput. It is especially true when various throttling mechanisms such as QoS are in place that provide higher priority to other VLANs. In essence, network managers can turn a 100BaseT network into something that is effectively more like a 1BaseT or slower if they like.
6. Our devices are typically 100BaseT and this is much slower than modern networks.
7. The response time of a meter to a request (AKA response delay) can also be a significant factor in throughput. This is especailly true in a master/slave network.
8. The ability of the operating system and our software to handle data transfers at or near wire rate comes into play. If the system is not capable of handling high speed communications, the network stack (software) will start dropping packets and this will require retransmissions that reduce throughout.
9. The factory is accustomed to wiring RS485 to meters in cabinets so wiring is not an issue for that.

Clearly, networking and data communications is not as simple as looking at raw bandwidths.

[Hal_Etheridge]

Some comments:

1. Agreed.  If this is a real concern then using NAT or other IT techniques can reduce the number of IP addresses required.  Generally the safest and fastest solution is to just get more IP addresses from the internal pool.  Note that power metering devices should **never** be on the internet as publicly available devices - they should always be on an internal network and protected by a firewall from general access.

2. Though technically a correct statement the reality is that, given the high bandwidth networks commonly in use today, this is basically a non-issue.  Back when I was adding the support for ethernet in the original 7500 meters 10MBit networks were the standard.  At the time a 7500 with full logging was measured to consume about 0.1-0.2% of the available bandwidth.  Modbus devices will use less than this in most situations.  For a 100BT network this percentage is 10 times less of course.  There are numerous articles in the recent trade press about using standard 100Mbit networks for plant *control* where not only is the available bandwidth important but also any network delays.  Our applications are much less demanding by comparison so there should be no issues for any reasonable system size.  If this is a concern then add more NIC cards to the server computer itself to help load balance the traffic as that is where all the requests converge.  Alternatively spec in 1Gbit or 10Gbit NICs for the server.

3. Agreed.  This is a limitation of the wireless physical network and not ethernet in general.  Being aware of the actual bandwidth available is definitely important.  I would be concerned if the traffic for your application is going to consume more than about 10-15% of the available bandwidth at any point in the network infrastructure.  At that point collisions and other congestion effects may become noticeable and may impact the overall reliability of the application.  It depends on what you are doing however.

4. Agreed.  The overhead of TCP/IP will roughly double the required bandwidth compared with looking at the raw modbus requests.  Unfortunately there is not much we can do about this.  Given 2) it is unlikely going to be an issue in practice though.

5. Same issue as 3.

6. Reality is that 100BT is so much bandwidth for our applications vs with a pure serial network it is hard to compare them.  Ethernet can process requests in parallel while serial is... well serial.  That fact alone makes ethernet based devices perform much better than any serial network ever could.

7. The response delay is definitely going to be a concern but this time will be roughly the same for both serial and ethernet based networks.  This time is mostly dependent on the device itself and not the network overhead.  Since ethernet based devices process requests in parallel relative to each other, any device delays that are present have much less of an impact on the overall system performance.

8. Agreed.  Server class OSes have been specifically tuned to reduce this issue.  In the very rare case where this *is* an issue there are registry key settings that can increase all the key TCP/IP stack parameters to address it.  This should never be an issue though in any but the very largest of system sizes (something like one in a thousand systems).

9. Agreed.  I would say though that there are more people familiar with wiring standard twisted pair vs RS485.  You could likely use twisted pair cable instead of RS 485 for short runs inside a cabinet with no ill effects.

Network design is definitely a complex topic.  For the vast majority of power systems though following the standard IT practices will give good results.  It is only when dealing with a device count in the range of several thousand or on very low bandwidth networks that special attention may be required to the network design.  Even then internally we have done tests on systems with over 5,000 devices with no noticeable issues.

Remember that a single computer downloading a few youtube videos will equal the bandwidth required to talk with a metering device for a whole *day*.  In the grand scheme of things metering devices use almost no bandwidth by comparison. 🙂

[sesa272464]

Given a scenario - with several meters in a daisy chain (serial and Ethernet):

With serial daisy chains when the meter in the middle of the chain is powered off or dies, it doesn't affect the meters in the rest of the chain since the serial loop isn't broken. If this was an Ethernet chain would the loop be broken if the meter is powered down or not functioning given that the 2 ports just simply act a switch?

[michael_franz]

We know that Ethernet is preferred over RS485 especially when using devices with large files like logs and waveforms on board.

It has been done for decades with CM2000, 3000 and 4000 meter and it works OK.  Just don't pull too much too fast or expect much over a radio or modem link.

The issue with Ethernet daisy-chaining is that when one unit, everything past it will go off-line.  This can be bad when doing maintenance.  A good industrial grade Ethernet switch is worth the money at that point.

Thanks,

Michael