Barix Wiki - User contributions [en]

Automation Applications

2009-01-25T12:37:50Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a [http://en.wikipedia.org/wiki/Programmable_logic_controller PLC] (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a [http://en.wikipedia.org/wiki/Programmable_automation_controller PAC] (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over the internet
* Heating Control system with multiple [http://en.wikipedia.org/wiki/PID_controller PID] loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like [http://calendar.google.com Google Calendar]
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like [http://code.google.com/apis/chart Google Charts]).

Barionet is a native [http://www.modbus-ida.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Modbus/TCP] Slave, meaning it can be polled by almost any [http://en.wikipedia.org/wiki/SCADA SCADA] server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of the traditional [http://en.wikipedia.org/wiki/SCADA SCADA] systems, [http://en.wikipedia.org/wiki/Snmp SNMP] traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, [http://www.nagios.org Nagios] being one of the most popular. Even lower traffic volumes are reachable when using simple [http://en.wikipedia.org/wiki/Syslog syslog] messaging from Barionets to the monitoring server.

If low traffic volume to/from Barionets and high security level at the same while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". All important state changes can be reported immediately to the central server. If there are no state shanges to report, Barionets should still be programmed to periodically access the central server, letting the central server know they are alive. At the same the Barionets may receive possible instructions from the central "brain". For example, the new configuration data or even a new version of application software can be sent this way in addition to the preprogrammed commands.

Automation Applications

2009-01-25T12:36:16Z

Dtneeme: added some links

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a [http://en.wikipedia.org/wiki/Programmable_logic_controller PLC] (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a [http://en.wikipedia.org/wiki/Programmable_automation_controller PAC] (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over the internet
* Heating Control system with multiple [http://en.wikipedia.org/wiki/PID_controller PID] loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like [[http://calendar.google.com Google Calendar]
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like ]http://code.google.com/apis/chart/ Google Charts]).

Barionet is a native [http://www.modbus-ida.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Modbus/TCP] Slave, meaning it can be polled by almost any [http://en.wikipedia.org/wiki/SCADA SCADA] server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of the traditional [http://en.wikipedia.org/wiki/SCADA SCADA] systems, [http://en.wikipedia.org/wiki/Snmp SNMP] traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, http://www.nagios.org Nagios] being one of the most popular. Even lower traffic volumes are reachable when using simple [http://en.wikipedia.org/wiki/Syslog syslog] messaging from Barionets to the monitoring server.

If low traffic volume to/from Barionets and high security level at the same while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". All important state changes can be reported immediately to the central server. If there are no state shanges to report, Barionets should still be programmed to periodically access the central server, letting the central server know they are alive. At the same the Barionets may receive possible instructions from the central "brain". For example, the new configuration data or even a new version of application software can be sent this way in addition to the preprogrammed commands.

Automation Applications

2009-01-25T12:18:25Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).

Barionet is a native Modbus/TCP Slave, meaning it can be polled by almost any SCADA server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of the traditional [http://en.wikipedia.org/wiki/SCADA SCADA] systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionets to the monitoring server.

If low traffic volume to/from Barionets and high security level at the same while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". All important state changes can be reported immediately to the central server. If there are no state shanges to report, Barionets should still be programmed to periodically access the central server, letting the central server know they are alive. At the same the Barionets may receive possible instructions from the central "brain". For example, the new configuration data or even a new version of application software can be sent this way in addition to the preprogrammed commands.

Automation Applications

2009-01-25T12:17:53Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).

Barionet is a native Modbus/TCP Slave, meaning it can be polled by almost any SCADA server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of the traditional [http://en.wikipedia.org/wiki/SCADA] systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionets to the monitoring server.

If low traffic volume to/from Barionets and high security level at the same while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". All important state changes can be reported immediately to the central server. If there are no state shanges to report, Barionets should still be programmed to periodically access the central server, letting the central server know they are alive. At the same the Barionets may receive possible instructions from the central "brain". For example, the new configuration data or even a new version of application software can be sent this way in addition to the preprogrammed commands.

Automation Applications

2009-01-25T12:14:14Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).

Barionet is a native Modbus/TCP Slave, meaning it can be polled by almost any SCADA server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of the traditional SCADA systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionets to the monitoring server.

If low traffic volume to/from Barionets and high security level at the same while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". All important state changes can be reported immediately to the central server. If there are no state shanges to report, Barionets should still be programmed to periodically access the central server, letting the central server know they are alive. At the same the Barionets may receive possible instructions from the central "brain". For example, the new configuration data or even a new version of application software can be sent this way in addition to the preprogrammed commands.

RS485 Termination

2009-01-19T19:44:43Z

Dtneeme: /* General Comments */ 1000 -> 100 Ohm ref gnd

<big>'''RS-485 line termination and "pull up/pull down"'''</big>

Several Barix products provide an RS-485 interface.

= General Comments =

An RS-485 (sometimes also written RS485) interface is generally bidirectional, a "bus" structure (which is different to RS-422, which is point-to-point). It is not suggested to connect any "branches" (introducing star topology elements) to the bus to ensure communication reliability - especially for longer lines (up to 1200 m) and/or higher speeds (up to 230kbps).

To work as a bidirectional device, the transmitter generally must be switched off and only drive the line if the device has something to say.

The RS-485 signal uses 2 wires, which are driven alternatively (inverse). the receivers look at the difference, not the absolute voltage value, of the two wires - a difference of higher than 0.3V (300mV) is accepted as a valid signal, absolute values below 0.3V are considered "undefined" and may result in either high or low reading.

In many applications, a "ground reference" line is available in addition to the 2 data lines (typically connected to the device ground through a 100 Ohm resistor), but this is not absolutely necessary.

You can find a lot of information about the RS-485 technology in general on the internet, for example in Wikipedia.

= Line Termination =

For high speed applications, the bus should be terminated with 120 Ohm resistors at both ends to avoid electrical reflections which can disturb the signal resulting in occasional of permanent communication failures.
Our experience is that for shorter distances and low speeds the line termination is "optional", and not required in many installations. Barix devices currently do *not* provide onboard termination resistors.

= Line Bias =

Line bias is critical in RS-485 applications. At times where no transmitter is active, the bus should be forced to the "idle" state. This is typically done at the master side.

The Barionet is not necessarily a master - it is a universal device which can be used as master or slave on an RS-485 bus infrastructure. A common technique to get to reasonable line bias, implemented in the Barix devices, is to use "weak" (10kOhm or similar) pullups and pulldowns in each device to provide the line bias.

Barix devices all do this - if no transmitter is active, the bus is pulled via these resistors (in every device !) to the idle state so all devices see the correct difference no the bus.

HOWEVER: 3rd party devices may not do this, or may even disturb this biasing by low impedance or reverse polarity biasing.
The problem can be clearly deteced if such a device is connected to the Barionet- the RS-485 indicator LED will stay "on" because an active transmission is detected. If you want to use such a device with Barix equipment, you need to provide (stronger) bias outside of the Barix devices, by using 2 resistors to pull up and pull down the two bus lines correctly.

(NOTE: Often times a single pull-down resistor will do the trick. We typically use a 1000 ohm resistor between the RS485- and RS485 shield on J7 of the BarioNet when using it with our RS485 i/o devices. - Adam)

RS485 Termination

2009-01-19T19:42:15Z

Dtneeme: avoid branches, 120 Ohm termination, 1000 Ohm ground, 1200 m max range

<big>'''RS-485 line termination and "pull up/pull down"'''</big>

Several Barix products provide an RS-485 interface.

= General Comments =

An RS-485 (sometimes also written RS485) interface is generally bidirectional, a "bus" structure (which is different to RS-422, which is point-to-point). It is not suggested to connect any "branches" (introducing star topology elements) to the bus to ensure communication reliability - especially for longer lines (up to 1200 m) and/or higher speeds (up to 230kbps).

To work as a bidirectional device, the transmitter generally must be switched off and only drive the line if the device has something to say.

The RS-485 signal uses 2 wires, which are driven alternatively (inverse). the receivers look at the difference, not the absolute voltage value, of the two wires - a difference of higher than 0.3V (300mV) is accepted as a valid signal, absolute values below 0.3V are considered "undefined" and may result in either high or low reading.

In many applications, a "ground reference" line is available in addition to the 2 data lines (typically connected to the device ground through a 1000 Ohm resistor), but this is not absolutely necessary.

You can find a lot of information about the RS-485 technology in general on the internet, for example in Wikipedia.

= Line Termination =

For high speed applications, the bus should be terminated with 120 Ohm resistors at both ends to avoid electrical reflections which can disturb the signal resulting in occasional of permanent communication failures.
Our experience is that for shorter distances and low speeds the line termination is "optional", and not required in many installations. Barix devices currently do *not* provide onboard termination resistors.

= Line Bias =

Line bias is critical in RS-485 applications. At times where no transmitter is active, the bus should be forced to the "idle" state. This is typically done at the master side.

The Barionet is not necessarily a master - it is a universal device which can be used as master or slave on an RS-485 bus infrastructure. A common technique to get to reasonable line bias, implemented in the Barix devices, is to use "weak" (10kOhm or similar) pullups and pulldowns in each device to provide the line bias.

Barix devices all do this - if no transmitter is active, the bus is pulled via these resistors (in every device !) to the idle state so all devices see the correct difference no the bus.

HOWEVER: 3rd party devices may not do this, or may even disturb this biasing by low impedance or reverse polarity biasing.
The problem can be clearly deteced if such a device is connected to the Barionet- the RS-485 indicator LED will stay "on" because an active transmission is detected. If you want to use such a device with Barix equipment, you need to provide (stronger) bias outside of the Barix devices, by using 2 resistors to pull up and pull down the two bus lines correctly.

(NOTE: Often times a single pull-down resistor will do the trick. We typically use a 1000 ohm resistor between the RS485- and RS485 shield on J7 of the BarioNet when using it with our RS485 i/o devices. - Adam)

Automation Applications

2009-01-10T13:51:54Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).

Barionet is a native Modbus RTU Slave, meaning it can be polled by almost any SCADA server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of traditional SCADA systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionet to the monitoring server.

If low traffic volume to/from Barionets and high security level while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". Barionets are programmed to periodically access the central server, sending their data to report and receiving the further instructions from the central "brain". Also a new version of application software or just new configuration data can be easily distributed this way.

Automation Applications

2009-01-10T13:49:26Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).

Barionet is a native Modbus RTU Slave, meaning it can be polled by almost any SCADA server. This makes it possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues of course, but there will be added traffic to keep up the VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of traditional SCADA systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, Nagios being one of the most popular. Even lower traffic volumes are reachable when using simple syslog messaging from Barionet to the monitoring server.

If low traffic volume to/from Barionets and high security level while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". Barionets are programmed to periodically access the central server, sending their data to report and receiving the further instructions from the central "brain". Also a new version of application software or just configuration data can be easily distributed this way.

Automation Applications

2009-01-10T13:43:34Z

Dtneeme:

The possibilities for automation applications using Barix [[Barionet]] are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility consumption data (water, gas, electricity)
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-s is the ease of further development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing some coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) will benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. Remotely located Barionets can be programmed to behave as one virtual controller or as a synchronized group of controllers. Also external sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules for various purposes can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts).

Barionet is a native Modbus RTU Slave, meaning it can be polled by almost any SCADA server. This makes possible to add Barionet based objects to the existing process control applications. Both monitoring and remote control functionality is available in SCADA systems. But the objects in such systems are continuously polled by the central server, which keeps the traffic volume high, even if there are no changes in the states of the objects to report. Additionally, the objects in such a system must be accessible by the SCADA server, creating network security related issues where public internet is used as a transport layer. VPN can be used used to resolve the security related issues, but there will be added traffic caused by VPN itself.

If no remote control is necessary (just monitoring is enough), then in order to overcome the mentioned above traffic and also security related issues of SCADA systems, SNMP traps should be used to inform the monitoring server about the changes on Barionet inputs. There are several powerful SNMP-aware monitoring tools available for free, Nagios being one of the most popular.

If low traffic volume to/from Barionets and high security level while using public internet is important, but both monitoring and remote control must be possible, then different tailor-made systems are possible to develop if Barionets are used as on-site controllers. For example, a distributed remote monitoring and control system can be based on one central server and a number of Barionets "on the field". Barionets are programmed to periodically access the central server, sending their data to report and receiving the further instructions from the central "brain". Also a new version of application software or just configuration data can be easily distributed this way.

Automation Applications

2009-01-08T16:23:21Z

Dtneeme: some polishing

Automation Applications

2009-01-08T09:54:50Z

Dtneeme:

The possibilities for automation applications using Barix Barionet are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

- Wastewater pump stations, independent or synchronized over internet
- Heating Control system with multiple PID loops
- Irrigation System Control
- Remote Telecommunication Site Controller
- Lightning Control
- Ventilation Control
- Remote Reading of utility readings
- etc.

An important difference of the systems based on PAC compared to the systems based on PLC-c is the ease of future development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot directly talk to each other. Introducing coordination and information sharing between separate systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) could benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. External sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Timing schedules can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts for example)

