Example of device-control telegrams?

[mk42]

I created a request/response protocol but it is unfamiliar to the PLC programmer, who is using the terms cyclic, acyclic, and telegrams (which are all new to me!).

I'd like to learn what it is that a PLC programmer expects in terms of communication to/from devices, so that I can better accommodate him. Can anyone provide examples?

There's been good discussion of Modbus TCP, and I think that's potentially a good direction for you to go (if your customer is willing). Since I didn't see anyone actually define the terms you're unfamiliar with, I figured I'd include some background. Apologies if this is below your level, making some assumptions.



All PLC logic is based on the scan cycle, a big loop of code. The basic version is that each scan, it reads the inputs, executes all the code once, and then writes the outputs. Then it does it all over again. Each scan is typically between 1 and 50 milliseconds.

• Cyclic: Many PLCs control devices out in the field (motors, pushbuttons, indicator lights, etc). The data to/from those devices are sent at a defined cycle. Every X milliseconds (often 2/3/8ms) each device sends a packet of data to the controller, and the controller sends the data to the device.
• Acyclic: Sometimes there is extra data that is only sent occasionally, as needed. This could be sending a request to another system for new recipe parameters at the end of each part, or responding to a request from another system like an HMI (industrial GUI) to display.
• Telegram: This is a defined set of data used in communication. It is usually cyclic. The entire telegram (often 10 bytes or less) is transferred every time, even if certain parts of the data may not be useful this message. In the example of a drive controlling a motor, the PLC will send a command telegram (enable, run, speed setpoint, etc), and the drive will respond with a status telegram (enabled, running, actual speed, etc). Even if the drive isn't moving, it still sends back that the speed is 0, because it's in the defined telegram.

My read is that the customer has experience and expectations related to Profinet, as that is the protocol that the 1200 has built in HW support for (and uses the above terms). The system also has application level support for Modbus TCP, and that option would have the most cross platform support across PLC brands.

 

[zoomable]

I may be wrong about this, but the S7-1200 supports OPCUA server functionality. I was talking about OPCUA client, which I have only seen in Codesys and TwinCAT. There may be other PLCs with OPCUA client function that I am not aware of.

It's all built in, with OPCUA licence. The S71200s provide mapping between PLC DB and OPCUA server interface. It is thus that the PLC gets OPCUA client functionality.

There are some function blocks for PLC programmer to use for OPCUA - https://cache.industry.siemens.com/...109756885_OpcUa_ServerMethods_DOC_V1_2_en.pdf. For example multiple nodes can be written/read at once.

The downsides to using OPCUA for control are:

- no protocol; e.g. you need to manage "connectivity/session status" between the two clients yourself (PLC and PC; can be done with heartbeat), and master/slave behavior is implicit in program design; to enforce it explicitly (for correctness) takes much more programming effort on both ends.

- speed; OPCUA cycle time is adjustable to a point? slower than MBTCP?


Does anyone know off the top of their head how many Modbus TCP clients an s712xx supports?

z

 

[mk42]

I may be wrong about this, but the S7-1200 supports OPCUA server functionality. I was talking about OPCUA client, which I have only seen in Codesys and TwinCAT. There may be other PLCs with OPCUA client function that I am not aware of.

Oh, I think you're right; apologies, missed you were talking about client. 1500 supports client and server, but 1200 is only server, last I heard.

- speed; OPCUA cycle time is adjustable to a point? slower than MBTCP?

Does anyone know off the top of their head how many Modbus TCP clients an s712xx supports?

My experience with OPC UA is that the speed depends somewhat on the server and client, but if you get 100ms turnaround you should be pretty happy, 200ms-500ms is more common, since the normal use case is closer to SCADA than machine control.


From the tech specs, a 1214 has 8 connections reserved for TCP (which Modbus TCP is of course built on) and max 14.

 

[zoomable]

Within Modbus TCP, what are inputs and outputs defined as, from the perspective of the slave (server)?

Must be:

Input -- input from master/client?
Output -- output from slave/servert?

If so, how are inputs and outputs distinguished/mapped to Modbus address space? Just segments of registers I guess?

Thanks
z

 

