Device Server - interface converter or simple Tibbo PLC?
Good day, dear Habrovchane.
This article can be divided into three parts. In the first, we will talk about converters of RS232 / Ethernet interfaces - what it is and how it is used.
In the second, using the example of creating a ModBus ASCII_RTU / ModBus TCP gateway, I will demonstrate the possibility of programming Tibbo converters.
And finally, in the third part we will try to create an automatic heating control system, from a slightly modified Tibbo interface converter, with the ability to send commands via SMS messages, web-based management interface and data upload to MySQL.
The western concept of Serial Device Server means Serial Interface Converter (RS232 / 422/485) to Ethernet. The need for such devices has arisen for a simple reason: almost any microcontroller, regardless of the manufacturer, uses the UART interface (this is due to the technological simplicity of the implementation of this interface) on TTL or CMOS logic to communicate with the “outside world”. Thus, a developer simply needs to connect a transceiver chip to the controller in order to receive a data transmission channel via RS232 / 485 interface. But serial interfaces do not provide sufficient characteristics for the creation of modern communication systems. On the other hand, there is an advanced Ethernet technology that allows you to create local subnets, merge them and organize data transfer channels between geographically distributed points around the world. It is logical that the manufacturers of communication equipment decided to "combine" serial interfaces and Ethernet technology. Thus, there were hardware gateways called Serial Device Server.
RS232 / Ethernet interface converters from Taiwan-based Tibbo Technology have been used around the world for 10 years. During this time, the engineers of the company have accumulated vast experience in implementing projects using this equipment, solved non-trivial tasks, and expanded the functionality of the devices to a new level, far beyond the scope of "conventional" converters. This line of devices is called Tibbo Device Server - programmable interface converters. The key word in this definition is the word "programmable", since the final functionality of the device depends entirely on the firmware that was created and loaded into it.
But let's start with a simple one.
Structurally, Tibbo Device Server (DS) devices are a small box the size of a pack of cigarettes. On the one hand there is a standard connector (or several connectors) for the serial interface, on the other - a socket for connecting a twisted pair using Ethernet technology. By default, the Tibbo Device Server comes with the “Serial Over IP” firmware, which allows data transfer between RS232 / 485 interfaces to Ethernet.
After physical switching, it is necessary to configure the device parameters. To do this, use a set of utilities from the manufacturer: DS Manager - designed to configure device parameters, VSP Manager - to configure the parameters of a virtual COM port, a virtual COM port driver, and several diagnostic utilities. I will not elaborate on the description of the settings, but I will draw your attention to some features of these utilities:
Interface converter can be configured in one of three modes. Client mode is when the serial device initiates an Ethernet connection. This mode is used for passive monitoring. For example, when a PBX with a certain interval throws statistics on the server. Or a barcode scanner transmits data to 1C. In this mode, you specify the ip-address to which you want to send data, and the virtual COM port of the server listens to the TCP / IP port for the presence of an incoming data stream.
Server mode - a serial device responds to an incoming request. This mode can be used to interrogate I / O modules, PLCs, meters, etc.
Server / client mode - combines both of the above options. In this case, the virtual COM port of the server can both listen to the incoming data stream and establish a connection with the device at the specified ip address. Where can similar solutions be used? This is a multitude of vertical markets and applied tasks. For example:
Many will ask the question, and how are Tibbo devices better than analogs (which are enough in this segment)? I will not compare technical specifications in detail, which are identical for most similar devices. I will mention only the important features of Tibbo converters:
But the main difference from competitors - Tibbo converters are programmable ! What if this functionality is not enough and you need something special? Let's see how this can be achieved and how to unleash the full functionality of the Device Server from Tibbo Technology.
What if there is a Scada system installed on the site that polls devices using ModBus TCP protocol. And we need to interrogate the device with the ModBus RTU protocol and the RS232 serial channel on board. Having connected the usual RS232 interface converter, we will get access to the local network and even the Internet, but Scada will not see any data without implementing the ModBus protocol.
This is where the main feature of Tibbo converters comes in - the possibility of programming.
Programs are encoded in the event object-oriented language Tibbo Basic. I briefly wrote about this in an article about the Tibbo Project System . At the moment, the compiler for the language "C" is ready and its release will take place soon. Thus, you can choose a programming language - a functional and deep "C" or a simpler, easier to understand Basic.
The Tibbo IDE programming environment is free. For debugging programs and firmware, no programmers are required; everything is done directly via the local Ethernet network, including step-by-step mode of program passage and breakpoints.
So, for the realization of our task (device polling with ModBus RTU), we need to implement the ModBus protocol for Tibbo equipment. Fortunately, the protocol has already been written and is in the public domain . We just need to download it from the site, connect to the project, compile, flash the device and we get the ModBus RTU gateway in ModBus TCP.
Here's what the probros data looks like in the source code, after connecting the libraries.
Expand the task. The serial device does not support the ModBus protocol at all, and I want to connect it to the Scada system. Then we program the polling of the required device metrics over the usual RS232 interface, take the ModBus TCP code and get the hardware driver specifically for your device.
It is possible to further expand the task - is it necessary to back up data in case of a disconnection? We use the built-in flash memory for 1 MB and store the data offline, until the connection is restored. Need configuration via web interface? We program the embedded web server and get the specified functionality.
Thus, you can implement any protocol by creating your own hardware device drivers and even more. You can program logic by getting your own little PLC.
')
One day I came across a rather interesting task. The private house has a heating system - two electric water boilers. Water temperature sensors are installed at the boiler outlet and in the return leg of the pipeline; there is also an overpressure sensor and an outdoor temperature sensor in the system. All sensors were connected to the analog input module MVA8 (ARIES), which “communicates with the world” via the RS485 interface. Task - remote monitoring sensor readings. Ideally, the system should write values ​​to the MySQL database for further display of information on the customer’s personal website. I chose the DS1102 device.
The first thing to do was implement the data transfer protocol for the MVA8 module. The protocol is quite simple and several hours were spent on coding. As a result, a couple of useful functions were obtained for working with the analog input module, including get_data_sensor (). The next step was the implementation of the MySql protocol. Then I spent a little more time. As a result, this problem was solved in a few hours. The finished library MySql published on the manufacturer's website.
So, DS1102 is now able to access the MySql database, can interrogate MBA8, it's time to do the simplest logic - interrogate sensors and write values ​​to the database.
Everything works, data is successfully transferred to the MySql table. The customer is satisfied and was ready to celebrate the successful implementation, when he suddenly asked: “Can you control the room temperature remotely?”. Well, if you want, then we will do it.
The manufacturer has provided the boiler power supply circuit with the possibility of switching on the heaters using external low power relays. This method is very simple to implement, since it does not imply load power control. This means that temperature control is performed "in the forehead", without using the PID controller. But at the same time a large regulation error accumulates (overheating, then cooling). It suited the customer. But there was another problem. In the DS1102 module - there is no relay. But the relay is in the "modified" Device Server device - DS1014 . This model has not only relays, but also analog inputs, built-in GPRS and WiFi.
A little distracted. In fact, the Device Server devices from Tibbo are based on the so-called embedded modules, which I will discuss in subsequent articles. We can consider these modules as programmable microcontrollers. Using embedded in constructions with COM ports, we get an interface converter. But it is worth adding to the ADC board, DAC, as we have already received a simple I / O module. That is how the model was created DS1014. It is not difficult to conclude that having one hardware basis, programs written under the “different” Tibbo hardware are in fact easily ported between them. Thus, replacing one Tibbo device with another is painless.
The customer also agreed to this change (everyone would have such customers, right?). Well, the existing code does not need to be rewritten. Getting to work. We look at the mismatch of the outdoor temperature with a given value and if it is more than the accepted delta, we decide to turn the heaters on or off. The water pressure in the circuit fell below the critical level - turn off the boilers.
The relay clicks, the room is warm and comfortable. True, the real algorithm still provides a delay between turning on / off the boilers in order to avoid “bounce” when the temperature is in the boundary state. Data on critical events on the object is transmitted to MySQL. But we have not yet enabled the user to promptly set the required values ​​of the temperature in the room. I easily implemented this using a web interface, because all modern Tibbo modules have an embedded web server. At the same time and provided online monitoring of meters.
The function html_print_value () - polls the ports of MVA8 according to the already known algorithm and displays the values ​​on the html page.
Great, everything is configured via the browser. Customer satisfied. But I can not stop. How convenient it would be to set the temperature via SMS! For example, when returning home after a busy day, write an SMS to our system so that it raises the temperature in the house to 25 ° C. But our DS1014 model has a built-in GPRS modem, which is connected to one of the 4 serial ports of the controller. Let's work a bit with the AT & T teams.
As you can see, in the code we compare the phone number from which the command came with the specified one. The gsm_get_command () function - at the entrance it receives SMS text and extracts our commands from it. For example, a text message with the text “SET TEMP 25” will give a command to set the temperature maintenance in the region of 25 ° C.
What if there was a pipeline breakthrough (pressure dropped sharply)? In this case, our system is already able to turn off the heaters, but you also need to warn the owner.
Now the person in charge has received an alert about what is happening at the facility. As you can see, programming is not complicated at all, and it would seem that such exotic things as SMS management are implemented quite simply and quickly. There are analog input lines in the Device Server DS1014 device, so the whole system could do without the MBA8 module at all, but it was already at the site and so wanted by the customer. It is worth mentioning that by connecting the AggreGate Agent software library to the written application, it is possible to upload metrics to AggreGate Scada.
And with the release of a more flexible hardware automation platform Tibbo Project System (about which I wrote in the previous article ), the implementation of such systems turns into a commonplace and elementary designer.
It turns out that the equipment from Tibbo Technology is, of course, full-featured classic Device Server devices, in no way inferior to competitors and even superior to them. But with the possibility of free programming and the output of the TPS hardware platform, the developers were given the opportunity to go far beyond this functionality: create their own converters, hardware gateways for protocols, and even their own PLCs.
In combination with affordable pricing, technical support, a service center and our assistance in advising on project implementation, customers receive a quality product as a whole. Contact our specialists and we will show you how our equipment will help solve problems in your projects.
This article can be divided into three parts. In the first, we will talk about converters of RS232 / Ethernet interfaces - what it is and how it is used.
In the second, using the example of creating a ModBus ASCII_RTU / ModBus TCP gateway, I will demonstrate the possibility of programming Tibbo converters.
And finally, in the third part we will try to create an automatic heating control system, from a slightly modified Tibbo interface converter, with the ability to send commands via SMS messages, web-based management interface and data upload to MySQL.
1. Device Server.
1.1. What is a device server or a little banality.
The western concept of Serial Device Server means Serial Interface Converter (RS232 / 422/485) to Ethernet. The need for such devices has arisen for a simple reason: almost any microcontroller, regardless of the manufacturer, uses the UART interface (this is due to the technological simplicity of the implementation of this interface) on TTL or CMOS logic to communicate with the “outside world”. Thus, a developer simply needs to connect a transceiver chip to the controller in order to receive a data transmission channel via RS232 / 485 interface. But serial interfaces do not provide sufficient characteristics for the creation of modern communication systems. On the other hand, there is an advanced Ethernet technology that allows you to create local subnets, merge them and organize data transfer channels between geographically distributed points around the world. It is logical that the manufacturers of communication equipment decided to "combine" serial interfaces and Ethernet technology. Thus, there were hardware gateways called Serial Device Server.
RS232 / Ethernet interface converters from Taiwan-based Tibbo Technology have been used around the world for 10 years. During this time, the engineers of the company have accumulated vast experience in implementing projects using this equipment, solved non-trivial tasks, and expanded the functionality of the devices to a new level, far beyond the scope of "conventional" converters. This line of devices is called Tibbo Device Server - programmable interface converters. The key word in this definition is the word "programmable", since the final functionality of the device depends entirely on the firmware that was created and loaded into it.
But let's start with a simple one.
1.2. Serial Over IP.
Structurally, Tibbo Device Server (DS) devices are a small box the size of a pack of cigarettes. On the one hand there is a standard connector (or several connectors) for the serial interface, on the other - a socket for connecting a twisted pair using Ethernet technology. By default, the Tibbo Device Server comes with the “Serial Over IP” firmware, which allows data transfer between RS232 / 485 interfaces to Ethernet.
After physical switching, it is necessary to configure the device parameters. To do this, use a set of utilities from the manufacturer: DS Manager - designed to configure device parameters, VSP Manager - to configure the parameters of a virtual COM port, a virtual COM port driver, and several diagnostic utilities. I will not elaborate on the description of the settings, but I will draw your attention to some features of these utilities:
- Setting device parameters is carried out directly through the local network;
- Software works under any Windows OS;
- The driver of the virtual COM port is written qualitatively and many problems, such as here , can be avoided. Also, the driver version for Linux is written;
- There is the possibility of customization of software.
Interface converter can be configured in one of three modes. Client mode is when the serial device initiates an Ethernet connection. This mode is used for passive monitoring. For example, when a PBX with a certain interval throws statistics on the server. Or a barcode scanner transmits data to 1C. In this mode, you specify the ip-address to which you want to send data, and the virtual COM port of the server listens to the TCP / IP port for the presence of an incoming data stream.
Server mode - a serial device responds to an incoming request. This mode can be used to interrogate I / O modules, PLCs, meters, etc.
Server / client mode - combines both of the above options. In this case, the virtual COM port of the server can both listen to the incoming data stream and establish a connection with the device at the specified ip address. Where can similar solutions be used? This is a multitude of vertical markets and applied tasks. For example:
- Interrogation and monitoring of electricity meters in the AMR systems;
- Poll heat meters or water meters in utilities;
- Collect data from barcode scanners or RFID readers and transfer them to 1C via a virtual port;
- Polling I / O modules;
- Remote monitoring and control of PLC modules;
- Monitoring PBX or building engineering systems;
- Fire safety or access control systems;
- Remote control of your own microcontroller;
- In other words, interface converters can be used wherever remote operation with serial interfaces is required.
Many will ask the question, and how are Tibbo devices better than analogs (which are enough in this segment)? I will not compare technical specifications in detail, which are identical for most similar devices. I will mention only the important features of Tibbo converters:
- Convenient, high-quality and reliable software that works not only under Windows, but also under Linux;
- Reliable virtual COM port driver;
- The possibility of creating autonomous systems (device - DS - DS - device), without the participation of the PC;
- Ability to configure the converter through the Web management interface;
- As an option, the ability to use the WiFi network 802.11b / g. Thus, we can transfer data from the serial port by means of wireless data transmission;
- As an option, the use of technology Power over Ethernet;
- A secure line of DS10xx equipment with serial port optocoupling, IP68 protection certificate and GPRS data transfer capability;
- Supports UDP, TCP, ARP, ICMP (PING), DHCP, PPPoE, LCP and HTTP protocols;
- Ability to configure via Telnet;
- Direct control of ADSL modems;
- The possibility of multichannel operation of the serial interface has been implemented (up to 3 devices with RS232 interface can be connected via one DB9 connector);
- Easy connection of converters to the AggreGate Scada / HMI system ;
- Not to mention the pricing policy, which compares favorably with the analogues.
But the main difference from competitors - Tibbo converters are programmable ! What if this functionality is not enough and you need something special? Let's see how this can be achieved and how to unleash the full functionality of the Device Server from Tibbo Technology.
2. Programming Device Server or create a ModBus gateway.
What if there is a Scada system installed on the site that polls devices using ModBus TCP protocol. And we need to interrogate the device with the ModBus RTU protocol and the RS232 serial channel on board. Having connected the usual RS232 interface converter, we will get access to the local network and even the Internet, but Scada will not see any data without implementing the ModBus protocol.
This is where the main feature of Tibbo converters comes in - the possibility of programming.
Programs are encoded in the event object-oriented language Tibbo Basic. I briefly wrote about this in an article about the Tibbo Project System . At the moment, the compiler for the language "C" is ready and its release will take place soon. Thus, you can choose a programming language - a functional and deep "C" or a simpler, easier to understand Basic.
The Tibbo IDE programming environment is free. For debugging programs and firmware, no programmers are required; everything is done directly via the local Ethernet network, including step-by-step mode of program passage and breakpoints.
So, for the realization of our task (device polling with ModBus RTU), we need to implement the ModBus protocol for Tibbo equipment. Fortunately, the protocol has already been written and is in the public domain . We just need to download it from the site, connect to the project, compile, flash the device and we get the ModBus RTU gateway in ModBus TCP.
Here's what the probros data looks like in the source code, after connecting the libraries.
Source:
sub on_ser_data_arrival() ' , . dim x as string #if modbus_serial_mode = 0 'ASCII x = ascii_to_tcp(ser.getdata(255)) ' ASCII tcp #else 'RTU x = rtu_to_tcp(ser.getdata(255)) ' RTU tcp #endif sock.num = 0 sock.setdata(x) ' sock.send ' . end sub '-------------------------------------------------------------------- sub on_sock_data_arrival() ' , . dim x as string #if modbus_serial_mode = 0 'ASCII x = tcp_to_ascii(sock.getdata(255)) ' ASCII #else 'RTU x = tcp_to_rtu(sock.getdata(255)) ' RTU #endif ser.num = 0 ser.setdata(x) ' ser.send ' end sub ' ip , sub on_sys_init() ' , net.ip = "192.168.1.222" net.netmask = "255.255.255.0" net.gatewayip = "192.168.1.1" 'setup the Ethernet socket sock.num = 0 sock.protocol = PL_SOCK_PROTOCOL_TCP sock.inconmode = PL_SOCK_INCONMODE_ANY_IP_ANY_PORT sock.reconmode = PL_SOCK_RECONMODE_1 sock.localportlist = "502" sock.connectiontout=50 sock.rxbuffrq(2) sock.txbuffrq(2) 'setup the serial port ser.num = 0 ser.parity = PL_SER_PR_NONE ser.bits = PL_SER_BB_8 ser.flowcontrol = DISABLED ser.baudrate = ser.div9600 ser.interface = PL_SER_SI_FULLDUPLEX ser.interchardelay = 5 ser.rxbuffrq(3) ser.txbuffrq(2) sys.buffalloc ser.enabled = YES end sub Expand the task. The serial device does not support the ModBus protocol at all, and I want to connect it to the Scada system. Then we program the polling of the required device metrics over the usual RS232 interface, take the ModBus TCP code and get the hardware driver specifically for your device.
It is possible to further expand the task - is it necessary to back up data in case of a disconnection? We use the built-in flash memory for 1 MB and store the data offline, until the connection is restored. Need configuration via web interface? We program the embedded web server and get the specified functionality.
Thus, you can implement any protocol by creating your own hardware device drivers and even more. You can program logic by getting your own little PLC.
')
3. A little practice or management of heating in the forehead.
One day I came across a rather interesting task. The private house has a heating system - two electric water boilers. Water temperature sensors are installed at the boiler outlet and in the return leg of the pipeline; there is also an overpressure sensor and an outdoor temperature sensor in the system. All sensors were connected to the analog input module MVA8 (ARIES), which “communicates with the world” via the RS485 interface. Task - remote monitoring sensor readings. Ideally, the system should write values ​​to the MySQL database for further display of information on the customer’s personal website. I chose the DS1102 device.
The first thing to do was implement the data transfer protocol for the MVA8 module. The protocol is quite simple and several hours were spent on coding. As a result, a couple of useful functions were obtained for working with the analog input module, including get_data_sensor (). The next step was the implementation of the MySql protocol. Then I spent a little more time. As a result, this problem was solved in a few hours. The finished library MySql published on the manufacturer's website.
So, DS1102 is now able to access the MySql database, can interrogate MBA8, it's time to do the simplest logic - interrogate sensors and write values ​​to the database.
Source:
sub on_sys_timer ' , 0.5 . if sys.timercount>delay_get_data then ' . , , 8 ser.num=0 ' get_data_sensor() ', 8, end if End sub sub on_ser_data_arrival() dim buff, temp as string dim value as packet select case ser.num Case 0: '----- ----- mva8=incoming_data(ser.getdata(ser.rxlen)) ' 8 Value ( enum) . …. End select mysql_connect(“login”,”password”,”database_name”) ' SQL sql_query("INSERT INTO tbl_Sensor VALUES ("+ chr(34)+mva8.temperature_in+chr(34)+", "+ chr(34)+mva8.temperature_out+chr(34)+", "+ chr(34)+mva8.temperature_air+chr(34)+", "+ chr(34)+mva8.pressure+chr(34)+", "+ chr(34)+device_name+chr(34)+", "+ "NOW(),"+ chr(34)+chr(34)+")",0) sql_disconnect() End sub Everything works, data is successfully transferred to the MySql table. The customer is satisfied and was ready to celebrate the successful implementation, when he suddenly asked: “Can you control the room temperature remotely?”. Well, if you want, then we will do it.
Control of boilers using relays.
The manufacturer has provided the boiler power supply circuit with the possibility of switching on the heaters using external low power relays. This method is very simple to implement, since it does not imply load power control. This means that temperature control is performed "in the forehead", without using the PID controller. But at the same time a large regulation error accumulates (overheating, then cooling). It suited the customer. But there was another problem. In the DS1102 module - there is no relay. But the relay is in the "modified" Device Server device - DS1014 . This model has not only relays, but also analog inputs, built-in GPRS and WiFi.
A little distracted. In fact, the Device Server devices from Tibbo are based on the so-called embedded modules, which I will discuss in subsequent articles. We can consider these modules as programmable microcontrollers. Using embedded in constructions with COM ports, we get an interface converter. But it is worth adding to the ADC board, DAC, as we have already received a simple I / O module. That is how the model was created DS1014. It is not difficult to conclude that having one hardware basis, programs written under the “different” Tibbo hardware are in fact easily ported between them. Thus, replacing one Tibbo device with another is painless.
The customer also agreed to this change (everyone would have such customers, right?). Well, the existing code does not need to be rewritten. Getting to work. We look at the mismatch of the outdoor temperature with a given value and if it is more than the accepted delta, we decide to turn the heaters on or off. The water pressure in the circuit fell below the critical level - turn off the boilers.
Source:
sub on_sys_timer …... If control = true then ' , , , ( ) If mva8.temperature_air>temperature_set+delta then boiler(on) If mva8.temperature_air<temperature_set-delta then boiler_on(off) End if If mva8.pressure<pressure_min then ' , . boiler(off) Control = false Else Control = true End if End sub public sub boiler (on_off as string[3]) ' , 2 , . select case on_off case “on”: io.num=PL_IO_NUM_13_TX2 io.state=LOW io.enabled=Yes io.num=PL_IO_NUM_3 io.state=LOW io.enabled=Yes case “off”: io.num=PL_IO_NUM_13_TX2 io.enabled=NO io.num=PL_IO_NUM_3 io.enabled=NO end select end sub The relay clicks, the room is warm and comfortable. True, the real algorithm still provides a delay between turning on / off the boilers in order to avoid “bounce” when the temperature is in the boundary state. Data on critical events on the object is transmitted to MySQL. But we have not yet enabled the user to promptly set the required values ​​of the temperature in the room. I easily implemented this using a web interface, because all modern Tibbo modules have an embedded web server. At the same time and provided online monitoring of meters.
Source:
<h3> </h3> <table width=80% align=center> <tr><td> <br> <table width=100% align=center border="1" cellspacing="1" cellpadding="2" > <form action="online.html?" method="get"> <? html_print_session?> <tr> <td width=33%><font color = <?sock.setdata(FONT_COLOR_1) sock.send?>><b></b></td> <td width=33%><font color = <?sock.setdata(FONT_COLOR_1) sock.send?>><b></b></td> </tr> <? if html_login_state = LOGIN then html_print_value() end if ?> </form> </table> </td></tr> </table> The function html_print_value () - polls the ports of MVA8 according to the already known algorithm and displays the values ​​on the html page.
SMS management
Great, everything is configured via the browser. Customer satisfied. But I can not stop. How convenient it would be to set the temperature via SMS! For example, when returning home after a busy day, write an SMS to our system so that it raises the temperature in the house to 25 ° C. But our DS1014 model has a built-in GPRS modem, which is connected to one of the 4 serial ports of the controller. Let's work a bit with the AT & T teams.
Source:
sub on_ser_data_arrival() … Select case ser.num … case 1: '----- gsm ----- gsm_extract(ser.getdata(ser.rxbuffsize)) ... end select End sub public sub gsm_extract(buff as string) … select case prefix … case "+CMGR": i=instr(1,buff,chr(44),1) j=instr(1,buff,chr(44),2) cmpphone=mid(buff,i+2,ji-3) if cmpphone=phone then j=instr(9,buff,chr(13)+chr(10),1) data=mid(buff,j+2,len_buf-j-2-3) gsm_get_command(data) ' . end if in ="AT+CMGD="+num+chr(13) if val(num)>10 then in="AT+CMGDA="+chr(34)+"DEL ALL"+chr(34)+chr(13) ' 10 , SIM . ser.num=ser_gsm ser.setdata(in) ser.send case "error": …. end select End sub As you can see, in the code we compare the phone number from which the command came with the specified one. The gsm_get_command () function - at the entrance it receives SMS text and extracts our commands from it. For example, a text message with the text “SET TEMP 25” will give a command to set the temperature maintenance in the region of 25 ° C.What if there was a pipeline breakthrough (pressure dropped sharply)? In this case, our system is already able to turn off the heaters, but you also need to warn the owner.
Source:
sub on_sys_timer …... If mva8.pressure<pressure_min then boiler(off) Control = false gsm_send_sms("AT+CMGS=","CRITICAL PRESSURE. BOILER OFF.") ... End sub public sub gsm_send_sms(command as string,data as string) dim gprs_data as string gprs_data =command+chr(34)+phone+chr(34)+chr(13)+data+chr(26)+chr(13) ' , ser.num=1 ser.setdata(gprs_data) ' . ser.send end sub Now the person in charge has received an alert about what is happening at the facility. As you can see, programming is not complicated at all, and it would seem that such exotic things as SMS management are implemented quite simply and quickly. There are analog input lines in the Device Server DS1014 device, so the whole system could do without the MBA8 module at all, but it was already at the site and so wanted by the customer. It is worth mentioning that by connecting the AggreGate Agent software library to the written application, it is possible to upload metrics to AggreGate Scada.
And with the release of a more flexible hardware automation platform Tibbo Project System (about which I wrote in the previous article ), the implementation of such systems turns into a commonplace and elementary designer.
It turns out that the equipment from Tibbo Technology is, of course, full-featured classic Device Server devices, in no way inferior to competitors and even superior to them. But with the possibility of free programming and the output of the TPS hardware platform, the developers were given the opportunity to go far beyond this functionality: create their own converters, hardware gateways for protocols, and even their own PLCs.
In combination with affordable pricing, technical support, a service center and our assistance in advising on project implementation, customers receive a quality product as a whole. Contact our specialists and we will show you how our equipment will help solve problems in your projects.
Source: https://habr.com/ru/post/200538/
All Articles