Ascii Issues

Lary · May 13, 2020

I have an Aczet CZ series weigh scale hooked up to a MicroLogix 1400 PLC through port 0 (9 pin serial). The software being used is RSlogix 500. When in run mode in the ascii read box the characters read keeps cycling. I have an image of the ascii read box attached. Is there a way to get that to stop cycling and show a weight value from the scale? Thank you for your help.

Lary

Dravik · May 13, 2020

What is your scale actually outputting via Serial, is it a continuous output or only when a button is pressed?
Do you have the termination characters setup?
What's your comm setup look like for the channel you are using? Does that match what the scale is configured for ala baud rate, etc.
How often are you triggering the ARD

parky · May 13, 2020

The way you explain it is that you expect the chars to be in the Chars read, this is just the number of chars read. You need to look at the ST registers where it is stored. These may well change depending how often it is read, I suspect that the scale is sending data reasonably fast and not requested by the PLC. Also it depends on how you set up the read for example is it always a fixed length string i.e. 6 chars, if so on a read of 6 chars, compare the read char variable with 6 or what ever, then move the ST regs into another set so only full reads are moved.

_Dock_ · May 13, 2020

Is the data you're getting valid? If so we need to see the contact side of that instruction. The scale is providing weight obviously but what for? A determination needs to be made first on how you need to read the weight, triggered or continuous.

Ken Roach · May 13, 2020

Welcome to the PLCTalk forum community !

The more information you can provide, the better folks can help you understand the scale connection and the associated logic.

There are two "ASCII Read" instructions in the MicroLogix command set; ASCII Read Characters (ARD) and ASCII Read Line (ARL).

The difference between them is that ARD will immediately read whatever is in the incoming data buffer. ARL waits until it sees the configured "termination characters", often Carriage Return and Line Feed.

If you can provide more information about the serial data you expect to see arriving from the scale, and on how the logic and MicroLogix are configured, folks can probably help.

Ideally, ZIP and attach the *.RSS file to your post, if your company rules will allow it.

Jim3846 · May 13, 2020

I would also look at the standard logic that Rockwell supplies with the typical coding for asc2 as a start for coding. Like everyone is saying more info on your channel 0 setup.

I thought the string length is set to zero (feature), where it will read what is in the buffer. Then it will show the length and the string should be displayed in the destination.

Lary · May 14, 2020

This is a project I was brought into that was built about 9 years ago. The original PLC was a AB 1500 series with the 2 serial ports on it. They decided to upgrade the PLC to a AB 1400 series which has 3 ports on it the 2 serial and the 1 ethernet port. According the manuals port 1 on the 1500 is the 9 pin serial port and port 1 on the 1400 series is the ethernet port. Is this going to be an issue when switching plc's? The other problem I have is that I have the pc hooked to the plc through ethernet and the weight scale hooked through the 9 pin serial port. Everything seems to be good connection wise, but I'm not sure if the continuous ascii signal coming from the scale should be cycling thru the numbers like it is. I have attached the RSS file to this reply. To let you know I was not the original writer of the program I just have to get it to work properly. Thank you again.

Lary

Dravik · May 14, 2020

Do you have the original .rss, the one the 1500 is working on? It would be good to compare the serial port settings.

Lary · May 14, 2020

As far as I know everything matches up with the exception of the port ID's. The original RSS from the 1500 is attached.

Dravik · May 14, 2020

So, your first post says you've got the scale hooked up to port 0.

The program says it is looking for data on port 2.

Which is it?

Ken Roach · May 14, 2020

Thanks for posting the program !

The change from Port 1 on the MicroLogix 1500 to Port 2 on the MicroLogix 1400 should be no problem; they are physically and functionally identical RS-232 ports.

It looks like there is data coming into the serial port, but that it doesn't make sense as an ASCII string, like "123.45".

Instead, the data values all seem to be above 0x7F (127 decimal, the highest value of normal 7-bit ASCII).

\80\98\86\E6\98\86\98\98\98\80\98

I recommend going back to the MicroLogix 1500 version of this and checking carefully the serial framing (parity, stop bits, number of data bits) and the data rate. This data looks like it might be using 8 data bits when it's intended to use 7 data bits.

Ken Roach · May 14, 2020

I sat on my post too long and overlooked the original program post. Thanks !

That program shows a sample of the expected string: "+ 23.72 g"

So we should be looking for four non-numeric characters: plus sign, decimal point, space, and lowercase "g".

20 hex = 32 dec = space
2B hex = 43 dec = plus sign
2E hex = 46 dec = decimal point
67 hex = 103 dec = "g"

Curiously, the MicroLogix 1500 doesn't seem to give an option for changing the serial framing, only the parity value.

Ken Roach · May 14, 2020

This issue smells like a serial framing problem, with the wrong parity or number of data bits.

But the exact framing issue doesn't jump out at me, nor are there obvious differences in the MicroLogix configuration.

The MicroLogix 1400 Channel Status (CS2) file shows an accumulating value of "bad characters" while the MicroLogix 1500 shows an accumulating value of received characters, which further suggests there's something wrong with the framing of the incoming data stream, like the wrong parity setting, number of bits, or data rate.

Lary · May 14, 2020

Another problem I am having is that I've never seen this in working order. I don't know what it looks like when running properly. Under normal working conditions if I was looking at ST9-String Data file the numbers should only change when an item is put on the scale? or are they going to constantly fluxuate?

Dravik · May 14, 2020

One thing I noticed with the 1500 program, was that both Serial channels were set to ASCII for some reason. Curious if that one was only communicated w/ using the DF1 reset.

Ascii Issues

Lary

Member

Dravik

Member

parky

Member

_Dock_

Member

Ken Roach

Lifetime Supporting Member + Moderator

Jim3846

Member

Lary

Member

Dravik

Member

Lary

Member

Dravik

Member

Ken Roach

Lifetime Supporting Member + Moderator

Ken Roach

Lifetime Supporting Member + Moderator

Ken Roach

Lifetime Supporting Member + Moderator

Lary

Member

Dravik

Member

Similar Topics