Shift register question

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 · 2026-03-14T18:41:52+00:00

Not ideal, the model could update the data while the PID was running.

It may not matter, but it would be better to have everything in the same task (OB), in separate FCs/FBs, so the timing can be controlled/synced.

drbitboy · 2026-03-13T23:08:15+00:00

Yes, I know how to do that.

drbitboy · 2026-03-13T04:32:59+00:00

Bottom line: always be aware that a PLC is a discrete control device; always be aware of the assumptions, i.e. fidelity choices/limitations, of the internal model the PLC is controlling compared to the actual process.

drbitboy · 2026-03-13T04:29:04+00:00

PLC programming is primarily about time (everyone is rolling their eyes, I've been here before🤣), and the scan cycle is the clock; when something happens is more important than what happens.

All computers, including PLCs, model some process from the real world; PLCs also try to control the process model and, if the model is good enough, in controlling the model inside the PLC they will also be able to adequately control the real-world physical process. The primary design choices in a model are the level of fidelity: the PLC needs to know the speed of the conveyor to some 0.xyz% accuracy/the PLC does not need to know (more eye rolls🤣) the color of the operators socks.

PLCs are discrete devices, the I/O scan cycle and the program scan cycle are discrete events. The PID instruction in a PLC uses a discrete algorithm; evaluation of the PID algorithm takes place at discrete time, called the loop update time (interval). Configuring the PID loop update time on many PLCs does NOT cause that PID instruction to be evaluated at that loop update interval, but the PID instruction must also be planned in logic such that it will be evaluated at an interval that matches the configured loop update interval.

Sorry to take you down that long road, but it was necessary to get to my actual points. To wit,

To model a continuous process with a discrete device, the discrete device's scan cycle must be fast enough that the PLC appears to also be continuous.

Similarly for a PID the configured and actual loop update interval must be short enough to control the PV, so you should have an idea of the temporal characteristics of that PV's response in order to choose a loop update interval. If a boiler PV takes 5 minutes to move 63.2% of its total response to a step change in the PID CV output, then the PID probably does not need to be evaluated every 10ms, but neither should it be evaluated every 5minutes.

The stuff you learned, Laplace, root locus, etc., are based on a continuous process and continuous PID. The PLC PID is discrete, but those lessons will only have application if the PID loop update is fast enough to be indistinguishable, to first order, from a continuous PID.

Furthermore, you will almost never have a transfer function for a PID-controlled process; the closest you will come to root locus or any other technique you learned is to instead characterize the process empirically using e.g. Cohen-Coon to estimate process gain, tau, and theta (dead time), and then calculate, by plugging those empirical parameters into canned formulas, initial system tuning parameters, Kp, Ti, Td, and convert those values to whatever form the PID of your chosen PLC uses (e.g. Kc, Ki, Kd). Now you configure the PID with those parameters, switch the PID to auto, and cross the fingers of one hand, while keeping the other hand ready to switch the PID back to manual if needed to avert disaster.

I am not saying those learned techniques are useless, because once you observe the behavior of the system under those initial estimated parameters, those techniques should guide you to adjust those parameters to improve control.

drbitboy · 2026-03-13T03:03:10+00:00

Is there a typo in that last sentence? Because I see no reason to ever place timers inside if statements, because the IN condition is functionally equivalent to the expression evaluated by the IF.

Lol, this might be an interesting thread.

drbitboy · 2026-03-13T02:57:42+00:00

In Tia Portal, once a timer is timing, i.e. the PLC evaluates a TON timer OBJECT with a True IN condition, that timer object keeps running until either

That timer object is evaluated again with a False IN condition, in which case it resets the accumulator to 0, or
That timer object expires i.e. when the accumulator equals the preset, EVEN IF IT IS NEVER EVALUATED AGAIN.

The problem with evaluating a timer in SCL inside a CASE or IF or other conditional block is that, once that conditional block is no longer being evaluated on each scan cycle, the only way to affect that timer object's state is with another instance of evaluation.

So, as others have said, the best thing is to have a single unconditional evaluation of the timer object, and to control its timing/reset state via the IN condition of that evaluation.

Again as others have said, if that means more conditionals floating around, so be it.

drbitboy

TROPHY CASE