Design of intelligent fire water cannon system based on CANOPEN

Publisher:浅唱清风Latest update time:2009-11-13 Source: 微计算机信息 Reading articles on mobile phones Scan QR code
Read articles on your mobile phone anytime, anywhere

1. Introduction

With the rapid development of society and economy, there are more and more tall and large-space buildings, such as exhibition centers, theaters, stadiums, warehouses, etc. Due to their special structure and complex facilities, large-space buildings have many fire hazards. Moreover, it is difficult to detect and extinguish fires in time, which often causes huge economic losses and casualties. Considering the performance and dosage requirements of other fire extinguishing agents, water extinguishing is still the best way to extinguish fires in large-space buildings [1]. Therefore, for large-space buildings, the use of intelligent fire-fighting water cannon systems with automatic fire detection functions is a better solution.

The working principle of the intelligent fire water cannon system is to collect infrared images of the scene through the front-end detection system, and the central controller uses image processing to detect and locate the fire in the control area, turn on the corresponding linkage equipment and control the water cannon to start the water spraying operation [2]. The various parts of the system are distributed in different locations of the control site. Therefore, communication between the various parts is the prerequisite for ensuring the normal operation of the entire system.

As a communication control method with advanced technology, high reliability, low cost and complete functions, CAN bus has been widely adopted in various fields such as automotive electronics, automatic control, and intelligent buildings. However, CAN-Bus only specifies the physical layer and data link layer. It is not a complete protocol itself. For efficient communication, it must be supported by high-level protocols. CANOPEN is an open and standardized high-level CAN protocol developed by CIA (CAN in Automation) members engaged in industrial control. It has achieved rapid development in recent years, especially in Europe. CANOPEN protocol occupies a leading position in CAN-based industrial systems [3]. With the support of CANOPEN protocol, devices from different manufacturers can be configured through the bus, which greatly enhances the versatility of CAN network.
Applying CANOPEN protocol to intelligent fire monitor system can not only solve the interconnection problem between various parts of the system, but also improve the reliability and real-time performance of the communication of the whole system. In addition, due to the adoption of CANOPEN protocol, the standardization and openness of the whole system are improved, so it is more convenient to expand the whole system.

2. Analysis of CANOPEN protocol

CANOPEN assumes that the node hardware of the CAN network has a CAN controller and a CAN transceiver specified by ISO11898. The protocol describes the standard communication mechanism, network management and related parameter settings.

2.1The core of CANOPEN——object dictionary

In CANOPEN, the concept of object dictionary is introduced. Each node in the CANOPEN network has an object dictionary, and the object dictionary of each device has the same structure. The object dictionary describes all the parameters of the device and its network behavior. It is an ordered group of objects. Each object in the object dictionary can be located by a 16-bit main index and an 8-bit sub-index.
The object dictionary of the network node is stored in the electronic data sheet or device configuration file. The CAN bus does not need to detect all the functions of the object dictionary of each node. The node only needs to be able to provide the required objects in the object dictionary and other optional objects that constitute the configurable functions of the node[4].

2.2 CANOPEN communication mode

The CANOPEN protocol classifies the data transmitted on the bus, that is, each transmitted data is an object of a specific class, thus realizing object-oriented programming. Four types of objects are defined in CANOPEN, namely management objects (NMT), service data objects (SDO), process data objects (PDO) and special function objects.

2.2.1 Management Object (NMT)

CANOPEN is based on the master-slave communication mode. The work of all slave nodes is coordinated by the network master node. The management object is used by the network master node to monitor and manage the slave nodes and complete related tasks such as node initialization, node parameter configuration, node error protection, etc.

2.2.2 Service Data Object (SDO)

The service data object is used to establish a point-to-point communication between two CANOPEN devices based on the client/server mechanism. Through the service data object, the client can access the object dictionary of the server. A service data object uses two CAN data frames with different identifiers. The service data object allows the transmission of data of any size. There are two transmission mechanisms. The accelerated transmission mechanism is used to transmit data less than or equal to four bytes at a time, and the segmented transmission mechanism is used to transmit data greater than four bytes.

2.2.3 Process Data Object (PDO)

Process data objects are used to transmit real-time data. It is the most basic data transmission method of CANOPEN. Data transmission is limited to 1 to 8 bytes. Data is sent by a producer and can have one or more consumers. There are two types of PDO communication, read PDO and write PDO. Write PDO is mapped to a CAN data frame, and read PDO is mapped to a CAN remote frame. This remote frame is responded by a data frame. There are three ways to trigger PDO transmission: event or timer trigger mode; remote request trigger mode; synchronous trigger mode. In the object dictionary of the node, each PDO has a clear description, so that both the sender and the receiver can interpret the specific content of the PDO. The identifier of the PDO has a high priority to ensure good real-time performance.

2.2.4 Special Function Objects

CANopen provides three special function objects: Synchronization Object, Time-Stamp Object and Emergency Object [5]. Synchronization Object is broadcast regularly by the synchronizer and is used for synchronous communication of PDO. Time-Stamp Object provides a microsecond clock for application devices, so that those devices with strict time requirements can be accurately synchronized. Emergency Object is triggered by a fatal error inside the device and is sent by the device with the error to other devices in the network with the highest priority to notify other devices not to try to communicate with the device again.

