Ascii Issues

I suspect that the scale is set up to send data continuously. This is quite common some systems I have seen have a digital input to mimic the print key. so you will see data changing usually only by about +- 1 digit. Is the number of chars received changing if so then you may need to either set the expected string length to that of the printer or if it has CR/LF chars on the end detect that. Ken will almost certainly sort you out.
 
If this program functioned properly when I placed an object on the scale what would happen to the numbers in the ST9 data file?o_O
 
It depends on what the form of the weight message.
It will normally be a string of the same length It does really depend on the system for example, a simple print type file may be
+ 0123.0 CR LF in Hex 43 48 49 50 51 2E 48 0A 0D
or if it sends an address 010123.0 CR LF
48 48 49 50 51 2E 48 0A 0D.
If the data you are getting seems to be for example 84 84 94 05 E2 A0 D0 then it could be coming in byte reversed or the parity etc. is wrong.
Assuming that the scale is working properly and it is continuous print out then use a terminal program to read the data in a PC.
 
I'm guessing it continuously sends a signal to the PLC. The program is made to determine if a series of small parts weigh a certain amount between a high and low range. If the weight falls out of either a cylinder shoots the parts in a box labeled bad, and if parts are within weight they are moved to a good box. I've never seen this machine function properly so I'm not sure what to look for. I'm new in the PLC business.
 
Your program looks like it is designed for a scale that periodically sends 11 characters of data, in the format "+ 12.34 g", without any termination characters.

If the connection were configured and working properly, the data in ST9:0 would change every time the scale sent data to the PLC.

It probably still is; the "_1400" version of the program you sent shows data arriving in the ST9:0 file, but the data is considered "bad" by the serial port.

Go online with the MicroLogix 1400 and have a look at the Channel 2 serial status window, and see if the value in the "Bad Character Count" box is increasing.

If this were my system, I would connect to the scale with a utility program like RealTerm that would let me easily view the incoming data, and quickly experiment with different "serial framing" settings and data rates.

My guess is that the scale is set up for serial framing that is different from the 9600 baud, 8 data bits, 1 stop bit, no parity bit settings that are the default on the MicroLogix 1500 and 1400.
 
http://www.scalemanuals.com/aczetmanuals/aczet-czsquare-manual.pdf


p. 39pdf/36internal, section 9: default 9600/8/N, but doesn't state a stop bit count.


Section 9.4 describes the continuous data output.




Section 8 describes the menus, so you should be able to navigate to the serial settings.




Section 8.5 on p. 35pdf/32int. says baud rates can be powers of 2 times 600, from 600 through 9600, it also show how to set stuff in the menu, also several printing options, including continuous, auto(?), and ask (on-demand?).


Also not;) this impotent warning:
Please not that negative values cannot been edited via the interface !

 
[update: whoops, looks like indirect addressing may not be an option in the ARD instruction; maybe ARD into ST9:0, and then copy/move ST9:0 to ST9:[index]?]


If this were my system, I would connect to the scale with a utility program like RealTerm that would let me easily view the incoming data, and quickly experiment with different "serial framing" settings and data rates.


Bingo, this^ There are not a large number of settings so it should not take long.



Does Hyperterminal still exist (I used to do a lot of RS-232/RS-485 protocol work with TV/broadcast industry hardware)?


the next thing would be to write a very simple ladder program that dumps 17-character strings (per section 9.4 of the manual; see below; and that may not be the right manual, of course) into a dozen or so ST9 strings, with ST9 acting like a circular buffer, (ARD(ST9:[index],17), then index:=index+1; if index==12 then index=0.). Once you have recognizable data in ST9, then the fun begins.



Btw, Ken, along with the bad character count in the 1400; is it possible the high bit being set in ST9 characters indicates errors as well? This is ASCII, and "true" ASCII is 7-bit*, so that high bit would always be 0 and essentially ignored in good data values anyway, and so available to be used for summat else i.e. error indicator.



* although we treat LATIN1/ISO-8899-1 encoding as "8-bit ASCII"

xxx.png
 
Last edited:
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.


This would be a neat situation to get one of those apps that turn the audio input jack of a smartphone into an oscilloscope probe. Although hyperterminal or kermit will be faster.


Also, it's odd, but if we drop the high bits and consider all sets of lower 7 bits as a stream, there are no single 1s, nor any run of 1s longer than two:


attachment.php
 
Last edited:
I plugged the scale into realterm and this is what I got. If I need to change some setting please let me know which ones.

Annotation 2020-05-15 141932.png
 
I did a screen grab showing the setting on realterm. In the lower right corner the red error box when hovered over said UART receiving framing error. Is that error fixable?

5.png
 
Try

  • 8 data bits (7 is rare)
  • all baud rates between 600 and 9600 inclusive
    • my money is on 4800
  • Try different parity settings
Also switch to HEX+space display

That's around 50-60 combinations (8/7_data_bits x 6/12/24/48/9600_baud x None/Even/Odd/Mark_parity), but it will not take long.
 
According to the manual it is ASCII and contains 17 chars, the screen grab you have indicates you have the settings wrong. i.e Baud, bits etc. try different combinations.
Noted on the ascii receive block you have the length set at 11 & I believe it is possible in the setup to tell the PLC what the end chars are, this will give you consistent data.
Also according to the manual it is 8 bit no parity
 
Last edited:
Right on ! A slower baud rate on the scale side is consistent with what you're seeing with "bad" bytes, and what others pointed out about the adjacent true bits.

Change your MicroLogix Channel 2 data rate to 4800 baud and the data should arrive as expected.

Because your data stream does end with <CR><LF> you could alter the logic to use the ASCII Read Line (ARL) instead of testing the buffer for data sizes and clearing the buffer when they don't arrive, which might be easier to understand and less burden on the processor. But if the logic works, you can stick with it.
 

Similar Topics

I have a Keyence vision system (camera which will read text and output what it reads in ASCII) and a Productivity 2000 PAC. I am sending the ASCII...
Replies
27
Views
3,313
I have an L24ER-QB1B with a 1769-ASCII card in slot number 4. I'm looking to send data to this zebra printer after every completed sequence. I'm a...
Replies
2
Views
403
Hi to everybody. I need to read the first 12 characters of the message that a barcode reader sends to the ascii card (1734-rs232 ascii) and I...
Replies
8
Views
685
I am trying to import addresses and symbols from a PanelBuilder32 application into the RSLogix 5 Address/Symbol database - however each time I...
Replies
5
Views
503
Good day! I am working on a project at our campus to integrate fleet vehicle chargers with load management so we don't overwhelm our service. The...
Replies
37
Views
3,699
Back
Top Bottom