[drbitboy]

Within Modbus TCP, what are inputs and outputs defined as, from the perspective of the slave (server)?

Must be:

Input -- input from master/client?
Output -- output from slave/servert?

Yes. Everything [Discretes* Input; Coils; Input Registers; Holding Registers] in the Modbus Data Model is either an input or an output relative to the point of view of the Modbus Server device.

Modbus Server device inputs: Discretes* Inputs @ 1 bit each; Input Registers @ 16 bits each.

Modbus Server device outputs: Coils @ 1 bit each; Holding Registers @ 16 bits each.

The Modbus Client reads data from, or writes data to, the server's Data Model.

Modbus Server device inputs can only be read by the Modbus Client (which makes sense: they are inputs to the Server device, which Server device is reading them e.g. via input module/card).

Modbus Server device output can be read or written to by the Modbus Client. Holding registers (16-bit integers) are kind of fuzzy: they could be analog outputs on an analog output module/card e.g. written to by Modbus Server device-internal logic such as a PID or other feedback controller; or they could be parameters used internally by the Modbus Server device e.g. an enumeration that tells the device whether the units of input values are to be converted to litre/hour or firkins/fortnight when read via Modbus request.

If you have not yet found the Technical Documentation on modbus.org, I suggest going there.

* "Discretes" is, I think, a typo in the Modbus documentation (which typo I am perpetuating ; see item (iv) below).

If so, how are inputs and outputs distinguished/mapped to Modbus address space? Just segments of registers I guess?

The mapping, from the Modbus Server device's internal data model to the Modbus Data Model addresses is the purview of the Modbus Server device only. The Modbus Client must know beforehand what each numeric address means e.g. "Holding register 0001 is the [Encabulator Tenperature]." There is no text-based self-description e.g. XML schema made available to the Modbus Client.

If you are familiar with Web APIs, it's like one of those with four interfaces:

• https://my.host.name/DiscretesInput?addr=10-20
• https://my.host.name/InputRegisters?addr=100-150
• https://my.host.name/Coils?addr=5-6&write_vals=true,false
• https://my.host.name/HoldingRegisters?addrs=3-3&write_vals=0o177777

Where the [&write_values=...] API parameters are optional, and

• EITHER the presence of those [&write_values=...] parameters tells the interface to write those values to those outputs,
• OR the absence of those [&write_values=...] parameters tells the interface to read the current values of those outputs.

So each one of those Web API interfaces (/DiscreteInputs, /Coils, ...) is analogous to one of the Modbus Function Codes (0x02 Read Discrete Inputs, 0x01 Read Coils, ...) in a Modbus request.

 

[AlfredoQuintero]

I understand your application is not a typical HMI or SCADA application in which the application requests data to the PLC and occasionally sends commands to it. (I may need to be corrected on this). I think you wrote that the PC is itself an industrial device that needs to be controlled by a PLC. That is why I suggested that your application acts like a Modbus TCP server of the PLC's Motbus TCP client.
Talking from the Modbus TCP client's point of view, the input from the server and the output to the server are mapped in different buffers. I would recommend you to download the Modbus specification which is available free of charge.
https://modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf

 

[danw]

The Modbus spec is a truly open spec and the specs can be downloaded from Modbus.org
https://modbus.org/specs.php
after agreeing to the terms

Coils (outputs) are typically mapped to the coil registers (0)xxxx or (0)xxxxx where the leading numeral 0 is a human indicator digit that the register is a coil and the numeral 0 is not part of the Modbus message. Coils are read by the client using Function Code 01. The client writes to a coil register using Function Code 05 (write single coil) or Function Code 15 (write multiple coils to sequential, contiguous registers).

Digital Inputs (inputs) are typically mapped to discrete registers (1)xxxx or (1)xxxxx where the leading numeral 1 is a human indicator digit that the register is a discrete register and the numeral 1 is not part of the Modbus Message. Discrete inputs are read by the client using Function Code 02. There is no Modbus Function code to write DI values.

