Establishing communication between SCADA/EMS and Pentimex scales
Recently, there was a specific customer request to establish communication with scales – namely Pentimex PREMOVA 60-2-8 and Pentimex PREMOVA 60-3-8 platform scales with capacity of 60 tons used for weighting cargo vehicles. These scales were connected to DINI Argeo DFW06 control panel, which communicated via serial port with an application Cestná váha by VTnet company on a PC. The request of the customer was parallel publishing of data from a scale into a web interface which is provided by our SCADA/EMS application (Energy Management System) built on IPESOFT D2000 technology.
Starting the process of establishing communication
First, I found the documentation for DINI Argeo DFW06 control panel. It showed an existence of several modes, which can be used for the communication with the control panel. Either it responds to requests from a program and sends various information (including measured weight), or it sends data spontaneously, alternatively after pressing the button.
Sending of measured weight may be in standard or extended format. The standard format contains a value (8-digit number with a decimal point), units and information concerning status of the scale (e.g. stabilized value, too high or too low weight).
The extended format contains not only one, but two values (net weight and tare – 10 digit numbers with decimal points), number of counted pieces (for scales, which support this functionality) and all other data contained in a standard format.
Within a request/response mode, a so called 485 mode can be also active. This mode presumes several scales connected to RS-485 link (via RS-232 to RS-485 converters) and a two digit number of the device which is located at the start of the data. This number must be unique for each scale on a line. A scale responds only to requests which contain its address.
The control panel also supports various bitrates of serial line communication and various settings of parity and number of bits per byte.
Based on the information from the documentation, workers of the customer found out that two of three control panels send data spontaneously, and the third one on request. In all cases the scales use standard format of messages. Communication rates were in all cases 9600 bauds, 8 bits, 1 stop bit, without parity.
At the same time I would like to express my thanks to Julius Pastorek – managing director of Pentimex – for his prompt answers to my technical questions (in parallel with searching for documentation for control panel, I wrote an e-mail directly to Pentimex company).
How to obtain values?
Monitoring of the existing communication appears to be the simplest solution to obtain values. With the help of serial “sniffer“ cable the signals TX a GND can be elicited from the control panel. The sniffer cable was made directly by a technically savvy customer who then connected it into a serial port of Moxa NPort 5110. This popular (and not only with us) converter was then connected to the local network by the customer. NPort enables a transformation of serial communication into a TCP dataflow, UDP packets, and alternatively it can work in virtual port mode, when it creates a virtual serial port on a server (e.g. COM99) representing a specific device using Moxa drivers. We prefer UDP mode of communication – it does not require establishing a connection (and so in contrast with TCP mode it does not suffer from timeout problems in case of various network problems) nor installation of driver used for creation of virtual serial port (in the past we experienced “frozen“ ports). Moreover, the communication can be easily recorded e.g. with the help of the Wireshark tool.
How did we add a new protocol into the existing energy management system?
Customer had an existing SCADA/EMS application built on IPESOFT D2000 version 11.2.57. Will we therefore have to implement (into a new version of IPESOFT D2000) a new communication protocol, and because of that will we also have to upgrade IPESOFT D2000? Or should we rather implement the protocol as an OEM protocol in the form of dynamic library (e.g. in C language) using the KomAPI and so avoid performing the upgrade?
Even though these two approaches are possible, the simplest and least straining way is the third way – we will use the Generic User Protocol, which is intended exactly for this – for a quick and simple implementation of trivial protocols directly in environment of scripts in IPESOFT D2000, with the use of ESL language. By the way, this protocol was implemented in 2015, so it has been available in IPESOFT D2000 since 10.1.39 version.
I have already written a blog about Generic User Protocol –there we demonstrated the possibilities of the protocol by processing data from a GPS receiver. Communication with scale was not more complicated, we just based the server script on structured variables (so one script operates all three scales). Also invalid inputs and detection of broken communication were handled. If a weighed value cannot be obtained from communication within defined time (e.g. 5 seconds), it is evaluated as a communication error.
The advantage of using the ESL scripts is also simple debugging and correction of errors, as well as modification of functionality caused by changes in the protocol (e.g. newer versions of the protocol used in newer scales can contain additional pieces of information). It is possible to carry out all the modifications online, directly on a production application. At the same time it is possible to use the functionality of XML exports to backup certain versions of the script, so the history can be found in a case of problems and possibly we can revert the script to the functional version.
Ing. Peter Humaj, www.ipesoft.com
