Send ASCII characters Via 1734-232ASC

The command copy specifies element 5 as the starting location (i.e., Data[4]), when it should probably be Data[0].

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:

Hi again guys,

i ran the two below reading from the comports, if it shines any bit of light on the data being sent,

if you can see where i am going wrong i would be very grateful,

Thanks again,

Your logic is still sending out nothing but three nulls and a 0x04 character.

Make the changes I show in the screenshot above and that will get your first command string sent out, followed by a Carriage Return (0x0D) character.

Hi Ken, apologies for the first one had reply done before i saw your response, i have done the code as you provided and have the following responses for the first array it is just dots and for array 1 it shows \1A

I think your destination is correct now (the Output Data[0] element) but your source is still the base String tag, not the .Data[x] array.

Check the syntax very carefully (screenshot attached, with annotation showing your original incorrect address syntax in the inset box)

Hi Ken,

yes i have used your code as is to get the responses, shown in the updated ladder it works actually getting some ASCII characters.

apologies on all the questions but where do i change to .Data[x] array is it in one of the other attached photos,

thanks so much for your help on this apologies for my lack of skills in serial communication (Every day is a school day)

Noob_MW said:

Hi Ken,

yes i have used your code as is to get the responses, shown in the updated ladder it works actually getting some ASCII characters.

apologies on all the questions but where do i change to .Data[x] array is it in one of the other attached photos,

thanks so much for your help on this apologies for my lack of skills in serial communication (Every day is a school day)

Click to expand...

From a lurker: in Rung 3, shouldn't the LES be LEQ? otherwise the Tx record number will get stuck once it reaches 254, or am I missing something?


Also, shuold the GRT test be in the upper branch, else Tx record number will jump from 254 to 255 on the LEQ test, then from 255 to 1 on the GRT test ("left to right, top to bottom), all in one scan? Not that it matters, necessarily.

Good points on the increment test, and shame on me for not testing it.

You're correct the top instruction should be LEQ, and the bottom one GRT. That gives values between 1 and 255 inclusively, but never 256 at the output (because a SINT can't hold 256).

I roll over to 1 because I'm not 100% sure that the 232ASC doesn't consider 0 to be special in the Tx Record. I would have to check.

I think you could simplify this and just keep adding 1 to the TxRecordNumber, and it would appear to roll over to -1 and then count down but still be interpreted as a change to the TxRecord that triggers the transmission, but I like to keep things a little more readable.

In the COP instruction's first argument, the SOURCE value, type "Command_Array[0].Data[0]" instead of just "Command_Array[0]".

While you can click [+] icons and expand the Database view when using the Tag Picker, I prefer to type it in by hand.


Almost there !

Hi Ken,

Yep that sent the characters correctly this time,

see the attached pic, i tried to connect it to the pump there no movement does it require the carriage return or something ?

once again thanks for the help we are nearly there,

Noob_MW said:

Hi Ken, apologies for the first one had reply done before i saw your response, i have done the code as you provided and have the following responses for the first array it is just dots and for array 1 it shows \1A

Click to expand...

In the attachment data 4, is that from the supplied software or from your PLC? You know the supplied software works correctly, so you want to match what it sends. Pay no attention to the right side where it shows ".../1A" What is important is the hex values on the left. You're sending x00 x00 x00 before you send x2f x31 x41. It's showing "..." because those three hex values are non-printable characters and inserts a . to represent the data.

I checked the user manual (and will paste the important part as a screenshot).

Commands from the PLC to the pump should end with a Carriage Return byte.

Replies from the pump will end with an ETX, Carriage Return, and Line Feed.

In the traffic above, I don't see a Carriage Return byte (hex 0x0D) after the "/1AR".

Check your Termination settings in the 232ASC configuration and be sure that you've set the termination for "$R" from the selection pull-down, and enabled the Termination character for transmissions.

Hi Ken,

have attached the configuration from the module settings and also from the controller tags, would it be a case to just add it to the string or would i be totally incorrect in doing that,

thanks again

Ken Roach said:

You're correct the top instruction should be LEQ, and the bottom one GRT. That gives values between 1 and 255 inclusively, but never 256 at the output (because a SINT can't hold 256).

Click to expand...

I think it's the other way around: top GRT; bottom LEQ.


Also, I just realized that top GRT-driven MOV should move 0 (not 1) to TxRecordNumber i.e. when rung starts with TxRecordNumber as 255, because bottom LEQ-driven MOV will then increment TxRecordNumber from 0 to 1.