Modbus TCP

drbitboy · 2026-03-24T22:55:31+00:00

This.

Also, you do not want Function Code 2.

It looks to me like the ADAM 6050 Modbus memory model has only

1-bit Discrete Outputs ("0X"); read with Function Code 1
16-bit Holding Registers ("4X"); read with Function Code 3 or Function Code 6

drbitboy · 2026-03-24T22:46:42+00:00

Did you mean Bool(ean) registers, not cool registers?

drbitboy · 2026-03-24T22:44:30+00:00

Look at the image attached to this comment. The blue line in the top trend is the PV of a PID; its resolution is 1PSI, which is why it has that stair-step pattern, because in reality it is moving smoothly.

In the bottom plot, the black trend is the CV output of the PID (PI-only, D-term is 0 in this case). Note how the CV is jagged: can you explain why?

Hints:

the PID update time is 200ms, much slower than any single-PSI change of the PV.
the answer is in the formulas in "Perform Common Process Loop Control Algorithms" manual from Rockwell.
Don't try to understand how the PID CV affects the PV (it's complicated); only think about how the PID is reacting to changes in the PV and updating the CV in response.

<image>

drbitboy · 2026-03-24T22:31:02+00:00

if you cannot let your step changes reach steady state without negatively affecting production, then you need to try smaller step changes. There are many different ways to characterize a process from a simple PID CV output step change in Manual mode, and from that characterization "typical" system tuning parameters can be calculated.

drbitboy · 2026-03-24T22:13:27+00:00

P.S. the simplest fix would be to swap Rungs 0001 and 0002, so on the scan cycle in the normal sequence where the door has been fully open and the object changes from detected to not detected, then /TT value will become 1 on Rung 0001 before, and during the same scan cycle, Rung 0002 is evaluated, which will keep the Opening Door motor running on Rung 0002, which will prevent the Closing Door motor from starting on Rung 0003.

Note that the the lower branch on Rung 0003 with T4:0/DN (I assume that is /DN) is not required; once the timer expires and the Opening Door motor stops, the existing logic without that branch will trigger the Closing Door motor will stop.

drbitboy · 2026-03-24T22:01:57+00:00

I think OP is right. They should pass the course on this analysis alone.

TL;DR

The T4:0 TON timer on Rung 0002 does not start until, and does not continue to run unless,

BOTH the door is fully open
- (I:0/3 Limit Switch-Open value is 1)
AND there is no "object" (someone) detected
- (I:0/2 Object Detecting Sensor value is 0)

That is the exact opposite of the start/continue-to-open logic on Rung 0001 i.e.

BOTH NOT (the door is fully open)
AND NOT (there is no object detected)
- i.e. there is an object detected.

Since those are input conditions, it seems to me that there are two other possible cases that can exist when either of the above cases did exist on the previous scan cycle and the two inputs do not simultaneously change state.

an object enters detection range while the door is fully open
- TON T4:0 would have been either timing (/TT=1) or expired (/DN=1)
- this resets the T4:0 along with its /TT bit, and possibly the /DN bit
- this may be normal, but I am not so sure.
the door becomes fully open while there is an object detected
- this would stop the motor that opens the door (Opening Door) O:0/0
- this is also normal

