Thank you, Mispeld, for pointing out what I failed to see; the String data needs to be copied starting at element 0 of the .Data part of the String, into the Output data array starting at element 0.
A String datatype starts with a DINT for the Length; it was that first element of CommandArray[0] that was landing in O.Data[4] through [7]. That's why there was that lonely value "4" in the Output data.
Attached is a screenshot of how I recommend writing the logic to present those Command_Array[x] Strings to the 232ASC.
I separated out the increment of the "Transmit Record Number" value onto its own rung not just to avoid duplication but also to emphasize that whenever you modify the elements of an Output data tag, there is the possibility that the RPI for the module will expire at any point in your logic; it can even do so in between elements of an array-tag COP instruction, which is why the Copy Synchronous (CPS) instruction exists.
In this case, if the RPI expires during or after the COP, or after the MOV in either Rungs 1 or 2, the Output data image goes out with the non-incremented Transmit Record Number, so no data is transmitted and no undesired operation occurs.
Because the change to the O.TransmitRecordNumber only occurs in the last MOV instruction on Rung 3, then there's no risk of the 232ASC getting an incomplete or undesired assembly of Output data.
The 232ASC/485ASC module is pretty cool under the hood; they're actually based on the design of a DeviceNet/Serial module from Western Reserve Controls in Akron, Ohio. The Prosoft ILX34 modules are based on the same hardware. It's a nice stable design which has served well for years (I started working with WRC in 2003 or so), and does what it's built to do without a lot of extra flexibility or sophistication.
Screenshot attached: