Serial ASCII Resources

[AMarks95]

Does anybody have links to serial ascii resources? (specifically, for AB Logix 5000) Never used it before and it's in a project I'm jumping into in the middle of. Serial ascii seems foreign to me and I'm not sure where to start.

 

[Ken Roach]

The Instruction Set Reference is really the best place to start, both for the instructions that manage a serial port, and the ones that manipulate strings. And print yourself a convenient ASCII chart so you can quickly translate hex/decimal/ASCII characters.

What sort of interface are you using: the Ch.0 Serial port on an older controller, or a module like the 5069-SERIAL or the 1734-232ASC ?

The bad news is that most PLCs are lousy at processing strings, and Rockwell is lousier than most.

 

[Steve Bailey]

Sometimes you will find that your HMI has better tools for handling strings than the PLC.

 

[Dayvieboy]

Done ASCII many many times & have more to do, it is never fun

Does the device have any other language protocol options?

HMI & SCADA are easier to program ASCII but we are not allowed to use them
because it becomes a gateway component in the process that could go down.

On Allen Bradley I found the hard way that Point I/O ascii does not support variable length time delimited carriage returns. It worked for 25 of the 30 ASCII devices, We went to Anybus for the others.

I always use a sniffer so I know I am concatenating my strings correctly before I even attempt connect to a PLC also to make sure the device replies as expected.

I recommend spending about $ 100 in serial communications tools .

Even if you only use it one time I
this serial tool called Docklight
https://docklight.de/
at $ 59 it is worth every penny

https://docklight.de/information/#docklight-tap-pro

This utility converts ASCII, Hex, Decimal & Binary.
And lets you save the sequences that work so you can use them to program the PLC.
It lets you verify baud rate, Parity etc.
Also it can run loops to verify consistency.

A sniffer cable is also great to have so you can see if the PLC is sending the correct command & if the device is replying.

$ 45 for a sniffer cable
https://www.commfront.com/products/full-duplex-rs232-monitor-control-cable?variant=9209126659

It requires either 2 serial ports on your computer or 2 USB to 232 adaptors

Everybody @ work uses this to help set up ASCII & I have not seen a better utility.

.

 

[JeffKiper]

I second Docklight. Ken Roach actually introduced me to it years and years ago.

Steve Bailey just dropped a huge bit of advice for you. An HMI may be better for you ASCII handling than a AB PLC. i use Real Time Automation if its just a simple passing data from device to device. If I need to do anything heavier I use Red Lion controls hardware.

 

[parky]

Serial ascii is not your problem it's the protocol you need to get your head around, many serial systems are simple for example a weigher may send just the value of the weight in ascii form with a terminating character like CR or LF.
The protocols vary considerably as do handshaking, many do not use hardware handshaking and then there is things like checksums.
For example: a system may make a request for weight from a weigher
this may consist of something like "STX|W|ETX|CRC
i.e. "0257037F" the checksum is used to verify the data sent is valid & not corrupted, the checksum is the addition of the HEX codes excluding the STX this is a value in Hex but only the right hand codes used, i.e. 0-FF so 17F becomes 7F, this then instead of sending actual Hex values is converted into ascii characters before sending (please ignore actual values cannot be A$%D to work them out), so the controller sends the request, the weigher replies with the weight plus the checksum, the controller then calculates the checksum & compares it if ok sends back an ACK.
So, what ever you are communicating with it will depend on the protocol.
Many systems will either just continuously send out data, only send on request, may require acknowledgement, some are simple with no checksum others send checksums based on known algorithms i.e. CRC etc.
Only done serial coms on SLC basic card but RW & others will have plenty of information & configuration of code samples, your job will be to interpret the protocol & send (if required) the correct commands & decode the replies into useful values or commands.
Take a look at this link

https://literature.rockwellautomation.com/idc/groups/literature/documents/pm/1756-pm013_-en-p.pdf