A trend chart that records 50 to 60 samples a minute against 150 triggers is being throttled on the acquisition path: the required interval, PLC scan rate, serial wire time or the number of separate memory reads behind each sample. Count chart points and trigger pulses over the same minute, then work through the checks in order before buying a communications module.
A trend chart that logs 50 to 60 points a minute against 150 trigger pulses a minute has a throughput problem on the acquisition path, not a setting inside the chart. Four limits produce this symptom: the interval you ask the chart to keep, the PLC scan's ability to service each trigger, the time the serial link needs to move the data, and the number of separate memory reads behind every sample. Each limit leaves a different fingerprint. A one-minute count of chart points against trigger counts, plus one reading of scan time, tells you which limit you have. This article walks the checks in order, with the arithmetic, so you can tell a scan-time limit from a wire-time limit before you spend money on a communications module.
What the shortfall points to
Compare the two counts first, because each pattern means something different:
- Chart count matches trigger count at the tested speed. The path keeps up at that speed. Repeat the count at the highest speed the process needs before calling the problem solved.
- Chart count sits well below trigger count and stays near one value. In this case it held at 50 to 60 points a minute while the machine fired 150 pulses, at any speed. Something on the path meters samples at a fixed cadence, so per-sample service time exceeds the interval the process needs.
- The count improves after one change but still misses the target. That factor is one contributor. Retest at top speed and look for the next constraint.
- The average rate looks right but individual triggers are missing. Check edge detection first. A sensor input that stays on or chatters gives the wrong pulse count before any throughput limit appears.
Set the interval the process needs
The chart's slowest time-based interval is 1 s, and that answers a different question from one point per piece. Work the interval back from the process. At this machine's minimum speed the line passes 2.5 pieces per second, which is 150 triggers a minute and a budget of 60,000 ÷ 150 = 400 ms per sample. The higher production targets shrink the budget:
| Operating point | Triggers per minute | Budget per sample |
|---|---|---|
| 50 ft/min, minimum speed | 150 | 400 ms |
| Mid-range target | 280 | 214 ms |
| Top target | 380 | 160 ms |
If every piece needs its own vacuum reading, a 1 s interval cannot deliver it at any speed in the table, so keep the trigger input and fix the path. If the decision you make from the chart is about drift across a shift, take the 1 s trend; it needs no sensor and no throughput budget.
Count chart points against triggers for one minute
Run one speed, start a timer, and write down two numbers for the same 60 seconds: the points the chart added and the pulses the trigger input received. Read the pulse count from the trigger register in the PLC or from a handheld counter on the sensor line. On the line in this article the test returned 50 to 60 points a minute across several hours against a steady 150 pulses, so a single lucky minute would have hidden the problem.
Keep speed and window identical between runs. One minute at 150 triggers compared with five minutes at 380 says nothing about the bottleneck.
Read the scan time before blaming the wire
Go online with the PLC and watch scan time in your programming software's online monitor; most packages print the current and maximum value for every pass. Watch both numbers for a minute of normal production. Scan time grows with the program and with the work each pass does, and it decides how much service every connected device gets.
Then apply this rule: if the reading stays under about a quarter of the sample interval, the PLC has room to service each trigger, so scan time is out of the picture. Under the 400 ms interval that means under 100 ms; under 160 ms, under 40 ms. Once the reading approaches the interval itself, the PLC is the limit, and a faster serial module or an Ethernet card will not change it.
Run the test with the control program and its interlocks live. Pausing parts of the program to free scan time for a trend test changes machine behavior and belongs only in a planned trial that keeps every required interlock active.
What a faster serial link can change
In this case the PLC's programming port is fixed at 9600 baud and the second serial port already carries Modbus traffic for other devices, so the realistic upgrades are a serial communications module with higher rate settings or an Ethernet module. A higher rate cuts only the time data spends on the wire. It changes nothing about scan service or the number of reads per sample, the same reason a faster baud rate will not fix slow HMI animation.
Use these planning numbers for wire time. At 9600 baud with 8 data bits plus start and stop, one character takes 9600 ÷ 10 ≈ 1.04 ms. Modbus RTU requires a silent gap of 3.5 characters between frames, about 4 ms at 9600 baud, shrinking to just under 2 ms once rates climb. One read of a 10-register block moves 8 characters out and 25 back, so 33 characters, about 34 ms on the wire plus the 4 ms gap. Multiply your own frame sizes the same way, whatever protocol the panel speaks.
Before buying a module, confirm that the PLC port, the module and the panel's driver all accept one common rate. A module that lists much higher rates than the panel's driver supports changes nothing. An Ethernet module removes serial wire time from the budget entirely, but scan service and transaction count remain, so rerun the same one-minute count after the change and check how many panels one PLC Ethernet card supports before you add this one.
One boundary worth keeping straight: a standalone Android signage screen plays its own offline content and takes no video in, so it can carry notices or recorded results beside the machine, but it will not display this trend; that separate job belongs to the shop-floor screens and andon boards range.
Example: 150 triggers a minute, 56 recorded
Demand: the line runs 50 ft/min and passes 2.5 pieces per second, so 2.5 × 60 = 150 triggers a minute and the budget is 60,000 ÷ 150 = 400 ms per sample.
Measured: 56 points arrived in one minute, so each point took 60,000 ÷ 56 = 1071 ms, about 2.7 times slower than the budget.
Next target: at 380 triggers a minute the budget is 60,000 ÷ 380 = 158 ms, call it 160 ms. Going from 1071 ms to 158 ms takes a 6.8-fold improvement, so the fix has to be a big one.
Wire budget: one 10-register read takes about 34 ms of character time plus a 4 ms gap, 38 ms. Three separate reads per sample take about 103 ms plus 12 ms of gaps, 115 ms. Against the 400 ms budget that leaves 285 ms for scan service and panel overhead, which is workable. Against 160 ms it leaves 45 ms, which is nearly nothing.
Result: wire time reaches 1071 ms per sample only if every sample moves about 1000 characters (1071 ÷ 1.04), and this trend reads 33 characters per block, so the wire is not the whole limit at the measured rate. Read the scan time and count the transactions. At 150 pieces a minute the existing port fits the budget once the transaction count is tidy; at 380 pieces a minute the same link has almost no headroom, so plan on fewer reads per sample or a faster link from the start.
The fix, in order
- Set the interval target from the process: 400 ms per piece at 150 triggers a minute, 160 ms at 380, or accept a 1 s time-based trend and stop there.
- Count chart points and trigger pulses over the same 60 seconds at every speed you need, and repeat across a shift.
- Read scan time online. Under about a quarter of the interval, the PLC has room; near the interval, the PLC is the limit.
- Group the trend's values into contiguous blocks so one sample takes one read, three at most, and rerun the same count test.
- Change the serial rate or add a module last, with a rate every device on the link accepts, and rerun the count after every change.
Recommendation: Run the one-minute count test and the scan-time reading before buying any communications module. If scan time stays under about a quarter of the sample interval and the trend already reads one contiguous block, wire time is the limit and a higher-rate module or Ethernet card is the right buy. If scan time approaches the interval or the trend scatters across many small blocks, spend nothing on hardware until the PLC side and the transaction layout are fixed, because a faster link cannot reach those parts. For this case, expect the 400 ms target at 150 pieces a minute to be reachable on the existing port, and plan the faster link before promising one point per piece at 380.
Questions
Can I raise the trend rate by raising the baud rate alone?
Only when time on the wire dominates. At 9600 baud one character takes about 1 ms and each frame adds roughly a 4 ms silent gap, so doubling the rate halves wire time while scan service and transaction count stay as they are. On many controllers the programming port's rate is fixed in firmware, which is why a separate communications module exists. Count points against triggers before and after any rate change; a count that barely moves means the wire was never the limit.
How many samples a minute can a 9600 baud link carry?
The wire itself moves about 960 characters per second at 9600 baud with 8 data bits plus start and stop. A 33-character register read plus its silent gap takes about 38 ms, so the raw link could carry roughly 1,500 reads a minute. Real rates land far lower because the panel shares the link with screens and events, the PLC services requests between scan passes, and one sample often needs several reads. Use the measured count as the planning number.
Should I use trigger sampling or time-based sampling?
They answer different questions. A trigger input gives one point per machine cycle, which is what a trend needs when it must explain a single piece's vacuum behavior. A 1 s time-based interval gives a steady picture of drift across a shift and needs no sensor, no extra wiring and no throughput budget. If the decision you make from the chart is about the process over an hour, take the 1 s trend and keep the trigger for per-piece investigations.
Will an Ethernet communications module fix the shortfall?
It removes serial wire time from the budget, which matters most at the 160 ms level where a 9600 baud link has almost no headroom. Scan service and the number of reads per sample remain, so rerun the same one-minute count at the same speed after the change. Before ordering, confirm the panel's Ethernet driver and the module support a common configuration, and confirm the PLC's Ethernet card has room for one more connected panel.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.