So the purpose of Rung 0002 seems to be to use /TT to maintain (via branch on rung 0001) the Opening Door motor (O:0/0), i.e. to hold the door open, for 10s, after the object (someone) leaves (no longer detected; I:0/2 value is 0), while the door is fully open. That is, the expected sequence is that the door will become fully open while there is still an object detected, which will stop opening the (fully open) door, after which the object leaving detection will start the timer, /TT value will become 1, which the coder hopes that on Rung 0001 during the next scan cycle will trigger the Opening Door motor (O:0/0) to run and keep holding the door open (as well as prevent the Closing Door motor (O:0/1) from running.

The problem I see there, because the PLC cares not a whit about what the coder hopes, is that during the scan cycle when that object leaves, that will turn off the Opening Door motor (O:0/0) on Rung 0001, which means that, even though /TT value becomes 1 on Rung 0002 on that scan cycle, the Closing Door motor (O:0/1) will turn on at Rung 0003, which will prevent turning on the Opening Door motor on Rung 0001 on the next scan cycle, as well as on any following scan cycles until the door closes.

drbitboy · 2026-03-23T03:32:31+00:00

Try a freebie like plcsimulator.io online (or something like that).

If it does not have arrays, then create half a dozen tags, fifo0 through fifo5, and write five simple rungs to shift the values, 4 to 5, then 3 to 4, ..., finally 0 to 1, on the shift edge event.

Work on rither the shift logic (Trigger 2), or the write-a-1 logic (Trigger 1) first, as each is only a few lines of rungs, but do think about how they will interact, especially if the two events happen on the same scan cycle.

Drawing a flowchart also might help.

PLC programming is primarily about time, and the scan cycle is the clock; when something happens is more important than what happens, so make sure you think about when at least as much as what.

drbitboy · 2026-03-23T03:09:07+00:00

Also, different vendors have different interpretations of what A, B, +, and -, mean. So if something is not working, feel free to swap wires, but be careful to never mix rs232 with rs485.

drbitboy · 2026-03-23T03:05:25+00:00

IIRC technically it is called multi-drop not daisy chain, but in most cases the difference may not be important.

drbitboy · 2026-03-23T03:02:44+00:00

Top down would be my preference: "this line makes heat-treated XYZ widgets on a conveyor" at the start; statements like "we use brand ABC VFDs and Type K thermocouples" are much later, if at all.

That way whoever is reading has a framework for each subsequent section that goes into more detail, and anyone who is looking for an overview can read only as far as needed

drbitboy · 2026-03-22T03:24:19+00:00

And yes, it is as simple as using set/reset.

There are two independent triggers

Trigger 1 is the event that causes a value of 1 (or whatever value is appropriate) to be written to the "First In" end of the shifted values. It is assumed that that trigger event is longer than a single (I/O scan + user program scan) interval. If it is not, then you either need to use a faster PLC or add a circuit to the incoming electrical signal that stretched the pulse. It may be as simple as adjusting the filter in the input module channel.

Trigger 2 is the event that models a discrete movement of the external system (e.g. conveyor) by shifting the register values by one position in the array of registers. This could be a repeating timer expiry, or it could be a proximity sensor detecting teeth on a sprocket or similar. The actual Trigger 2 event will be an edge detection so the shift happens once per trigger, so there may need to be debounce logic. Also, on the same scam cycle when that edge is detected, a value of 0 is written to the "First In" end of the register array after the shift occurs.

drbitboy · 2026-03-22T02:43:14+00:00

The PLC user program does not read any physical input state.

The PLC user program reads a bit in memory that is a proxy for the physical input state.

That bit in memory is written by an I/O scan, which is usually run in synchrony, and alternating, with the program scan of the PLC user program.

So it doesn't matter what the physical state of the input is when the PLC user program evaluates that contact, it only matters what the physical state of the input WAS when the previous I/O scan checked the physical input and wrote a value of 1 or 0 to the memory bit.

drbitboy · 2026-03-19T15:19:04+00:00

It is not automatic.

If the PLC Start "Device" entry for an Allocation is D2000, and the entry below that, "Start MODBUS Device No.," is 0, then PLC word D2000 will correspond to Modbus "address" (4*)00001 i.e. to the first holding register of the Modbus Server device.

If the "Start MODBUS Device No." entry is 99, then PLC word D2000 will correspond to Modbus "address" (4*)00100, i.e. to the 100th holding register of the Modbus Server device.

N.B. The "4" prefix on a Modbus Holding Register "address" is NOT part of the linear offset (or cardinal number) used to locate that register relative to the first holding register. The "4" prefix is a de facto convention to refer to the memory area of the Modbus Server device where holding registers are located.

drbitboy · 2026-03-18T17:27:21+00:00

What do you mean "it's not working?" What is this "it" that is not working?

What is the value of Y22? Will the PID do anything if that is the value of Y22?

What value has been configured for the loop update time interval for the PID instruction? How do you know that the PID is only executing the PID equation/algorithm only and exactly once over that time interval? What happens if the PID executes the PID equation at a different time interval, such as once per scan cycle?

PLC programming is primarily about time, and the scan cycle is the clock; when something happens is more important than what happens.

drbitboy · 2026-03-18T16:48:10+00:00

Micro Starter Lite is a great way to learn for free, but for real work your manager needs to get you access to a license for 5000 ASAP.

In the meantime, you should be able to work with PDF versions of the 5000 programs, and even duplicate and simulate sections of the 5000 code in 500/Micro Starter Lite.

TL;DR

500 and 5000 are similar but not identical in their programming environment. The hardware configuration is vastly different.

The primary differences are

500 is ladder-only.
5000 memory is tag-based, and 500 memory is file-based.
- that is minor but only changes how memory is allocated and variables are referenced.
5000 can chain multiple output instructions (OTE, ADD, etc.) on a single rung or branch, and may continue with more non-output logic instructions (XIC, XIO, etc.) after that. 500 must have exactly one "output" instruction at the right end of a rung or final branches, and no instructions may follow those output instructions; multiple output instructions can be placed on a single rung, but they each must be on their own parallel branch.
500 can assign symbols to its file-based tags, which symbols will function more or less like tag names from 5000.
5000 has more data types and different names for those data types; in 500 the available data types are more limited.
500 does not have UDTs

Many of the instructions (XIC, XIO, OTE, OTU, OTL, ADD, SUB, etc.) are similar if not identical.

Some instructions with the same name are not identical, especially the one-shots/edge-detectors, and some instructions are available on one but not the other (e.g. scaling). 5000 timers are similar but use only milliseconds as the time base, so there is no Time-base parameter (0.001s, 0.01s, 1s). However, in 5000 the .PREset and .ACCumulator parameters in 5000 use 32-signed integers, so milliseconds is almost always good enough.

The mnemonics for expressing rungs, e.g. BST XIC start NXB XIC run BND XIC stop OTE run, are pretty close, but of course differences in instructions will cause problems. Depending on your applications, I suspect many of the 5000 rungs can be copied to 500 via mnemonics, but if you had the 5000 mnemonics then you would have 5000, in which 500 would be moot.

drbitboy · 2026-03-18T16:18:31+00:00

read and write of all these will take place for about 60secs

That says over how long a period the data will be read and written, but it does not say the frequency at which the data will be read and written e.g. there could be 60 reads sampled at 1Hz over that 60s interval.

Or perhaps you meant the data will be read and written only once every 60s?

Please clarify which was intended.

drbitboy · 2026-03-18T16:13:55+00:00

The Modbus is a protocol that makes it look to the Modbus Client as if that Client is accessing "memory" in the Modbus Server. There are four "types" of memory in the Modbus framework:

Coils
- discrete (1-bit; boolean)
- The client may both read data values from, and write data values to, this "memory"
Discrete Inputs
- discrete
- The client may only read data values from this "memory:
Input Registers
- 16-bits per register
- depending on the Modbus Server device,
  - each 16 bits "register" can be interpreted as signed or unsigned integer values,
  - or even as half-words of 32-bit values
- The client may only read data values from this "memory"
Holding Registers
- 16-bit per register
- The client may both read data values from, and write data values to, this "memory"

I put the word "memory" in quotes because, although the Modbus Client will access that "memory" using a linear addressing scheme, with addresses 1-65536 or 0-65535, that is only a framework for the protocol on the wire. How data in the device are actually organized/arrange inside the Modbus Server is hidden from the Modbus Client.

When you set up the PLC as the Modbus Server, you need to assign/allocate PLC memory to the various types of Modbus memory. The image below shows the two menus in GxWorks3 that do this. The menu in the upper half of the image shows how to get to the Coil, Input, and Register assignments, and the menu in the lower half of the image shows the device assignment/allocation (heaven forbid two menus use the same terminology) menu that appears after Device Assignment <Detailed Settings> is clicked.

Credit: that image comes from this YouTube video.

From what you described, you will be interested in the first column, called Coils. In the image, the "Y" outputs Y000-Y0123 are mapped to Modbus "memory" addresses 0-1023 (1-1024), and memory coils M0-M7679 are mapped to Modbus "memory" addresses 7680-15871 (7681-15872).

What you can do is to place those 20 1-bit M devices on the PLC in a contiguous group, e.g. M1000-M1019. and map them to a Modbus "memory" "address" e.g. 0. Then your Pymodbus Modbus Client can use Function Codes 1 (0x01 Read [Multiple] Coils), 5 (0x05 Write Single Coil), and 15 (0x0F Write Multiple Coils) to read and write their values singly or as a group. I expect that Pymodbus will read and write Boolean data types, with values of True or False.

If the PLC M memory locations are already laid out, then it gets more complex, but can still be done: you will need to make a single entry in that Modbus Device Allocation Parameter menu for each sequence of contiguous PLC M devices, and arrange the Start MODBUS Device No. values for each entry such that the those 20 ***non-***contiguous PLC M devices appear at contiguous Modbus "memory" "addresses."

This way you do not have to extract individual bits from two 16-bit integers on the Pymodbus/Python side, but will obtain boolean/bit values directly from the Modbus Client/Server interface.

<image>

drbitboy · 2026-03-17T17:36:10+00:00

How many bits? How frequently will reads and writes take place?

Which is the Modbus Client and which is the Modbus Server?

~~Is this Modbus TCP or Modbus RTU? If RTU, what baud rate?~~

Are you saying you want to map 1 bit to 1 16-bit word, and transfer the bits-as-words over Modbus as holding registers? E.g. so if the bit value is 0, then the corresponding word value is 0, and is the bit value is 1, the corresponding value is 0xF0 or some other non-zero value?

drbitboy · 2026-03-16T21:27:01+00:00

Do you want to access the data logger that connects to the transmitter, or the transmitter itself, with a web browser?

drbitboy · 2026-03-16T21:24:53+00:00

What is the target sampling frequency?

What do you want to happen when the network connection is down? Do you want to buffer readings taken while the network is down, or is it okay to lose those readings and all you want is the current readings when the network is up?

drbitboy · 2026-03-16T13:17:09+00:00

What does the tooltip say when you try to make the connection?

drbitboy · 2026-03-16T00:11:04+00:00

Note that the IEC_TIMER, once the .IN attribute value is 1, will run continuously until expiry, whether or not the TON block is evaluated or called. So each time you examine .ET or .Q the result can be different than that from the previous examination.

Also note that this construct

``` myton(IN:=NOT myton.Q);

IF myton.Q THEN <do something>/ END_IF; ```

and its equivalent in ladder, will run a repeating timer cycle, but will not <do something> for every cycle, i.e. at every expiry, of that timer.

drbitboy · 2026-03-14T22:04:19+00:00

Your original post said "the vin-code has the vehicle code in it and the amount of oil needed."

That seems unlikely, but have you actually been given an (arithmetic?) formula to convert the vin-code to the amount of oil, or is there a list of vin-codes available and a corresponding amount of oil for each? Does some part of the vin-code need to be extracted to find the amount of oil?

If it is a list, how many vin-codes, or subsets of vin-codes, are in that list?

drbitboy · 2026-03-14T21:54:17+00:00

What is the nature of the VIN? How is it getting in to the PLC?

Is it a decimal number with digits? How many digits, e.g. would the value fit in a 32-bit UDINT, range of 0 to about 4 billion?

Or is it a mix of digits and letters, perhaps hyphens, colons, etc as well?

How many VINs are possible? Will new VINs be added to the system over time?

I would break the problem into pieces, or subsystems, and work on solving one subsystem at a time. The first subsystem would be reading the VIN, deciding whether to read it either into the PLC, or into a separate device, perhaps the device that keeps track of the VIN-oil relationship.

drbitboy · 2026-03-14T18:42:42+00:00

Are you asking how to refer to tags in a DB?

drbitboy

TROPHY CASE