At the plant's baseline rate a counter poll of about 50 characters takes 14 ms of wire time, so the link idles most of each 100 ms poll cycle and a move to 115,200 baud buys a few milliseconds, not a smoother animation. Keep the baseline rate, bound the animation with the poll interval and the render, and raise the rate only when both ends document it and the link is busy.
A pushbutton animation that cycles a multistate bitmap from a counter feels slow, and the tempting fix is a faster serial link. The link here runs at the plant's baseline rate over RS-232 between the panel and the CJ1. The question is whether 115,200 baud is available and whether it would help. Both halves have an answer. The rate is a compatibility question that the documentation for each end settles in minutes. The smoothness question is arithmetic: at the baseline rate the wire finishes a counter poll in about 14 ms and then waits out the rest of the poll cycle. The stages that decide how the animation looks are the poll interval, the counter logic and the panel's drawing time. Below are the rate rule, the symptoms that point to each bottleneck, and the change procedure with a fallback.
Can I raise an RS-232 HMI link to 115,200 baud?
Only if both ends list that rate: set 115,200 baud on the panel's Host Link driver and on the CJ1 serial port at the same time, and keep the baseline rate whenever either side's documentation stops below it.
Both ends of an RS-232 link carry a printed list of rates, and the link runs at a speed both accept with the same character format. Driver setup sheets for CJ1 Host Link pair the baud with that format; one documented setup shows 19,200 baud, format 7,2,E, mode Host Link and unit number 0. Whatever your pair uses, the baud and the format must match at both ends. A rate one side offers and the other does not list is not a setting, it is a dead link.
The controller side is decided per port. The CJ1W-SCU serial communications unit datasheet documents communications at 230,400 bps as requiring the CJ1W-SCU@2, so the rates you can use depend on which port the cable is on and on that unit's version. Rates for the CPU's built-in ports are printed in the CPU unit manual. Read your two lists and the answer is settled before any cable is touched.
Why doesn't a faster baud rate make the animation smoother?
Because the animation speed is bounded by three slower stages: how often the panel polls the counter, how often the controller logic updates it, and how long the panel takes to draw the next bitmap, none of which changes with baud rate.
The counter value passes through four stages before it becomes a new frame, and each stage sets its own ceiling:
| Stage | What sets the bound | Example value |
|---|---|---|
| Counter update | the increment logic, a scan pulse or a timer preset | a 200 ms preset gives at most 5 states per second |
| Serial wire | baud rate and characters per exchange | 14.3 ms for a 50-character poll at the baseline rate |
| Panel poll | the tag's update interval in the driver | a 100 ms interval gives at most 10 frames per second |
| Panel render | bitmap count, size and transparency | drawing cost rises with each transparent pixel |
Baud moves only the wire row, and on a healthy point-to-point link that row is already the shortest. The animation bitmap object's help topic documents transparency as a significant CPU cost that noticeably affects screen update rates, which is where the render row gets fixed. The same poll ceiling that keeps an HMI trend graph from updating every half second keeps a bitmap from beating its own poll interval. When the counter row is the slow one, the repair is in the increment logic; PLC up-down counter scan timing and direction logic shows how scan order shapes what a counter does.
Worked example: how long does one counter poll take at the baseline rate?
One 50-character poll takes about 14 ms of wire time at the baseline rate and 4.8 ms at 115,200, so at ten polls per second the link idles about 86% of the time and the saved 9.5 ms cannot double the animation rate.
Take a pushbutton-held animation that cycles six bitmap states in 600 ms, 100 ms per state, with the panel polling the counter every 100 ms.
Character size follows the format: 7,2,E means 1 start bit + 7 data bits + 1 parity bit + 2 stop bits = 11 bits per character. Assume a 20-character read request and a 30-character response, an illustrative 50 characters or 550 bits per exchange; count your own frames from the protocol documentation.
- Wire time per poll: 550 ÷ 38,400 baud = 14.3 ms. At 115,200 baud: 550 ÷ 115,200 = 4.8 ms.
- Ten polls per second: 143 ms of wire time, so the link is busy 14% of the cycle and idle the other 86%. At 115,200 the busy share drops to 48 ms, under 5%.
- Link capacity: 38,400 baud ÷ 11 bits = about 3,490 characters per second. Ten polls at 50 characters use 500 of them, the same 14%.
- The animation ceiling sits at 10 changes per second, because nothing can draw before a poll returns. Twenty changes per second needs a 50 ms poll, which this link carries at 1,000 characters per second, about 29% of capacity.
The arithmetic says keep the baseline rate: the wire is idle six cycles out of seven, and the 9.5 ms saved per poll cannot lift a 10-per-second ceiling. Baud becomes the row to fix when total traffic, this poll plus every other tag and device on the port, passes about 1,700 characters per second, half of capacity, and reads start to queue. Sharing one serial port between two panels is its own failure mode, covered in why two HMI panels fail on one PLC serial port.
Which symptom points to which bottleneck?
States that skip point at the poll interval, a link that drops points at wiring or format, values that arrive but draw slowly point at the render, and none of the three is repaired by baud.
- Skipped states. The display jumps from frame 2 to frame 4. The counter advanced two steps between reads. If your scan is 10 ms and the counter increments every scan, a 100 ms poll passes over nine increments for every one it reads. Cut the poll to 50 ms or slow the counter.
- Stutter with a correct value. The number on screen matches the controller and the frames still draw unevenly. That is the render row: trim transparent pixels or drop a frame from the set.
- Drops and error icons on a link that ran for months. Wiring, connector or cable length. RS-232C defines 15 m as the maximum cable length, so a run past it produces errors at any rate, and a higher rate multiplies them.
- Everything seconds behind the machine. The tag sits in a slow update group or its interval dwarfs the process. Shorten that tag's interval before touching speed.
- No change after the rate went up. The wire was never the constraint. Restore the baseline and treat the slowest row from the table.
A bitmap that freezes on one state while the counter keeps running is a separate fault with its own checklist, in multistate bitmap fan animation counter not cycling.
What should I check before changing the baud rate?
Record both ends first: the CJ1 port's baud and character format, the panel driver's matching settings, the unit number, and a baseline of the counter value against what the screen shows at the baseline rate before anything is touched.
- Record the controller side: which CJ1 port the cable uses, its baud, format, mode (Host Link) and unit number. Set Host Link serial settings on a CS1 or CJ1 PLC walks those fields.
- Record the panel side. The documented path runs through the configuration software's PLC Settings screen: open the Host Link Port tab, select the Custom option under Communication Settings and set the Baud field to match the controller, as the panel's help page for CJ1 Host Link setup shows.
- Compare the two rate lists. If either stops below 115,200, that is the ceiling, and the animation work moves to the poll and render rows.
- Take a baseline: force the counter at a known increment period, count displayed transitions over 10 s and note any communication errors, so any change has a number to beat.
- Check the physical layer while the covers are off: cable at or under 15 m, connectors seated, same format at both ends. Wiring faults get worse at speed, never better.
How do I change the rate without dropping the link?
Change both ends to the same baud in one maintenance window, keep the character format identical, and if the link fails to come back, restore the recorded settings on both devices before diagnosing anything else.
Do the swap with the line in a safe state, because the operator loses the machine screen for the minutes the link is down. Set the controller port and the panel driver to the same rate and format, restart communications the way your tools require, and read the counter from the panel before anyone relies on the screen. A link that will not come back almost always has a rate or format set on one end only: restore both recorded settings, confirm the port selection, then look further. Never troubleshoot animation timing over a link that is itself dropping.
Measure the change the way the baseline was taken: displayed transitions against counter increments over 10 s. Keep 115,200 baud only where both rate lists allowed it and that count improved.
Recommendation: Keep the link at its baseline rate and fix the animation at its binding stage. Set the panel's poll interval to half the counter's increment period, 50 ms for a 100 ms state, tie the increment to a scan pulse rather than a timer preset, and trim transparency from the bitmap set. Move to 115,200 baud only when both ends' documentation lists the rate and total link traffic passes about 1,700 characters per second, half of the 3,490 characters per second an 11-bit format allows at the baseline rate.
When does a CJ1 need different serial hardware?
Only for rates above what the present port documents: the CJ1W-SCU datasheet ties communications at 230,400 bps to the CJ1W-SCU@2, and the RS-232C standard's 15 m cable limit still applies to any serial port the link uses.
The port on this link was sized for a data panel's traffic, and the baseline rate carries it with the wire idle most of the time. Three reasons justify new hardware, each with its own number:
- A documented rate above your port's list. 230,400 bps is the rate the datasheet ties to the CJ1W-SCU@2. The unit version prints beside the lot number on the nameplate, so confirm it before ordering.
- A cable run past 15 m. RS-232C describes the electrical link only up to that length. RS-422 or RS-485 stretches the run, and RS-232 to RS-422 cable distance for an HMI panel link covers the conversion.
- More talkers than the port serves. An Ethernet path removes the baud ceiling and the 15 m limit, at the cost of an Ethernet unit or built-in port on the controller, a matching driver on the panel and setup at both ends. It pays for traffic volume, never for one counter polled ten times per second.
None of this makes a signage screen an operator panel. If the plant also wants a board that shows the count and shift status to the whole line, that is an offline signage job, and our panel-mount displays play such content with no subscription while the HMI link keeps its own job.
Questions
Why did the animation look better when the counter moved from the panel to the controller?
The panel's internal counter and a controller counter can update at different rates. A counter inside the panel advances only as fast as the object driving it, while a counter in the controller can be pulsed once per scan or driven from a faster input, so more distinct states are ready each time the panel polls. The poll interval, not the baud rate, made the difference.
Does a higher baud rate let me lengthen the RS-232 cable?
No. RS-232C defines the electrical link for cable runs up to 15 m, and that figure stands at any rate. Higher clock rates are more sensitive to cable capacitance, so pushing baud while stretching cable trades a working link at the baseline rate for errors. For a longer run, change the electrical standard to RS-422 or RS-485 rather than the speed.
How many bitmap states can a 100 ms poll support?
One per poll. A panel that reads the counter every 100 ms can change the bitmap at most 10 times per second, whatever the link speed does. Six states at 10 changes per second need 600 ms per full cycle. To cycle six states in 300 ms, halve the poll to 50 ms and confirm the counter increments at least 20 times per second.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.