Does PNPSCADA support Schneider Meters
sdg.marinusvz
2013-05-16 17:32
Last Edited 2025-09-01 17:14
*** UPDATE: Yes, we do, and we also optimized the comms for GPRS so that it is now also practical. You can put a modem directly on the RS485 network, so you don't even need a TCP/485 converter (provided there are no other masters on the 485 network to confuse the comms) ***
Can your system work with Schneider meters?
We've had a few requests from building that are already on AMR with Schneider meters and they want to know whether we can take over the management thereof.
I'm going for a meeting with the guys shortly and I want to be ready for the meeting.
sdg.marinusvz
2019-01-23 13:55
Are you going to put down a PNPSCADA server at these sites?
Reason I'm asking: usually the guys from Schneider wants you to receive the data from their own on site server. (e.g. from a Microsoft SQL Database or something like that)
The real reason for that is that to read profile remotely for the Schneider meter is very inefficient. The profile is generally kept at 15 minute intervals, and to read every interval is a separate Modbus transaction. On a local network this can be nice and fast, since those Modbus messages can fly very quickly, you can easily get hundreds through per second, but if you have a ping time of 1.5 seconds on GPRS from a remote server, for example, it means that reading one day of data from one meter will take you 96x1.5s = 144s (2 and a quarter minute?). So, if we assume you have 200 meters on an RS485 network, which means you can only read one meter at a time, and if you have to download a month's worth of data (lets say 30 days); then it will take you 200x30x96x1.5s = 864000seconds, which is 240 hours, or 10 days!! (more than a week).
So, they will give you fancy reasons why you should use their server, which they might even believe themselves, and you will really struggle to get the protocol/register mappings from them to do this reading (I found by chance it uses the same protocol that is used to download a profile from a Schneider relay on the internet); but in the last analysis, the real reason why this expensive Schneider meter is such a bad meter for remote meter reading, is the above reason, that it just simply performs too terribly, if your transaction turnaround time is not extremely fast. The Schneider meters was never designed to be read remotely.
So, we've done the most difficult part of the work to integrate this protocol to PNPSCADA, but we haven't had a customer yet that wanted to read it directly, because of above reason.
I know we've got another Reseller with an agreement with Schneider to send through a CSV file automatically periodically, with the data. We can then upload that data into PNPSCADA, in case you're interested. At the end of the day that would probably perform better. Except if you want to put down a PNPSCADA server physically on site, in which case we can put the Schneider code in place, and you can read the meters directly.
I will advise, however, that you only do this if Schneider doesn't already have a master on that RS485 network that keeps it very busy (we can, of course, go through a Modbus TCP gateway, which can synchronize multiple masters over the same Modbus RTU medium, but the point is that the medium might already be very busy, because of Schneider's inefficient profile protocol)
Tags: modbus
sdg.marinusvz
2015-09-15 15:22
This has now been implemented and is supported by PNPSCADA.
We have also been able to put in a 10x optimization on the profile readout, so remote meter reading on a high density site with a lot of this meter on one RS485 network is now more viable than before.
For more details, see:
http://wiki.pnpscada.com/showthread.php?425-Schneider-PM3255-support
sdg.marinusvz
2025-09-01 17:19
Transcribed from a support call:
Do you support these meter by any chance?
Scheider PM2200, PM5100, IEM3255 and IEM3155 all panel meter.
Answer:
If you need us to develop a connector for the Ion type meters, pls provide us with a sample, so we can test it.
The main problem with the PM2200 and PM5100 is that people normally configure them as Modbus TCP to Modbus RTU gateways, which means to read them you have to address them by static IP from the HES. This is usually problematic, since you basically have to have some kind of a static IP on an edge device on site, and do port forwarding to the meter (from the HES/pnpscada). Then once you can connect to it, on TCP, for Modbus TCP, you can basically multidrop from it to a bunch of 3255s on a local RS485 network.
If you want to put an RS485 modem on its RS485 network in order to read even the PM2200 and PM5100 through Modbus 485, you would have to configure the meter specifically as a Modbus Slave device (in most cases, if it is configured as a Gateway, it would be set as a Modbus Master on the RS485 network).
In the past we have not had someone request the development of protocol drivers for Ion Schneider meters, since it is so much more expensive than the 3255, and they are usually installed like with 1 on a site, or perhaps 3, for a big shopping center, on a LAN. So the market did not support it. However you can still configure them as a Generic Modbus meter on pnpscada, however you'd need to make sure you solve the addressability issue. If the customer also wants to read it via other systems, that would be fine, but then you can't mess with the status of the meter in terms of master or slave, so you'd need to install that edge device to get onto the local LAN of the site, to directly access the meter via TCP/IP - with all the potential problems dealing with their IT department.
The nice thing with a Modbus TCP gateway situation, is that you can have multiple masters, since access is synchronized internally on the RS485 per TCP connection to the gateway. So the client can still do what he normally does, and you can add remote reading to the mix without too many problems (he might be keeping the RS485 network ridiculously busy with lots of real time readings... however your remote access should still be able to read good enough for monthly billing, most of the time, IMHO).