Automation Applications

2009-01-08T09:47:56Z

Dtneeme:

The possibilities for automation applications using Barix Barionet are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

- Wastewater pump stations, independent or synchronized over internet
- Heating Control system with multiple PID loops
- Irrigation System Control
- Remote Telecommunication Site Controller
- Lightning Control
- Ventilation Control
- Remote Reading of utility readings
- etc.

An important difference of the systems based on PAC compared to the systems based on PLC-c is the ease of future development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot talk to each other due to their limited communication abilities. Introducing coordination and information sharing between systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) would benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. External sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Timing schedules can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts for example)

Automation Applications

2009-01-08T09:45:09Z

Dtneeme:

The possibilities for automation applications using Barix Barionet are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility readings
* etc.

An important difference of the systems based on PAC compared to the systems based on PLC-c is the ease of future development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot talk to each other due to their limited communication abilities. Introducing coordination and information sharing between systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) would benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. External sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecasts can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Timing schedules can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Time-lines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts for example)

Automation Applications

2009-01-08T09:40:38Z

Dtneeme: New page: The possibilities for automation applications using Barix Barionet are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more ...

The possibilities for automation applications using Barix Barionet are endless. Anything, that can be done using a PLC (Programmable Logic Controller), can be done with Barionet in a more efficient way. This is because Barionet is a step further from PLC - it's a PAC (Programmable Automation Controller).

