Evikontroll Silo Control and Monitoring System based on MangoES

Our partners contacted us with their new project as they were still building it on site.

They needed a control system for the whole site with a grain silo monitoring system. They also noted that if this project goes well we will get a quotation for a bigger one, as they were also rebuilding another larger site, which we would also be in charge of - if this system succeeds.

eks.png

We wanted to order MangoES earlier but we lacked projects where we could install it. As we had never ordered MangoES before, we wanted to test it with something more superior than just monitoring and alarming, where we had used Mango before in our previous projects.


silo.png

We had experience with control systems for timber drying automation, but as the two are not comparable (timber drying is much slower compared to grain drying), we wanted to take on a project that would be a challenge for us.

The system was built for one of the biggest Estonian farming companies with state of the art devices on site and we were responsible for relay, IO devices, temperature monitoring and control system development.

The site consisted of 6 preservation bins, 3 ventilation bins and 8 seed grain bins and 1 fast reload bin where loading for the trucks happen.

As we were building the system, many electrical and communication problems came up, which we were not expecting and because of that MangoES, which was installed on site, landed up doing far more work than we initially expected/needed.


All in all the project succeeded and we are extremely happy with MangoES, as it is powerful enough to build these kinds of projects on.

System overview

As we started building the system, the requirement for the control page was that every switch should be a button, as the user will be a farmer, which means that everything should be simple and understandable. The page should not use any modern graphics because this will make the system much more difficult to operate for farmers who are not so familiar with computers/technology. The system should respond instantenously with a maximum graphical delay of ~1 second. Operating the devices have to be instantaneous after the user has issued a command.

The whole automation part of the system consists of devices which have five states, depending on which signal they are sending to the IO ports. The state calculation has been done with Meta data source, which calculates the state by reading corresponding digital input points, which have been assigned for the specific device.

  Control Station

Control Station

We use our own 24V 32-channel IO digital input modules, which are all connected to the MangoES via RS485 Modbus network with a communication speed 57600 bps.

The current poll duration varies around 550 – 800 ms, which is within the required response delay. Modbus network consists of 35 devices with a datapoint count of approximately 850 points.

The operating PC is in the same local network as MangoES and has been installed as a kiosk for the operator to operate the site. The user can also access the system through our VPN for monitoring outside of the site to see what the operators are doing on site.

Data logging is done by the control system only for the states of the devices. An overview of changes of binary points is kept for 1 week, as we do not want to bulk MangoES with unnecessary binary data.

The control page has auto login enabled so that the local operators would not have to log in to the system. Mango has three user accounts, two of them have the possibility to control the site devices and alarms.

IMG_26092017_234858_0.png

As an add-on to the control system which operates the automation devices, there is a temperature monitoring system built within Mango, which also uses the same RS485 network to communicate with temperature controllers which are communicating with temperature cables installed in the bins.

Because of the large data size of the temperature monitoring system, we use scripting data source to switch on/off the temperature points. They are UTF-16 format datapoints (around 40-60 register bulks) in the grain silo temperature data controllers.

The system switches on the datapoints every 20 minutes, polls the devices, gathers data and then switches them back off after which the temperature assigning starts taking place. The system checks the control bits to see if there are any errors in the cables, then it calculates the temperatures of the silo bins and informs if there are any problems with the cables.

All is done with our own javascript function by converting the polled data and then assigning the correct values to corresponding datapoints within the scripting data source.
As our controller data is dynamic, the calculation for assigning the correct datapoints has to be done.

It is also worth noting, that as temperature changes in grain silo bins are very slow, this method for temperature monitoring is excellent for gaining overview of the current state and gaining information whether there are any problems with the grain.

The temperature monitoring system also uses meta datasource to calculate average and highest temperature in the bins.

temp-monitor1.jpg
  temperature monitoring

temperature monitoring

We use high/low/change event detectors in the temperature monitoring system to alarm the user to any problems. This current instance sends text messages by connecting to the on-site router via bash script, which uses 3G SIM card to alarm whether the alarm state has been reached for the corresponding bin.

We also use scripting data source to switch off the relays/switches of the damper motors when the device has reached its end point.

Because of miscommunication with our partner we have to use a modbus polling enhancer which polls rapidly the corresponding datapoints by using RuntimeManager when the user opens up a damper for the silo bin. This was done because it turned out that the devices did not have internal end switches, so the control system had to switch off the motors.

We had to make the endpoint reaction time faster, as the 550-800 ms data polling speed was too slow for this and the dampers got stuck if they were not switched off on time.
The scripting data source is also being used for controlling electrical drives as they need to be switched on with a corresponding algorythm.

The whole system has a total of 1771 datapoints and has been working for over a year now without any problems.