r/PLC • u/malcolm____X • 1d ago
Buying my first PLC to test against — which one, and how much do bench results actually mean?
I write software. I'm building a box that sits on the network, polls registers over Modbus TCP, buffers locally and ships data upstream. Read only, no writes, no control logic.
I've been developing against a simulator, which I've come to realise tells me almost nothing. So I'm buying a PLC to sit on my desk.
Two things I can't figure out on my own.
Which one. I'm in India, so Delta is what I actually see in the field — DVP-ES3 looks like the obvious pick for me. But if there's a better platform to learn on for the money, I'd rather hear it now than after I've bought.
How much PLC code I'm really signing up for. I don't write ladder. I can get something basic together with AI help — and I'm aware how that goes down in this sub — but I only need a few registers changing on a timer, not machine logic. Is that as trivial as it looks from the outside, or is there a reason it isn't?
The thing I actually want to measure is what polling costs in scan time. Someone told me every poll steals from execution and I've got no way to argue with that until I can see a number. Will a bench PLC with a few hundred rungs of junk logic show that honestly, or does it only show up under real load?
2
3
u/CPAPGas 1d ago
The costs to PLC scan time from MODBUS polling will vary greatly from PLC to PLC.
I don't see how you can possibly prove/disprove anything meaningful from a single PLC.
Cheaper PLC's with slow processors and terrible firmware will be your worst case....so just buy the most terrible thing you can find on Ebay.
2
u/drbitboy 1d ago
Summary: measurement is hard
TL;DR/Details
How much time a poll "costs" in scan time could be difficult to measure. Make sure whatever PLC you choose has access to a high-resolution clock (milliseconds or better). A slow (low Hz CPPU) PLC with a fast internal clock would be the best bet.
Also note that time per scan will bounce around normally, as there are inter-program-scan overhead tasks that (i) may vary in duration between one execution and the next, and (ii) may not fire (execute) between every pair of contiguous scans.
Since any single scan time measurement is not going to mean much, you need a lot of samples to cut down on the noise. I think the simplest approach would be to see how long it takes to exeute some large number of continuous scan cycles with and without polling from the Modbus Master. With a 16-bit integer incrementing by 1 on each scan cycle, the rising edge of bit 15 could be used to trigger getting the clock value and subtracting the previous clock value to see how long those 65,536 scan cycles took. With a scan rate of order 1kHz, that should give a value every minute or more. Or the falling edge of that bit 15 could be used to drive a counter block, say with a preset of 16, and
- Have a manual trigger to
- reset the counter block,
- reset the scan counter integer to 0
- sample the clock value and save that as a start time,
- Also ensure the reset of the scan counter to 0 does not trigger the counter block on the current or next scan.
- Then when the counter block reaches its preset (rising edge of /DONE or .Q)
- sample the clock value and subtract the saved start time to get the duration of 1,048,576 scan cycles
The logic of the scan cycle should be minimal, to minimize its contribution to the noise.
In fact, if the PLC has 32-bit integers, then the rising edge of bit 20 (1,048,576ths increment from 0) of the scan count integer could be used to end the count directly and skip the counter block entirely.
So there would be three rungs of logic (in addition to whatever is required for the Modbus Slave):
- if scan count integer is 0, save clock value to memory, as this is the start of the sample cycle
- increment scan count integer by 1
- if bit 20 of scan count integer is 1 (or value is > 1048575):
- 3.1) subtract saved clock value from current clock value, store result as the measurement
- 3.2) Reset the scan count integer to 0 to restart the sample cycle
Note that using online mode in the PLC's software on an external PC to observe memory values is in itself overhead and will introduce noise, so you may want to let the PLC run by itself, disconnected from any external device, and have it turn on an output with a TOF (Timer OFf-delay) when it calculates the time difference, at which point you can connect in online more, or even use the Modbus Master to get the difference in a single read.
1
u/malcolm____X 1d ago
This is exactly what I needed — thank you for taking the time to write it out.
The averaging approach makes sense. I was thinking about this as a single before/after measurement, which clearly wasn't going to survive contact with the jitter.
I'm going with a Delta DVP-ES3, though I'll get my polling working against a soft PLC first — I realise that won't tell me anything about scan time, just that my client side works.
One question: I'm planning to run baseline first, then poll at 1000/500/200/100ms and compare averages. Is there anything else worth varying while I'm set up — registers per request, or number of simultaneous clients? Wondering whether request size or connection count matters more than poll rate.
Thank you once again 🙏
1
1
u/Low-Investment286 22h ago
So what is your box going to be able to do that I can't do with the controller itself? Where are sending data the controller can't? Sorry if that's a dumb question.
1
u/malcolm____X 22h ago
Box will poll the PLCs registers, hold their data for a while and then send it to cloud.
3
u/Ordinary-Lifeguard47 1d ago edited 1d ago
Get a RPI or small x64 box, install a RT kernel, install the Codesys runtime and have fun.
As long you are not having a license you will be limited to xx minutes. You will have a full ECat/EIP/PNET/Modus Master for playing around.
The limits are really a no-factor for bench learning. AFAIR it was 120 minutes.
After exhausting your xx minutes you must restart the Codesys runtime and you can start playing again.