MultiSmart Firmware version 2.3, incorporates a host of new and unique features in addition to enhancements to current functions providing operations the ability to reach new levels of productivity.

Impressive new features include:

• Data Logger Enhancements – There are several new Logging Features for Crisis, Interval and Configuration Logging. Interval Logs can optionally trigger DNP events. User interface has been greatly enhanced including saving logs to CF (config logs, IP address, serial number, MAC address, etc) and System Logs (var/log/messages).
• Alternation by Efficiency Enhancements – When the efficiency of pumps is within a configurable deadband, standard alternation is used instead of the N to 1 ratio.
• DuoProbe Upgrades – This marks the formal software release for support of the DuoProbe, including enhancements to DuoProbe operation and calibration.
• Maintenance Mode – A timer is now associated with Maintenance Mode. In addition, flow calculations are disabled during Maintenance Mode operation.
• Print Out Info Pages to Excel – With the push of a button, capture a snapshot of all values displayed on the Info Pages and save it to a .csv file, which can then be imported into Excel.
• Last Known Power Factor – This innovative tag reflects the last known power factor: You no longer need to wait until the pump starts in order to determine the power factor.
• Generations of DNP/MODBUS Log Files – The size of the protocol logs are now programmable with a configurable number of file generations. These logs can help troubleshoot communications issues.
• Pump Starts/Stops Independent of Level – This clever feature allows custom logic to take full control of pumps and is designed especially for PID applications.
• Probe Fail Indicator – The number of the failed sensor is now indicated which helps isolate Probe problems and reduce the amount of time it takes to troubleshoot the problem.
• WITS-DNP – This involves enhancements to DNP3 mandated by the UK water industry. There are some features which have been designed in a generic way so that they can be used outside of WITS. Exposure outside of WITS is scheduled for a future release.

Other notable improvements include:

• Restart MultiSmart Tag
• Disable a Running ISaGRAF Program
• Pump Reversals
• Single Sensor and Three Sensor Probes
• Ability to View Inhibit Status from Front Screen
• Max Starts
• Configurable Limit for IRT
• Pump Starts and Flow Based on Contactor Closure
• Strings Not Included in DNP Class 0
• Pulse Input Flow and Rain Gauge
• Station Low Flow Rate Alarm

Related Blogs:

New MultiSmart Data Logger Enhancements

New Alternation by Efficiency Enhancement

MultiSmart Firmware 2.3 – DuoProbe Features

Upgrading Firmware Versions

Downloading Firmware Upgrades

Sign Up to Receive Firmware Upgrade Notification Read more…

MultiTrode News Alternation by Efficiency, data logger, DNP, DNP/MODBUS, DNP3, DuoProbe, IRT, isagraf, Last Known Power Factor, Maintenance Mode, Max Starts, Modbus, Power Factor, Probe Fail Indicator, Probes, Pump Reversal, WITS, WITS-DNP

This follows on from the first blog post on DNP3 where we covered Date/Time Stamping – or Less Guessing - and a little bit of a comparison with Modbus.

This post is about some of the mechanisms for communicating between the SCADA, or master station, and the remote site. By the way, in DNP3 speak, you often hear the term “outstation” for the remote site. We’ll tend to stay with RTU (depending on who you talk to it either means “Remote Telemetry Unit” or “Remote Terminal Unit”), which is essentially the device that communicates.

 

Polling 

Let’s start with a Modbus comparison again, just to give a little context. Modbus is a totally polled environment – that is, the master station (typically a PLC) requests data from a site. The remote site can’t choose to send some data to the master station, it has to wait until the master requests it. So a very typical arrangement for a collection system is where the master PLC polls each lift station in turn and when it is has finished, starts again.

This has a lot of disadvantages as anyone with a growing network of lift stations has found. The time taken to get around the network goes up and up. You might get to a point where it’s 15 minutes between polls and decide to prioritize certain sites to get polled more frequently, or add a radio frequency (and therefore a new base station and repeater radio) to split the network into more manageable pieces.

It’s not an ideal situation, because Modbus isn’t an ideal telemetry protocol. (It’s a great protocol for other applications).

 

Unsolicited Reporting

If waiting until the master station asks you how you are doing isn’t the best way, what about unsolicited reporting. What’s unsolicited reporting? The remote site, also known as the RTU, sends data to the master station without being asked.

If you are used to Modbus polling systems, this might sound like anarchy. And if you have every site sending a message every time an event takes place, it could well be anarchy. Will the radio network stand up to lots of sites all trying to communicate at once?

The only way you might be able to prevent chaos, is by having a very limited amount of data getting sent, or a high radio bandwidth. One of the guys in MultiTrode told me about a system he was involved in with a previous company where they used unsolicited reporting for every event, and during a major storm the entire network shut down due to “collisions” in the radio network. The solution was for someone to go and visit every site and reset each RTU. Then the network started communicating again. But they lost all the data for their critical event.

That’s not great. What’s the solution?

 

Communication Choices and Different Classes

The DNP3 protocol has some great features to avoid the problems above.

Firstly, you can group events into different classes. Then secondly, you can choose how those different classes communicate from the RTU to the master station.

An example is the best way to explain it. Suppose you want to know about all high level alarms within 1 minute, and otherwise you are happy for all stations to be communicating at least once every 30 minutes.

You would put the alarm “High level” into class 1, and everything else into class 2. Then you would set class 1 to unsolicited reporting immediately. And class 2 you might set one of two ways – either to report every 30 minutes or sooner if the event buffer was full; or you might have the master station polling every 30 minutes.

Now you can find out immediately about high level alarms without risking the network turning into treacle and you still find out about all the changes in your network.

It’s the flexibility in DNP3 that is one of its great features. As Paul Gibson, one of the key people behind the development of the MultiSmart pump station manager, said:

“If we didn’t have DNP3, we’d be trying to design a protocol just like it to put into the product.”

 

The Communications Network still needs Design

Just because there’s a flexible protocol doesn’t mean you don’t have to do anything. Every communications network needs design. How much data? What is the bandwidth? What are the delays?

Read more…

SCADA & Telemetry DNP3, Modbus, MultiSmart, RTU, SCADA, telemetry