Micrologix 1400 read serial binary data

Here is one that hopefully will be easy for the awesome people here.
I have several ML1400's that I would like to get to read binary serial data.

Is it possible to configure the rs485 input on the ML1400 to read one byte at a time and put it in a register?
I only see ASCII as the closest useful option for configuring that port and I know it is going to look for a linefeed or some significant terminator to tell it when to stop reading. Not to mention the fact that it wont be able to convert the data to ASCII or screw it up while trying.

The data is RS-485 and consists of a repeating stream of 3 bytes.
The first 2 bits of each byte signify the type of data that the next
six bits hold.

first 2 bits of
"10" : means this is the "Most significant bits" of a 12 byte number
"01" : means this is the "Least significant bits" of the 12 byte number
"11" : means this is some sort of status data.

There is no terminator, simply a stream of bytes with a long rest period in between each one that happen to repeat every 3 bytes.

It took me a couple weeks to figure out the format, it would be a killer if the PLC's purchased cannot read the data.

I would appreciate any pointers.

breshead said:

and I know it is going to look for a linefeed or some significant terminator to tell it when to stop reading.

Click to expand...

Not necessarily. I'm not familiar with the 1400 but other A-B processors allow you to configure the port without a termination character. Of course, it then follows that it's up to your program to handle the incoming data. One of the ASCII instructions checks for buffer characters. You can continually check the buffer and when a character appears you can read the buffer into memory (an ST type IIRC) and pick it apart from there. You needn't wait for a terminator.

breshead said:

Not to mention the fact that it wont be able to convert the data to ASCII or screw it up while trying.

Click to expand...

What is ASCII? It's just a way of looking at bits in a byte. By your own definition the data is not ASCII. So what? If your device sends eight bits and the processor receives those eight bits and knows not to process them as an ASCII character but special data, you're OK.

Ahh, I was thinking it was going to be strict about the data it allowed in.
Thanks for enlightening me, I will work on that this morning and try to verify your thoughts.

I have now got serial data coming in to the buffer and my program is reading it but it seems to be parsing it incorrectly.

Channel 0 - Setup
I have gleaned from other posts in the forum that..
Pins 1 and 8 are the Data A and Data B RS-485 connection.
Pin 2 is required as a common on RS-485 connections.
Setup port as ASCII with "No Handshaking (485 Network)" on the control line.

Baud: 300
Parity: ODD
Data bits: 8
Stop bits: 1
I am sure of all the serial parameters on Channel 0 except the
"Termination 1" and "Termination 2"
Term1 = \d
Term2 = \ff
I could not delete them as *something* is required.


When I read a char from the buffer in to ST9:0 I am getting a unchanging \FF in the string. I should never get that for one plus it should be changing (rapidly).

I have to pull the data into the string because the ARD instruction requires it.
I tried to pull it directly into N7:0 but the project would not verify.

It is interesting that ST9:0 contains \ff (same as termination char)?


I have connected the pins as following
The "Data +" is now on pin 1
The "Data -" is now on pin 8
Ground is on pin 2

I was under the impression that 1 and 8 should be opposite of what they are but when they are reversed I get an increasing "error" count on the Channel status and no "character count"

In the current setup, Channel Status has an ever increasing "character count received" with no error count.

When I put a scope on 1(+) and 8(-) I see a serial signal that "rests" with a high voltage and pulls low for the start bit. As far as I could tell this is what RS485 is supposed to look like.

I have added a screen shot showing the ST9:0

Any ideas as to what is going on?
Can I provide any more data?

Curious. Could you try changing the 2nd termination character to something else and see if the value which ends up in the string follows suit?

I fixed the problem. I don't have experience troubleshooting Allen Bradley PLC's so I couldn't quite figure out what was going on but it seemed like the serial port was constantly being read even though when it "reads" it should empty the buffer and that should stop the "reading". Any way I don't believe it was.

I changed the "Go ahead and process Data" flag to activate when the ARD read "DONE" flag was set.

I also had to insert a check at the beginning to only read if we were NOT processing an existing data byte. This seemed superfluous to me but it would not work w/o it.

Thanks for your input.

Glad to hear you got it going. I don't have a lot of experience with the serial port instructions but I do remember having to tinker with them to get it just right!

I don't have experience troubleshooting Allen Bradley PLC's so I couldn't quite figure out what was going on but it seemed like the serial port was constantly being read even though when it "reads" it should empty the buffer and that should stop the "reading". Any way I don't believe it was.

Click to expand...

The PLC constantly reads data into the ASCII buffer (until it is full or the data stops being sent). The ASCII commands (when enabled in the program scan) then move data from the ASCII buffer into user memory areas (such as the ST string file).

Your ARD command should have the String Length set for the total number of characters that you want to pull out of the ASCII buffer for each read instruction. I noticed you had "Str Len" set for only 1 character. That seems to be a slow way of getting all of the data. Why not read all of the 3 bytes at one time into a String location, then use the AEX command to pull out the parts as needed?

That is an interesting thought. I did not think of it as the slow way though as I am reading the data as it shows up in the queue, that *seems* like the fastest / smoothest method.
Also there is no real termination to mark the beginning or end of the sequence, you just have to read it and see what you have got. I guess that is the real reason I didn't think of it that way.
Thanks for your thoughts, I will look into the AEX instruction. Always looking to make my code better.

That is an interesting thought. I did not think of it as the slow way though as I am reading the data as it shows up in the queue, that *seems* like the fastest / smoothest method.

Click to expand...

Remember that you don't and can't see the data when it shows up in the ASCII buffer. The only way you can see it is to use one of the commands to move it out of the buffer.

Also there is no real termination to mark the beginning or end of the sequence, you just have to read it and see what you have got. I guess that is the real reason I didn't think of it that way.

Click to expand...

That is why most serial data has some 1 or 2 line termination characters inserted at the end of each line of data. Without that, you have to know the length of each line (you said 3 bytes), or simply keep reading until the serial buffer is empty.

For data of unknown length and no termination characters, I have used trial-and-error by reading different String Length settings until I have something that looks right. The only probably is that many times the data length varies.

So if I changed this to read 3-byte data sets, what would be your syncing method to make sure that it did not grab the last byte of one set and the first two bytes of the next?

Is there such a thing as a "maskable termination"? Where the first two bits could be used as a trigger?

Thanks again for your thoughts.

breshead said:

Is there such a thing as a "maskable termination"? Where the first two bits could be used as a trigger?

Click to expand...

I don't know how you'd do that in the buffer. You could though, after you've pulled the character(s) into an integer decide, based on the upper two bits, to clear the buffer and go back to waiting for the first character.

Yep, that is the implementation I have currently.

So if I changed this to read 3-byte data sets, what would be your syncing method to make sure that it did not grab the last byte of one set and the first two bytes of the next?

Click to expand...

The ASCII Buffer read always reads FIFO (first data in is the first read out). So if your sending device always sends 3 bytes, then your first read for 3 bytes will always contain the same pattern. Then your 2nd read should also be correct. The only time you would get off-track would be some type of upset (data missed or garbled). You would need a method to re-synch to some known point in case of a problem.

You will have to know how many "characters" are in that 3 bytes, then set your String Length to read that number of characters for each read instruction. If the number of characters varies (typical), then this method will not work.