Allen Bradley Strange ASCII Character

I'm trying to read in ASCII strings from an RS232 card reader to an AB 5/03. I get some strange characters in my string. As you can see in the attached .rss file, I get several \B characters inserted into my string (ST9:0) But as you can see, the string length is 32 as it should be which tells me that RSLogix (or the processor) doesn't consider the \Bs to be characters. Does anyone have an idea what these \Bs are? Rockwell Automation suspects that it may be noise but I don't think so. If I hook this reader up and read into Hyperterminal, I get ;6360221101258017=061119641129? as I expect every time.

My planned work around is to only read the first 11 characters as that is all I need and I can get the first 12 about 70% of the time. But of course I'd like to get about 99%

This looks interesting. Received strings are complete
but have randomly inserted \B characters...
You could try to search for \B and remove it and move the rest of string to fill it up.
But...
Can you try it on other CPU (just to check)?
What is the port setting of the terminal and scanner?
Are the data and stop bit settings same on all devices?
Are the cables you use same for PLC and PC?
Once you receive string to terminal, can you send it
to PLC (you need crossover such as 1746-CP3)? Does it look ok?
Do you have some dumb terminal? Hyperterminal is not always
to be trusted, it tends to "correct" or remove some control
characters.

The fact that the \Bs have not counted towards the string lenght is what has baffled me. I have thought about trying to search them out, but the AEX does not find them and even if it did, there are often (5% of the time maybe) \BBs in there as well. I tried on another CPU today with the same results and the port settings, baud, parity, etc are the same for the CH0 user mode as they are for the card reader. The cable is the factory cable attached to the card reader and as I can write to CH0 with it, I asume that the pinout of it is OK. I may have to get another card reader to try.

check out this thread:

http://www.plctalk.net/qanda/showthread.php?s=&threadid=3815&highlight=ascii

The \B may be only the first part in a callout of a hex code of the form \xx.

The \B may be only the first part in a callout of a hex code of the form \xx.

Click to expand...

I think that ndzied1 is probably right. If you look at the string youll see that the \B is always followed by a 1 or a 0. If you take those sequences as 1 byte and the ^M at the end of the string as one byte you get a lenth of 32.

I see that you moved your data over to N7. Look at N7 using an ASCII radix and you'll see exactly how much room these things take; 1 byte each.

Hope this helps,

Good Luck,

(8{)} ( .)

(Yosi)

Ok, I copied S9:0 (more corrupted than S9:5) to some
unused space (N7:100) so I can see it in hex.
Then I took copy of good string from original post
and pasted it into notepad so I could make similar
arrangement.
If you know that 30-39h are ASCII characters "0"-"9"
it's quite easy to follow. It seam that it's always
the upper nibble that's corrupted (B?h instead of 3?h).
For example highlighted word should have been 3032h (ASCII "02") instead of B032h.
Although this is very easy to correct in software,
I don't like patching things. Did you try it with
another CPU or verify port settings?

Is your card reader sending out extended ASCII codes?

The "3" in the upper nibble is 0011 in binary, and the "B" is 1011. In other words, the "B" is a "3" with the high bit set. You don't need the high bit to receive any of the normal ASCII codes.

Try setting your card reader or serial port to 7 data bits instead of 8. The 7 bit setting will filter out the high bit and your "B's" should become "3's".

I'm thinking now the \Bs may be the result of how the card reader transmits the data. It is a port powered reader and to keep the charge up on the circuit that powers it, it apparently uses a capacitor to keep the voltage level up and only transmits in 5ms bursts every 10ms. I tried an externally powered reader and it hits on all cylinders every time. Unfortunately the externally powered one is not my first choice. Any ideas on overcoming this 5/10ms issue?

panic mode said:

Ok, I copied S9:0 (more corrupted than S9:5) to
it's quite easy to follow. It seam that it's always
the upper nibble that's corrupted (B?h instead of 3?h).
For example highlighted word should have been 3032h (ASCII "02") instead of B032h.

Click to expand...

It's not just the upper nibble that's "corrupted", it's the most significant bit that is set in the first word. (Hex "3" is 0011 and Hex "B" is 1011)

Since standard ASCII characters are 7 bits, the first bit shouldn't matter. I would guess that your device uses that bit to signal the controller that it is the first byte of the string.

You could easily fix it by masking each byte with 7F in order to reset the most significant bit to a zero.

Edit: I just realized that this was a way-old thread. Sorry for the bump.