The Modbus industrial protocol was developed in 1979 to make communication possible between automation devices. Originally implemented as an application-level protocol intended to transfer data over a serial layer, the protocol has expanded to include implementations over serial, TCP/IP, and the user datagram protocol (UDP). Today, it is a common protocol used by countless devices for simple, reliable, and efficient communication across a variety of modern networks. Table of Contents.
Introduction to Modbus Modbus is typically used for Supervisory Control and Data Acquisition (SCADA)-style network communication between devices. For example, a large server may be used to master a programmable logic controller (PLC) or programmable automation controller (PAC), while that PLC/PAC may in turn master a sensor, valve, motor, or any other embedded device. To meet these needs, Modbus was designed as a request-response protocol with a flexible data and function model—features that are part of the reason it is still in use today. The Request-Response Cycle The Modbus protocol follows a master and slave architecture where a master transmits a request to a slave and waits for the response. This architecture gives the master full control over the flow of information, which has benefits on older multidrop serial networks. Even on modern TCP/IP networks, it gives the master a high degree of control over slave behavior, which is helpful in some designs.
The Master-Slave, Request-Response Relationship of Modbus Devices In Modbus, this request is a layered set of data. The first layer is the application data unit (ADU), which is what most people consider to be the “type” of Modbus used. There are three ADUs: ASCII, remote terminal unit (RTU), and TCP/IP. TCP is a modern format that allows for efficient handling of Modbus requests and responses in software, as well as more efficient networking through the use of dedicated connections and identifiers for each request. RTU and ASCII are older serial ADU formats with the primary difference between the two being that RTU uses a compact binary representation while ASCII sends all requests as streams of ASCII characters. For most applications, the preferred ADU depends on the desired physical network (Ethernet, serial, or something else), the number of devices on the network, and the ADUs supported by the master and slave devices on the network. From the point of view of the application using Modbus, data should simply be exposed as if the ADU did not exist.
Within each ADU, there is a protocol data unit (PDU) that is the core of the Modbus protocol. Each PDU contains a function code and associated data.
Each function code has a well-defined response, and you can think of this function code as the command being sent to the slave. In some cases, errors can occur. Modbus defines a specific PDU for exceptions, which lets the master know what happened. Most drivers convert this to a form that makes sense for the language or application in use. The Modbus Data Model Modbus manages the access of data simply and flexibly. Natively, Modbus supports two data types: a Boolean value and an unsigned, 16-bit integer. In SCADA systems, it is common for embedded devices to have certain values defined as inputs, such as gains or proportional integral derivative (PID) settings, while other values are outputs, like the current temperature or valve position.
To meet this need, Modbus data values are divided into four ranges (see Table 1). A slave can define as many as 65,536 elements in each range. Memory Block Data Type Master Access Slave Access Coils Boolean Read/Write Read/Write Discrete Inputs Boolean Read-only Read/Write Holding Registers Unsigned Word Read/Write Read/Write Input Registers Unsigned Word Read-only Read/Write Table 1. Modbus Data Model Blocks In many cases, sensors and other devices generate data in types other than simply Booleans and unsigned integers. It is common for slave devices to convert these larger data types into registers. For example, a pressure sensor may split a 32-bit floating point value across two 16-bit registers.
Modbus exposes these values in a completely conceptual way, meaning they may not actually exist in memory. For example, a slave device may be defined such that holding registers and input registers actually share the same memory if that behavior makes sense for the slave.
In most cases, slaves store each type of data that it supports in separate memory, and limits the number of data elements that a master can access. This flexibility is an option because of the way data is exposed through the well-defined behavior of Modbus function codes. Modbus Function Codes Modbus function codes determine how data is accessed and modified by the master.
Unlike the data ranges, which are conceptual, function codes have a well-defined behavior. When a slave is asked to perform a function code, it uses the parameters of the function to execute that well-defined behavior.
Figure 2 shows this link between a function request and the actual memory of the device. The Mapping Between a Function Code, Data Ranges, and the Actual Memory of a Slave Device The most common function codes are named after the conceptual data range they modify or access.
For example, “read holding registers” takes the action of pulling data out of the memory defined as holding registers and returning it to the master. Table 2 identifies the most common function codes. Common Function Codes NI provides three primary mechanisms for interfacing with Modbus devices: (1) a high-level OPC server, (2) a Modbus I/O server, and (3) a low-level Modbus API introduced in NI LabVIEW 2014 software through the LabVIEW Real-Time or LabVIEW Datalogging and Supervisory Control (DSC) modules.
LabVIEW Modbus API The low-level Modbus API is the preferred option when your application needs a high level of control over the sequencing and timing of Modbus requests. The low-level API is typically also the preferred choice where flexibility is paramount. In contrast, the flexibility and power offered by the LabVIEW Modbus API also means that your application code must be more complex to correctly manage the API. To help you understand this complexity, LabVIEW provides two examples. Modbus Introductory Example The first example, Modbus Library.lvproj, provides a basic overview of the API’s functionality. It also demonstrates the differences between an implementation on a PC and a real-time target. Figure 3 shows the code involved in the Real-Time Modbus Master example.
Master on RT Target.vi This example demonstrates the core requirements of a Modbus application using the LabVIEW API. First, a Modbus instance is created. In this case, a TCP master. However, you can switch this example to a serial master by changing the polymorphic instance selector. Changing the Type of Modbus Master When the instance is created, you can begin polling the slave device for data.
The example shows the use of the function code Read Input Registers. All Modbus function codes supported by the API are shown on the appropriate palette. Because of implementation of the protocol, the slave API has additional functions that the master cannot implement. For example, a slave can write to the input register range, while a master may only read from that range. Figure 5 shows the function codes.
Modbus Master and Slave Palettes Showing the Function Codes Finally, the Modbus instance is closed, de-allocating the memory associated with the instance. This also closes any references, including the TCP connection or NI-VISA serial references used by the instance.
Only the master example has been discussed thus far; however, every example follows the same basic pattern familiar to most LabVIEW users: open, read/write, and close. Finally, although the API does look the same, it is important to understand the key difference. If your device is a master, it must send a request across the network to the appropriate slave to acquire data. The slave, on the other hand, has its own local data storage and can access it quickly. Redundant Master Example The basic example may suffice for some applications; however, it may not be enough for complicated applications where the goal is to talk to a sensor or gateway.
To help bridge this gap, a sample application shows how to use two masters to communicate with a given slave. If one of the masters fails and loses connection with either the slave or human machine interface (HMI), the other master takes over. Design of the Redundant Master Example If this design meets the needs of your application, or if you are interested in a more complex example of Modbus communication, view Redundant Modbus Masters.lvproj in the Example Finder. Modbus I/O Servers Modbus I/O servers, which are in the LabVIEW DSC and LabVIEW Real-Time modules, provide a high-level engine for communicating over Modbus. Rather than specifying a function code that you wish to send, you register the set of data you would like to access and the I/O server schedules the requests automatically at the specified rate. To use I/O servers, you add a new I/O server to the desired target in your project. As with the low-level API, you can choose between a Modbus master or slave, and these lead to additional parameters.
For example, a master has a defined polling rate—the rate at which every request is sent to the slave, while slaves must wait on those requests and have no predefined timing. After the I/O server is created, you may specify the items on the device you wish to read. Unlike the low-level API, where you must generate and process the requests yourself, Modbus I/O servers let you select from a wide variety of formats and data types. For example, you can read the holding register at address 0 by mapping a variable to the item 400001, read the first bit of this register by selecting 400001.1, and read the single precision float that is stored in registers 0 and 1 by selecting F400001. After selecting variables to access, you can read or write these variables using shared variable nodes on the block diagram.
You can even alias the variable names. A Simple I/O Server Application The programming effort involved with an I/O server application is minimal and easier to understand.
Remember that this ease of use comes with limitations. Data updates at only the predefined rate, and there is no way to add or remove requested data at run time. If these limitations are acceptable for your application, I/O servers are the recommended cross-platform option. For more information and a step-by-step guide, view.
NI OPC Servers With OPC I/O Servers or OPC UA For complicated applications involving many slave devices that communicate over different protocols, the standard Modbus I/O might not suffice. A common solution is to use an OPC server, which acts as a data aggregator for all of your systems, and then use the OPC I/O servers included in the LabVIEW DSC Module to communicate with that OPC server. Figure 8 shows an example of this architecture, with NI OPC Servers using Modbus to communicate directly with sensors and OPC UA to communicate with an NI CompactRIO PAC. After data is aggregated in NI OPC Servers, an OPC I/O server can retrieve data and share it with the LabVIEW application. A SCADA Application Using Modbus, NI OPC Servers, and OPC I/O Servers You can also develop a similar architecture that uses the OPC UA Toolkit (OPC UA functionality was included in the LabVIEW DSC Module before version 2017) in place of OPC I/O servers. However, the OPC UA driver is a low-level driver and does not provide the ease of use afforded by OPC I/O servers.
To develop an application like this, you must first generate a valid configuration for NI OPC Servers to communicate with your slave devices. This is done by generating channels—which define a driver configuration—and devices—which define an individual endpoint for that driver. After you have configured a device, you can then generate tags.
A Sample Configuration in NI OPC Servers for the Above Architecture And after you have configured NI OPC Servers, you can configure an OPC I/O server to communicate with these tags. While Modbus I/O servers are configured to access registers, OPC I/O servers are configured to access tags in the OPC server. Configuring OPC I/O Servers This binding process generates variables you can then use in your application.
A Simple Application Using OPC I/O Servers Find a full walkthrough of this process. Meeting the Needs of Your Application Modbus is a simple protocol that you can use in various ways to implement powerful applications. For Modbus communication, NI provides three primary options that provide a wide array of functionality to meet the needs of your application. First, a low-level API provides fine control over the protocol, with high performance, at the expense of ease of use. Everything must be done manually when using the low-level API.
For simpler monitoring applications, Modbus I/O servers provide a simpler and easier API for accessing or serving up Modbus data. In exchange for ease of use, I/O servers give up the tight control over the protocol that can be required for some applications. Finally, for large and complex systems, it may be beneficial to consider a full-featured OPC server to serve as a data aggregator. Then, simply use a tool like the LabVIEW OPC UA Toolkit or OPC I/O servers to provide your application access to this data. Related Links.
If you encapsulate all of your communications code in a subVI or set of subVI's, separate from the code that does the transformation and display part, you can easily substitute test code and test data for the real sensor data. You could write a subVI that generates the test data and replace it with the real sensor comms subVI later, or you could use a case structure in the subVI to choose between communicating with the real sensor and just outputting test data (which, as Moray suggests, you could read in from a file so that you can easily change it). I would suggest that you write separate subVIs for opening communications to the sensor, getting a data point from it, and closing the comms port when you are finished (though you can probably just use the serial or VISA close function for that). Chain these VIs together using the comms port (aka VISA session) and error wires. The 'open' VI could take an input that specifies whether real/simulated data is to be used and store that choice in a global variable (or a functional global VI) which the 'get data' VI checks each time it is called. Glglgl's suggestion of sending the simulated data from another serial port is also good; all you need to do here is use the serial send and receive functions in some sort of loop to do the same thing as the real sensor would, in terms of receiving commands and sending an output back. This has the advantage that you don't need to make any changes to your main program which should work exactly the same whether it's connected to the real sensor or the simulation program.
However, problems with serial comms in the real world often result from instruments or devices that don't do exactly what their specifications claim they do, so just because your program works perfectly with your simulation doesn't guarantee it'll work perfectly with the real sensor if the real sensor does something you didn't expect:-). Though the other answers offered some really great ideas, I've found an easier way to simulate sensor input that would be convenient for beginners. Create virtual serial ports on your computer by using a Virtual port simulator. Get a Modbus simulator.
Download Labview Modbus Library. Open the Labview Modbus library and run 'MB Serial Master Example.vi' Now it should be possible to read/write values into the simulator using the example program.
The Block Diagram of example program can be analyzed to find out how data is being transferred behind the scenes on Modbus protocol.
You can use LabVIEW VIs on your host PC or NI CVS-145 x device to create a Modbus serial slave device for a remote master device or a Modbus serial master device for remote slave devices. This document provides detailed steps on how to build a slave device in LabVIEW to interact with a Modbus enabled touch screen, such as the QSI Corporation QTERM-G70 and the AutomationDirect EZTouch Panel EZ-S6C-FST. This document also includes steps for developing a LabVIEW VI to send out messages as a master device.
Table of Contents. Modbus Overview Modbus is an application layer messaging protocol for client/server communication between devices connected on a bus or network. Modbus can be implemented using asynchronous serial transmission to communicate with touch screens, PLCs, and gateways to support other types of industrial buses.
The Modbus Serial Line protocol is based on a master/slave architecture. An address, ranging from 1 to 247, is assigned to each slave device. Only one master is connected to the bus at any given time. Slave devices do not transmit information unless a request is made by the master device, and slave devices cannot communicate to other slave devices. Information is passed between master and slave devices by reading and writing to registers located on the slave device. The Modbus specification distinguishes the use of four register tables, each capable of 65,536 items and differentiated by register type and read-write access. Register address tables do not overlap in this implementation of LabVIEW.
Class 0: Read Multiple Registers Write Multiple Registers Class 1: Read Coils Read Input Discretes Read Input Registers Write Coil Write Single Register Read Exception Status For more information about the Modbus specification, visit www.modbus.org. Required Hardware and Software You must have the following hardware and software installed to perform the procedures outlined in this document:.
Host PC and/or NI CVS-145 x device. LabVIEW version 7.1 and later. Refer to the LabVIEW documentation for information about system requirements for the host PC and/or CVS-145 x device. LabVIEW Real-Time 7.1 installed on the host PC if you are using a CVS-145 x device to communicate with the Modbus device. NI-VISA 3.0.1 installed on the host PC. NI-VISA is the driver software that enables you to use the serial port on the PC to configure instrumentation systems with serial interfaces. Visit ni.com/visa to download the NI-VISA driver software.
VISA Server 3.0.0 installed on the host PC. The VISA server acts as a communication server between the PC and the Modbus device.
Visit ni.com/visa to download the VISA Server. Measurement & Automation Explorer (MAX) version 3.1.1 or later. Using LabVIEW to Interface with a Modbus Device National Instruments provides LabVIEW VIs you can use to format and write values to an internal Modbus register. The VIs you use to interface with a Modbus device are included in the NIModbus.llb. This library includes the Modbus Serial Slave Demon VI, which you use to run in the background to monitor the serial port for commands issued by a remote master device. When the Modbus Server receives a Modbus request, it performs the specified action, which is to read or write to the Modbus registers, and sends a response to the master. LabVIEW as a Modbus Slave Device Modbus Slave Device Setup Complete the following steps to set up a slave device, such as an NI CVS-145 x device or PC, to use LabVIEW to communicate with a Modbus master device, such as a touch screen:.
Initialize the local Modbus registers. Set up and initialize the COM port. Start the Modbus serial slave server. Read and write to the local Modbus registers. Stop the Modbus Serial Slave Demon and close VISA Sessions. Initialize the Local Modbus Registers At the start of a Modbus application, the four local register tables must be created in memory by LabVIEW. Initialize these registers using the MB Registers Manager VI.
This VI is a multipurpose VI you can use to initialize, read, and write to any of the registers. Complete the following steps to configure the MB Registers Manager VI:. Go to All Functions»Select a VI. In the dialog box, select NIModbus.llb»MB Registers Manager.vi. Right-click the Function terminal and select Create»Constant. Select Init in the constant. Tip: The other inputs are not necessary for initializing the registers.
Set Up and Initialize the COM Port Use the MB Serial Init VI to specify which COM port the master device is connected to and to set the serial communication settings. Complete the following steps to configure the MB Serial Init VI:. Go to All Functions»Select a VI. In the dialog box, select NIModbus.llb»MB Serial Init.vi in the LabVIEW block diagram.
Create controls or constants for all of the inputs to match the serial settings of the master device. VISA resource name – Select the COM port that the master device is connected to. Baud Rate – Default is 9600. Parity – Default is None. Flow Control – Default is None. Timeout – Default is 10000 ms. Mode – Default is RTU Note: These serial settings must match the serial settings of the master device.
Note: Select RTU mode for the QTERM-G70 and EZTouch Panel. The RTU (remote terminal unit) transmission mode is available with all Modbus devices. Set Up the Modbus Serial Slave Server The Modbus Serial Slave Demon VI works as the server between the master device and the local Modbus registers. The VI waits for incoming commands from the master device on the COM port and processes them. This VI can be launched dynamically from the main VI to run in the background.
Load the Slave Server Dynamically Complete the following steps to configure the Modbus Serial Slave VI:. Drop the All Functions»Application Control»Open VI Reference VI in the block diagram. Right-click the vi path terminal and select Create»Constant. Copy and paste the path to the MB Serial Slave Demon.vi, which is included in the NIModbus.llb, into the constant. Note: When targeting a CVS-145 x device, upload the NIModbus.llb, which contains the MB Serial Slave Demon VI, to the CVS-145 x device flash. In the Open VI Reference, specify the path of the MB Serial Slave Demon VI on the CVS-145 x device.
Note: When building a Modbus slave application into an executable, you must add the MB Serial Slave Demon.vi as a dynamic VI in the Source Files tab in the LabVIEW Application Builder. National Instruments suggests you specify a relative path for the MB Serial Slave Demon VI where the path is relative to the calling VI. Set the Control Values for the Slave Server Use invoke nodes to set values for the MB Serial Slave Demon VI with the action Set Control Value Variant. Complete the following steps to set values for MB Serial Slave Demon VI:. Drop the All Functions»Application Control»Invoke Node function on the block diagram.
Wire the reference output of the Open VI Reference function to the appropriate input on the Invoke Node function. Right-click the top portion of the Invoke Node and select Methods»Set Control Value Variant. Set up the Modes:.
Labview Modbus Serial Example List
Right-click Control Name and select Create»Constant. Enter Modes in the string constant input. Drop an All Functions»Numeric»Enum Constant on the block diagram. Enter RTU as the first option. Right-click the Enum Constant and select Add Item After.
Enter ASCII as the second option. Select the RTU item in the Enum Constant. Drop an All Functions»Array»Build Array function on the block diagram, and wire the Enum Constant into it. Wire the Build Array function to the Value property on the Invoke Node function. Repeat steps 1 through 4 for each of the items below, ignoring the Modes item because you already added it.
Tip: Refer to the All Functions»Select a VI» NIModbus.llb»MB Serial Example Slave.vi for an example of how these Invoke Node functions are configured. VISA resource names – Array of strings. The port is the same as the COM port specified with MB Serial Init, which is the COM port that the slave is connected to. Modes – Array of enums, RTU, or ASCII.
The mode is the same as the mode specified with MB Serial Init for each slave device. Timeouts – Array of U32 values. These are the timeout values for reading serial commands, in milliseconds, for each slave device.
Slave Address – Numeric U8. Assign a slave address that is between 1 and 247 to identify LabVIEW to the master device.
Tip: When you repeat Step 2 after you add the first Invoke Node function, wire the reference output and error out outputs from the initial Invoke Node to the subsequent Invoke Nodes. Tip: You do not need to use the Build Array function for the Slave Address item because it is not an array of values. Set Up the Global Variable Add the global variable, Slave Demon Running, to the block diagram and initialize the global variable to True. The global variable is used later to stop the MB Serial Slave Demon VI remotely.
Complete the following steps to add the global variable:. Go to All Functions»Select a VI. In the dialog box, select NIModbus.llb»MB Globals.vi. Click the MB Globals variable, and select Slave Demon Running. Right-click the Slave Demon Running global variable, and select Create»Constant. Set the constant to True. Run the Modbus Serial Slave Server VI.
Drop the All Functions»Application Control»Invoke Node function on the block diagram. Wire the reference output of the previously dropped Invoke Node function or Open VI Reference function to the reference input of the Invoke Node function you just dropped. Right-click the bottom portion of the Invoke Node and select Methods»Run VI. In the Invoke Node function, right-click Wait until done, and then select Create»Constant. Set the constant to False. In the Invoke Node function, right-click Auto Dispose Ref, and then select Create»Constant. Set the constant to False.
Note: You must initialize the local Modbus registers before you run the slave demon. Reading and Writing to Local Modbus Registers Use the MB Registers Manager VI to read from and write to the local Modbus registers. Only U16 words can be written to and read from the holding and input registers. If data types other than U16 are necessary, you must programmatically format the other data types to fit the U16 register structure. Refer to the LabVIEW documentation for information about formatting data types. You can write and read only Boolean values from the discrete inputs and coils registers.
Eltima Advanced Serial Port Terminal 6.0.382 + Crack [5MB] - Cybi Crack. 1- Download| Via UsersCloud; 2- Download| Via TusFile; 3- Download| Via Sf; 4- Download| Via UptoboX; 5- Download| Via boX; 6- Download| Via MEGA. Other Link Download: 1- Download| Via MirrorCreator. If You Enjoyed. Serial Port Monitor 6.0.235 Full Crack is here! - Serial Port Monitor is a powerful and professional application for RS232/422/485 COM ports monitoring. Eltima serial port monitor 6 crack 1. Analyze Serial Port Activity - After connecting to a COM port, Serial Port Monitor will will capture data in real time, allowing you to track down problems straight away. Monitor Multiple Ports - Serial Port Monitor can monitor several COM ports at once, which means you can analyze how apps interact with. Get Eltima Serial Port Monitor 6.0.235 for Free! Serial Port Monitor 6 Activation Code download, Serial Port Monitor 6.0.235 Patch, Serial Port Monitor 6 Crack.
Register Names and Addresses In most Modbus device configuration software, you must enter a name for the register you want to use. Per Modbus convention, the register address of the slave device, which is the PC or CVS-145 x device in this case, is calculated by subtracting 1 from the register name that you specify in the master device configuration software. When you are reading from or writing to a register on a Modbus device, be aware that LabVIEW expects register addresses rather than register names.
When you enter the register address to read from in LabVIEW, the value you enter must be the register name you defined in the Modbus device configuration software minus 1. The QTERM-G70 uses this naming convention. For example, a holding register name defined as 2 for the QTERM-G70 translates to register address 1 in the LabVIEW Holding Registers table. QTERM-G70 Holding Register Name = 2 LabVIEW Holding Register Address = 1 Some Modbus devices use register tables and addresses as shown in the following illustration. Because the register name and address tables do not overlap in LabVIEW, ignore the first digit, which indicates the register table.
In LabVIEW, you select the register table by name from a drop-down list. To determine the start address in LabVIEW, enter the number after the register table number. For example, a register name defined as 0x40000 in a Modbus configuration device translates to register address 0 in the LabVIEW Holding Registers table. Modbus Device Holding Register Name = 0x40000 LabVIEW Holding Register Address = 0 Some devices, such as the EZTouch Panel, require both of these concepts.
You must subtract 1 from the register name that you specify in the master device configuration software and ignore the first digit of the start address to ensure proper register addressing. For example, a register name defined as 0x40008 in the EZTouch Panel translates to register address 7 in the LabVIEW Holding Registers table. EZTouch Panel Holding Register Name = 0x40008 LabVIEW Holding Register Address = 7 Reading from the Local Modbus Registers Complete the following steps to set up the MB Registers Manager VI to read from the local Modbus registers:. Drop the All Functions»Select a VI» NIModbus.llb»MB Registers Manager.vi. On the block diagram.
Right-click the Function terminal, and select Create»Constant. In the constant, select Read to read a specific register, or select Read All to read all 65536 registers. Right-click the Table terminal, and select Create»Constant. In the constant, select the register table you are reading from.
Right-click the Start Address terminal, and select Create»Constant. Enter the local register address at which to start reading data. The Start Address terminal is necessary only when you have set the Function terminal to Read rather than Read All. Right-click the Length terminal, and select Create»Constant. Specify the number of registers to read. The Length terminal is necessary only when you have set the Function terminal to Read rather than Read All. Right-click the Words Out terminal, and select Create»Indicator.
This indicator displays the U16 data read in from the holding and/or input registers. Use the Words Out terminal only when you select either Input Registers or Holding Registers in the Table terminal. Right-click the Bits Out terminal, and select Create»Indicator. This indicator displays the Boolean data read in from the discrete input and/or coils registers. Use the Bits In terminal only when you select either Discrete Inputs or Coils in the Table terminal.
Writing to the Local Modbus Registers Complete the following steps to set up the MB Registers Manager VI to write to the local Modbus registers:. Drop the All Functions»Select a VI» NIModbus.llb»MB Registers Manager.vi. On the block diagram.
Labview Modbus Serial Example Free
Right-click the Function terminal, and select Create»Constant. In the constant, select Write. Right-click the Table terminal, and select Create»Constant.
In the constant, select the register table you are writing to. Right-click the Start Address terminal, and select Create»Constant. Enter the local register address at which to start writing data. Right-click the Length terminal, and select Create»Constant. Specify the number of elements from the array to write to the local registers. Wire the appropriate U16 data to the Words In terminal.
This is the data you send to the holding and/or input registers. Use the Words In terminal only when you select either Input Registers or Holding Registers in the Table terminal.
Wire the appropriate Boolean data to the Bits In terminal. This is the data you send to the discrete inputs or coils registers. Use the Bits In terminal only when you select either Discrete Inputs or Coils in the Table terminal. Stopping the Modbus Serial Slave Demon and Closing VISA Sessions The final steps of your Modbus application must properly close all resources that were opened. Complete the following steps to close resources:. Go to All Functions»Select a VI.
In the dialog box, select NIModbus.llb»MB Globals.vi. Click the MB Globals variable, and select Slave Demon Running. Right-click the Slave Demon Running global variable, and select Create»Constant. Set the constant to False. Drop the All Functions»Application Control»Close Reference VI on the block diagram. Wire the vi reference output from the Open VI Reference VI that you added in the Set Up the Modbus Serial Slave Server section to the reference input on the Close Reference VI.
Drop the All Functions»Instrument I/O»Serial»VISA Close VI on the block diagram. Wire the VISA resource out terminal of the MB Serial Init VI to the Visa resource name terminal of the VISA Close VI. LabVIEW as a Modbus Master Device Modbus Master Device Setup The master device in a Modbus system does not contain any Modbus registers. The Modbus device sends read and write commands to the slave devices on the bus. Complete the following steps to set up a master device, such as a CVS-145 x device or PC, to use LabVIEW to communicate with Modbus slave devices on the same serial bus:.
Set up and initialize the COM port. Drop the All Functions»Select a VI»NIModbus.llb»MB Serial Init.vi in the LabVIEW block diagram.
Use the Create»Constant item in the right-click menu to create controls or constants for all of the inputs, and modify the serial settings to ensure that the master and slave devices match:. VISA resource name – Select the COM port that the slave devices are connected to. Baud Rate – Default is 9600. Parity – Default is None.
Flow Control – Default is None. Timeout – Default is 10000 ms. Mode – Default is RTU Note: These serial settings must match the slave device you are connected to. Sending Read and Write Commands to Modbus Slave Devices Use the MB Serial Master Query VI to send both read and write commands to slave devices over the serial bus. Complete the following steps to set up the MB Serial Master Query VI to read commands from the Modbus device:. Go to All Functions»Select a VI. In the dialog box, select NIModbus.llb»MB Serial Master Query.vi.
Set up the Modbus Command Cluster Input elements as appropriate:. Function Code – Select the action you want to perform. Starting Address - Indicate the register address to start reading/writing data. Quantity – Specify the number of registers to be read or written to. This element is not used when either Write Single Coil or Write Single Register is selected in Function Code. Data – This is the U16 array of data to be written to the slave holding registers.
This element is used only when either Write Single Register or Write Multiple Registers is selected in Function Code. Discrete – This is the Boolean array of data to be written to the slave coil registers. This element is used only when either Write Single Coil or Write Multiple Coils is selected in Function Code.
Set up the Serial Parameters Cluster Input elements as appropriate:. Mode – Select RTU or ASCII. Slave Address – Specify which slave device to read from or write to. Read the Registers Cluster Output elements as appropriate:. Registers – Outputs an array of U16 values when Read Holding Registers or Read Input Registers is selected in Function Code. Discrete – Outputs an array of Boolean values when Read Coils or Read Discrete Inputs is selected in Function Code. Release the COM Port Complete the following steps to close the VISA session opened by the MB Serial Init VI:.
Drop the All Functions»Instrument I/O»Serial»VISA Close VI on the block diagram. Wire the VISA resource out terminal of the MB Serial Init VI to the Visa resource name terminal of the VISA Close VI. LabVIEW Modbus Examples The NIModbus.llb includes two example programs: MB Serial Example Master and MB Serial Example Slave. If two COM ports are available on your PC, you can run both VIs to implement a Modbus master device and Modbus slave device simultaneously on the same computer. Use a null modem serial cable to connect the two COM ports. LabVIEW As a Slave The MB Serial Example Slave continuously reads the first four registers of its local coil and holding register table. The VI writes Boolean and U16 values to the first four registers of its local discrete register table and input register table, respectively.
The MB Serial Example Slave VI contains functions to open the MB Serial Example Slave VI and open a VI reference, which are wired into a series of sequence structures, and a while loop that are used to achieve its functionality. The outer sequence structure handles the following functions:. Initializing the modbus registers. Setting up the serial slave. Using a while loop to read and write from registers.
Write to discrete input registers. Write to input registers. Read from coils and holding registers. Include a delay.
Closing the serial slave demon. Closing the VISA resources and the VI references LabVIEW As a Master The MB Serial Example Master VI writes Boolean and U16 values to the first four registers of the slave coil table and holding table, respectively. The VI continuously reads the first four registers of the slave discrete register table and input register table. The MB Serial Example Master VI contains a series of sequence structures and a while loop that are used to achieve its functionality. The outer sequence structure handles the following functions:. Initializing the VISA resource. Using a while loop to read and write from registers.
Write to coils input registers. Write to holding registers. Read discrete input registers. Read input registers.
Include a delay. Closing the VISA resources and the VI references Running the Examples The MB Serial Example Slave VI reads and writes to local registers, and the MB Serial Example Master VI polls the local registers on the slave device. When the MB Serial Example Master VI is reading registers, it polls the registers on the slave device and displays the data on the master device. The MB Serial Example Master VI also writes to registers on the slave device. Complete the following steps to run the MB Serial Example Slave VI and MB Serial Example Slave VI:. Ensure that the COM ports you want to use are not currently in use.
National Instruments suggests you exit Vision Builder for Automated Inspection (Vision Builder AI) before running these examples to ensure that the COM port you want to use is not already being used by a Vision Builder AI script. Launch the example VIs:. Launch LabVIEW.
Click Open and navigate to NIModbus.llb»MB Serial Example Slave VI. Click Open again and navigate to NIModbus.llb»MB Serial Example Master VI.
Select the appropriate COM port in the VISA resource name control for each of the VIs. Click Run in each of the VIs. Flip the switches in the Discrete Inputs section of the MB Serial Example Slave VI, or flip the switches in the Coils to Write section of the MB Serial Example Master VI. The corresponding LEDs on each example VI light to indicate which registers are set to true. Enter values in the Input Registers section of the MB Serial Example Slave VI, or enter values in the Registers to Write section of the MB Serial Example Master VI. These changes are displayed in the Holding Registers section of the slave example VI and the Input Registers section of the master example VI.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |