Productivity PLCs Need Segmented Buffers for Long ASCII Bills

A reported 128-character string ceiling blocks a long variable-length cutting bill from fitting in one Productivity PLC string, regardless of the controller’s total memory. Keep each bill intact in a storage method that supports its full length, or segment it with explicit length and ordering metadata; then verify that the saw receives the complete bill and that an operator’s deletion removes the intended queued board.

Separate total memory from the string limit

Do not treat the reported 50 MB of memory as proof that one string can hold a 4K-character bill. Total controller memory and the maximum length of an individual string are separate constraints. The reported Productivity ceiling is 128 characters per string, so allocating more general memory does not by itself remove that per-string limit.

The reported comparison is that Do-more can handle 1K-length strings. That is a different stated limit, not proof that every bill fits; measure the longest actual cutting bill before choosing a controller or storage design. If a bill exceeds the target’s supported string length, determine how that controller can store and transmit it before changing the production logic.

Check: Record the maximum supported string length for the installed PLC and compare it with the longest measured bill before proceeding.

Map each board packet and its deletion point

The described line scans boards, stores each variable-length ASCII cutting bill in a multi-board buffer, and routes the bill to the saw that will cut that board. The flow includes scanned boards, presaged and staged areas, a tipple, and presaged and staged buffers at each saw. A routing or deletion mistake can therefore send a valid bill to the wrong destination even when its characters are stored correctly.

The stated design capacity is up to eight board packets per staging point. The saw buffers can hold board data, but the saw cannot delete an arbitrary bill from its packet; deletion is possible only when the board is about to feed into the saw. The PLC and C-more display were assigned the earlier deletion task. Preserve that distinction: the PLC queue decides which board to remove or advance, while the saw’s own feed-time behavior governs its local packet.

1. List every staging point and saw destination in the actual installation.
2. Identify where an operator can request deletion and the exact queue entry that request must remove.
3. Trace when the PLC transfers a bill to the next stage and when the saw accepts or consumes it.
4. Define what the display shows if a board is deleted, delayed, or already transferred to a saw.

Check: Trace one test board from scan to saw and confirm that each transition has one unambiguous owner and queue position.

Measure bill lengths before choosing a buffer

Measure real cutting bills, including the longest expected production bill, rather than estimating capacity from average boards or controller memory. The bill is variable-length ASCII, so each queue slot must preserve both its payload and its actual length. If the system has multiple staging points, calculate capacity from the number of points and the configured maximum of eight packets per point; do not assume the number of points from the stage names alone.

For a memory-based design, calculate required storage from the sum of the queued bill lengths plus storage for lengths, queue state, routing data, and other implementation overhead. Measure or read the actual memory footprint for the selected PLC representation; the character count alone does not give the full allocation. Include worst-case queue occupancy, not merely one bill.

Set an explicit policy for a bill that exceeds the supported capacity or a queue that is full. Rejecting or alarming before overwriting another board’s data is safer than silently truncating a bill or shifting queue entries. The source does not identify the correct production response for a full queue, so select that response with the process owner.

Check: Test the longest measured bill at maximum intended queue occupancy and verify that the design has room for its payload and metadata.

Choose bulk storage or a segmented string buffer

For a Do-more controller with suitable functionality, the proposed approach was to buffer data in the RAM File System, especially when the PLC mainly needs to hold and resend bills. If the logic must parse a bill, the proposed approach was still to keep the bulk data in storage and read smaller portions into strings or other memory for parsing. This separates the full payload from the smaller working string.

The older Do-more controller in the described installation lacked the RAM File System. The suggested upgrade was version 2.0, described as free and supported on all existing CPUs. Before changing a running machine, check the exact CPU’s installed version, available storage features, and applicable upgrade instructions through the official product documentation or support channel. Do not assume that the storage facility is present just because the controller is Do-more.

If the selected PLC cannot hold a bill as one string and bulk storage is unavailable, a segmented buffer is an alternative architecture, not an automatic native feature. Store sequential fragments in separately addressable storage and track the total length, fragment order, and packet identity. At transmission, emit the fragments in order and confirm that the receiving machine accepts the complete bill. Do not invent string commands or memory addresses; use the target PLC’s documented instructions and storage limits.

Check: Confirm that the chosen storage path can retain, retrieve, and transmit one maximum-length bill without changing its content.

Build a queue that preserves board identity

Do not solve the capacity problem by concatenating several bills into one string. That increases the chance that a length limit or an incorrect delimiter will corrupt board boundaries. Give each queued packet a stable identity and maintain its destination, length, state, and position independently of the ASCII payload.

Use a defined lifecycle for each packet: scanned, waiting at its staging point, assigned to a saw, transferred, and consumed or deleted. A deletion request must target a specific packet identity, not simply erase the first or last buffer entry unless that entry is demonstrably the intended board. When an entry is removed, update the queue consistently so later boards do not inherit the deleted bill’s routing or identity.

Before transfer, check that the destination saw is ready to receive the packet and that the packet is not already in flight. After transfer, retain enough state to distinguish a pending packet from one accepted by the saw. The exact handshake signals depend on the installed controller and saw interface; use the actual I/O or communication status rather than assuming a send operation proves receipt.

Check: With test data, delete one selected board and verify that neighboring queue entries retain their own identities, destinations, lengths, and payloads.

Protect transfers from truncation and duplicate sends

Sending a packet in pieces requires explicit framing. Record the total bill length and the order and size of each fragment in the PLC’s documented data representation. The receiver or receiving sequence must know when the bill is complete; otherwise, a partial transfer may look like a valid shorter bill. Where the saw protocol has its own packet framing or acknowledgment, follow that documented interface rather than creating a competing convention.

Make transfer state changes only at defined points. A failed or interrupted transfer should leave the bill available for a controlled retry, while a confirmed transfer should not be resent merely because the PLC scan revisits the same queue entry. Use the communication status and receiving-side acceptance indication available in the installation. If the interface provides no positive indication, stop and determine how to distinguish acceptance from a send attempt before relying on automatic retries.

Preserve the original bill until the handoff is confirmed and the board’s deletion rule permits removal. This avoids losing a bill when the PLC has advanced its queue but the saw has not accepted the packet. Keep a diagnostic record or display of packet identity, destination, length, and transfer state so a shift operator can identify which board is blocked without guessing.

Check: Interrupt a controlled test transfer, recover it using the designed retry path, and confirm the saw receives one complete bill exactly once.

Run an end-to-end queue and recovery test

Test the whole path before returning the revised buffer logic to production. Include short and longest-length bills, more than one board in a staging point, each saw destination, and an operator deletion before feed. Verify payload integrity as well as queue behavior; a successful transfer indication alone does not prove that every character arrived in the correct order.

1. Load test bills with distinct identifiers and known lengths into the scan buffer.
2. Advance boards through each staging point and compare the PLC’s identity, destination, and length with the expected values.
3. Delete a selected bill before the saw’s feed point; confirm only that board is removed.
4. Send a bill to each intended saw and compare the received bill with the stored source payload.
5. Test a full queue and an interrupted transfer; confirm the configured alarm or stop behavior and verify that no existing bill is overwritten or duplicated.
6. Repeat the checks at the intended maximum queue occupancy before enabling production.

Check: Release the logic only after every tested board reaches its intended saw once, intact, and the deletion and recovery cases produce the defined result.

Frequently asked questions