2.3 CANOPEN device model

The device model of CANOPEN can be divided into three parts: communication interface and protocol software, object dictionary, process interface and application program. Among them, the communication interface and protocol software provide the connection service between the device and the bus. The object dictionary describes all data types, communication objects and application objects used by the device. It provides an interface with the application software. The process interface and application program provide the control mechanism inside the device. The relationship between them is shown in Figure 1.

CANOPEN device model

3. Implementation of the communication model of the intelligent fire water cannon system

3.1 Intelligent fire water cannon node hardware design

The entire fire monitor system consists of fourteen nodes, which form a CAN network. The industrial control computer is the main node of the network. It coordinates the actions of each sub-node in the system. The industrial computer is connected to the CAN network through a CAN communication card. The system contains a total of twelve fire monitor sub-nodes. Each sub-node contains an infrared CCD camera, a fire monitor, two stepper motors and a DC motor. The hardware system of the node control module in each sub-node is shown in Figure 2.

Hardware system of node control module in sub-node

The CAN controller uses an independent CAN bus controller produced by PHILIPS for automotive and general industrial environments. It supports basic CAN mode and enhanced CAN mode. It has all the necessary features required to complete the high-performance CAN communication protocol. The CAN bus driver 80C250 is the interface between the CAN controller and the physical bus, which can provide differential transmission and reception functions for the bus. In addition, the CAN controller SJA1000 and the CAN bus driver 80C250 are connected through a high-speed optical coupler TL113, which well realizes the electrical isolation between the various CAN nodes on the bus. However, the two power supplies used in the optocoupler circuit must also be completely isolated, otherwise the use of optocouplers loses its meaning.

3.2 Establishment of node object dictionary

Each device in the network needs an object dictionary. In this system, there is a master node and thirteen slave nodes. Each node uses the eleven-digit ID specified in the predefined connection set. It consists of a four-digit function code and a seven-digit node ID. Considering the future scalability of the system, the node numbers of the thirteen child nodes are set to 8-20. The following takes the master node as an example to introduce the creation of the object dictionary.

The slave node needs to be able to access the object dictionary of the master node, so the master node needs an SDO. The master node needs to send data to thirteen slave nodes, so it needs thirteen Tx-PDOs and thirteen Rx-PDOs. Each PDO is composed of two parts: PDO communication parameters (PDOParameter) and PDO mapping parameters (PDOMapping). As shown in the following table:

Mapping Parameters

In addition, the master node needs to manage the slave nodes in the network, so a management object (NMT) is needed. The system also needs to send urgent information, so an emergency event object (EmergencyObject) is needed.

The object dictionary of a node is described in an electronic data sheet (EDS). The node itself only needs to be able to provide the necessary objects in the object dictionary and other optional objects that constitute part of the node's configurable functions.

3.3 Node Software Implementation

The node software can be divided into three parts based on its content: the basic function part, including the communication initialization of the node and the initialization of the hardware device, the definition and access of the object dictionary, and the PDO communication and SDO communication; the error handling and node management part, which performs corresponding operations when an error occurs in the node or the node status changes; the extended function part, which is used to reset the node status and related parameters when the system hardware changes.

3.4 Network initialization process

The initialization process of the CANopen network is shown in Figure 3:

CANopen network initialization process

In the intelligent fire monitor network, each node automatically enters the pre-operational state after power-on and internal initialization. The slave nodes in this state can be configured with parameters through SDO, but PDO communication is not allowed. The industrial computer master node can use NMT to make each slave node enter the operational state. In the operational state, PDO communication is allowed. The master node can also make the slave node enter the stopped state. In the stopped state, neither PDO communication nor SDO communication is allowed, and the node can do its own thing. It is possible to return to the pre-operational state or the operational state from the stopped state.

4. Conclusion

As an important firefighting facility for large-space buildings, the intelligent firefighting water cannon system has attracted more and more attention in recent years. The CAN bus has a good application prospect in various fields, and CANopen is an open protocol. Applying the CANopen application layer protocol to the design of the firefighting water cannon system can not only improve the efficiency and reliability of system communication, but also promote the standardization of the intelligent firefighting water cannon system based on the CANopen protocol platform.

The author's innovation: For the first time, CAN bus and CANopen protocol are applied to the design of intelligent fire water cannon system.

Reference address:Design of intelligent fire water cannon system based on CANOPEN

Previous article:Design of remote meter reading system based on CAN/RS485 double-layer network
Next article:Application of Ethernet Technology in Relay Reliability Detection System

Latest Industrial Control Articles
Change More Related Popular Components

EEWorld
subscription
account

EEWorld
service
account

Automotive
development
circle

About Us Customer Service Contact Information Datasheet Sitemap LatestNews


Room 1530, 15th Floor, Building B, No.18 Zhongguancun Street, Haidian District, Beijing, Postal Code: 100190 China Telephone: 008610 8235 0740

Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved 京ICP证060456号 京ICP备10001474号-1 电信业务审批[2006]字第258号函 京公网安备 11010802033920号