Input registers are 16 bit registers that are read-only, typically used for analog values, but can be any 16 bit data word the vendor so decides. Input registers are mapped to (3)xxxx or (3)xxxxx where the leading numeral 3 is a human being indicator digit that the register is an Input Register and the numeral 3 is not part of the Modbus message. Input Registers are read by Modbus Function Code 04.

Holding Registers are 16 registers that are read-only or read-write, typically for analog values but can be any 16 bit data word the vendor so decides. Read or read-write is a vendor decision. Holding Registers are mapped to (4)xxxx or (4)xxxxx where the leading numeral 4 is not part of the Modbus message. Holding registers are read by Modbus Function Code 03. A client writes to Holding Registers using Modbus Function codes 06 (single register only) or 16 (decimal, or 0x10) multiple sequential/contiguous registers.

I have seen some wireless gateways use one Holding register (read-only) for each discrete input or one Holding Register for one coil (read/write).

Modbus does not know or care about the data in the registers. Modbus does not define numerical formats. By convention, a 32 bit IEEE754 floating point value uses 2 contiguous Holding Registers and it's up to the client to interpret the word/byte order appropriately. The server frequently scales integer data by some factor, 10x or 5x with the expectation that the client scales the data upon receipt.

 

[drbitboy]

The "device" needs to be told to run or stop (with parameters), and needs to provide its status and results.

So in the Modbus Data Model implemented in the PC (the Modbus Server device):

• the RUN and STOP bits would be Coils to be written to by the PLC (S7-1200; the Modbus Client device);
• the parameters to control how the device operates would be Holding Registers to be written to by the PLC;
• any status bits (running, error, alarms, etc.) would be Discretes Input bits to be read by the PLC;
• any results (temperature, piece count, etc.) would be Input Registers to be read by the PLC.

 

[zoomable]

Awesome. You guys ROCK!

 

[drbitboy]

the [leading] numeral 0 is not part of the Modbus message.
...
the [leading] numeral 1 is not part of the Modbus Message.
...
the [leading] numeral 3 is not part of the Modbus message.
...
the leading numeral 4 is not part of the Modbus message.

@danw has pointed out a very important item here.

There is a convention that shows up in the dialog menus for configuring Modbus Clients, including those for the MB_CLIENT instruction in TIA Portal for the S7-1200 PLC.

Instead of specifying a single function code (which would define almost everything about the type of transfer: data type; data direction i.e. read vs. write) and the offset address, when you tell your PLC programmer that they need to write a 16-bit value to the SPEED parameter in the Holding Register at address offset 99 (the one-hundredth Holding Register) of your PC's Modbus Server device's Holding Registers, you need to tell him to WRITE (MB_MODE = 1) to Data Model address MB_DATA_ADDR=40100 or MB_DATA_ADDR=400100. That will cause the PLC S7 MB_CLIENT instruction to send a TCP request with

• a Function Code of either 0x06 or 0x16, and
• an address offset of 99
  • N.B. not 100 and not 400100!

If you searched through this forum, probably 90% of Modbus addressing problems involve that off-by-1 issue.

 

[drbitboy]

Awesome. You guys ROCK!

haha. I'd give it all up if some of my neurons could be assigned to something useful, like my grandchildren's birthdays (instead of this dreck )

 

[zoomable]

@danw has pointed out a very important item here.

There is a convention that shows up in the dialog menus for configuring Modbus Clients, including those for the MB_CLIENT instruction in TIA Portal for the S7-1200 PLC.

Instead of specifying a single function code (which would define almost everything about the type of transfer: data type; data direction i.e. read vs. write) and the offset address, when you tell your PLC programmer that they need to write a 16-bit value to the SPEED parameter in the Holding Register at address offset 99 (the one-hundredth Holding Register) of your PC's Modbus Server device's Holding Registers, you need to tell him to WRITE (MB_MODE = 1) to Data Model address MB_DATA_ADDR=40100 or MB_DATA_ADDR=400100. That will cause the PLC S7 MB_CLIENT instruction to send a TCP request with

• a Function Code of either 0x06 or 0x16, and
• an address offset of 99
  • N.B. not 100 and not 400100!

If you searched through this forum, probably 90% of Modbus addressing problems involve that off-by-1 issue.

Thanks for the heads up! We start integration tomorrow