A few examples of some projects that have successfully used Barionet:

* Wastewater pump stations, independent or synchronized over internet
* Heating Control system with multiple PID loops
* Irrigation System Control
* Remote Telecommunication Site Controller
* Lightning Control
* Ventilation Control
* Remote Reading of utility etc.

An important differentiator of the systems based on PAC compared to the systems based on PLC-c is the ease of future development, expansion and integration. The powerful and open communication abilities are very important here: Barionet can talk to virtually any device willing to talk and there is no problem communicating with several devices simultaneously either. Barionet can also be used to set up some cooperation between various existing systems, which cannot talk to each other due to their limited communication abilities. Introducing coordination and information sharing between systems can result in remarkable savings. For example, independent and unaware of each other heating and cooling systems in the same building can easily waste huge amounts of energy. Also other building systems (security, access control, lightning and ventilation) would benefit of information sharing, as they can operate in a more optimal way using bits of information already present in some other system.

The information sharing abilities are not limited to one building of course. External sources of information can be used to "fine tune" the behavior of systems controlled by Barionet(s) or add features to the Barionet based applications using external computing power. A few examples here are:

* Weather forecast can be used to change the heating mode well before actual outside temperature change - this is especially beneficial for concrete buildings with remarkable thermal inertia
* Time schedules can be imported from external calendar server like Google Calendar
* User profiles (for access systems for example) can be centrally predefined and automatically distributed
* Timelines or other graphics to be shown on the Barionet web-interface can be prepared on external servers (like Google Charts for example)