Configuring P2-550 Arrays for Incoming ASCII Strings

For the corrected P2-550 setup, the array retained each ASCII string after CopyData was triggered once per AsciiIn completion; a continuously true RUN contact had kept CopyData enabled between updates. The data path was a Do-more PLC receiving the CSV over the internet, then sending it over RS-232 to the Productivity P2-550, which stored the received strings for later barcode lookup.

Confirm the P2-550 serial receive path

Check the model label and the communication path before changing ladder logic. The equipment was first identified as a P2-350, then corrected to P2-550. The Do-more H2DM1E received the internet file; the P2-550 received the data over RS-232. The P2-550 was not receiving the file directly over Ethernet.

Monitor the P2-550 receive string, identified as LabelID, while the Do-more transmits. If LabelID updates with the expected record, the serial handoff is working and the next check is the array write. If it does not update, troubleshoot the serial transfer and receive configuration before changing the array instruction; an empty or stale source string cannot produce the intended stored record.

The reported application needed records in the P2-550 because the Do-more memory was already close to capacity with the incoming file and still had other application duties. Parsing in the Do-more was considered, but the file size made that a poor fit for this setup.

Replace Fill Array with a per-record string copy

FLA was tried as an indexed Fill Array operation, but it did not place the incoming ASCII text into the intended slots. For this design, the working operation copied the received string from LabelID to an indexed element of the string array, LabelArry(LabArrCnt), using CopyData configured as Copy Binary.

Keep the source and destination roles clear: LabelID holds the latest received string, while LabelArry(LabArrCnt) names the array element intended to retain that record. A transfer error when entering an indexed destination is a reason to inspect the instruction’s destination field and the array tag definition. The working configuration used the indexed array element as the destination and the array’s declared type was string.

If the requirement changes from storing each complete received string to parsing individual characters, ASCII IN (AIN) or Custom Protocol In (CPI) with Copy Character (CPC) are alternate approaches to evaluate. They are separate receive and parsing paths; they are not needed to correct a CopyData instruction that is executing continuously.

Trace the receive-complete event and array index

Monitor LabelID, the AsciiIn Complete Tag, LabArrCnt, and the selected array element during a short transfer. Read them in that order: source string, completion event, destination index, stored value. This separates a communication problem from a write-timing or indexing problem.

Use the observed values to choose the next branch. If the completion tag never changes, return to the receive sequence. If it changes but the copy enable remains on, correct the trigger. If the enable pulses once but the wrong slot changes, resolve the counter/index timing before testing a larger file.

Trigger CopyData once after each AsciiIn completion

The immediate restore was to replace the always-on RUN contact with an NOE, described in the ladder as a normally open edge-triggered one-shot, so CopyData ran after each AsciiIn completion. A continuously enabled instruction is evaluated over repeated PLC scans; the one-shot makes the array write event-based, matching the arrival of a new string.

1. Keep AsciiIn writing the received string to LabelID.
2. Use the AsciiIn Complete Tag as the event that advances LabArrCnt and triggers the CopyData path.
3. Place the NOE on the CopyData enable path so the copy occurs once for each completion, rather than remaining enabled by the RUN bit.
4. Set CopyData source to LabelID, destination to LabelArry(LabArrCnt), and type to Copy Binary, matching the working configuration.
5. Confirm that LabArrCnt identifies the intended slot when the copy executes. If the counter increments in the same event logic, inspect rung execution order and adjust the sequence so the copy and index stay aligned.

Do not use the RUN bit as a permanent copy enable when the source string changes only on a receive completion. The completion event should control the write. Keep the counter update tied to completed records so incomplete or idle scans do not consume array positions.

Read the grey DataView cell as a monitor field

A grey Value field in DataView does not by itself mean the array tag has the wrong datatype. In the reported setup, the tag database identified the array as string, the field remained grey, and the array retained the copied text after the one-shot change. Treat the field as a monitored value rather than as an editable cell.

Watch a known record enter LabelID, then watch the intended LabelArry slot update and remain unchanged after the input sequence ends. If the string appears only while reception is active and disappears afterward, verify that CopyData actually executes and that the destination element is the array slot being monitored. Do not try to solve a scan-timing problem by changing a string array’s type solely because its DataView value is grey.

Test the file size and retained records before production

The CSV was described as approximately five columns, about 25 characters per field, and roughly 2,100 rows. That volume nearly filled the Do-more memory in the reported application; the file could potentially grow to 2,500 rows. These are application dimensions, not a guaranteed memory calculation. The actual file size and each controller’s available memory decide whether the receive and storage design fits.

For a temporary restore, use the edge-triggered CopyData path and confirm that records remain in the P2-550 array. For the permanent design, validate the largest expected file, array capacity, counter range, and the memory left for other Do-more and P2-550 functions. No maximum array length or spare memory value was provided, so read those values from the configured tags and controller project rather than sizing from row count alone.

Run a controlled transfer before reconnecting the full stream:

1. Send a small, known set of records and record their expected order.
2. Monitor the receive string, complete tag, counter, and destination slot through every record.
3. Wait until the serial sequence ends, then confirm the strings remain in their array slots.
4. Scan a barcode that should select a known record and verify that the lookup returns the intended stored data.
5. Repeat with a file at the largest expected size and confirm that the last record is retained without counter wrap, slot overwrite, or Do-more memory exhaustion.

Once the small and maximum-size checks pass, validate the remaining application work that depends on the stored data, including distribution to work centers, display on the C-More screens, and arrival timing. If serial reception fails, the instruction rejects the indexed destination, or records still overwrite after the completion-triggered write and index timing are checked, stop changing the ladder and contact AutomationDirect official support with the controller model, project version, monitored tags, and a concise reproduction sequence.

FAQ