Ascii Issues

Woo hoo. I am not going to sleep tonight thinking about this.


I do coding on various topics, but protocols, they are my favorite things! (when the dog bites, when the bee stings, when I'm feeling ba-a-a-a-a-a-d ).

Everything seems to be coming together. I must thank you all for your help. I have but one more question, is there anyway to get the plc to take a snapshot of the scale data when the start button is pressed on the machine?

Lary said:

Everything seems to be coming together. I must thank you all for your help. I have but one more question, is there anyway to get the plc to take a snapshot of the scale data when the start button is pressed on the machine?

Click to expand...

The start button on which machine? On the scale, or on some HMI, or on summat else?

After loading parts on the scale you hit the start button on the machine it then takes the weight reading from scale and at that point the plc decides pass or fail depending on the criteria.

Totally then, The same routine that is doing the 'compare' can just shove the scale value into a storage location.

The other way is to create a one shot off the button and move the data to another register. I have not seen your program but you must be doing a compare ? is that after converting the ASCII data to a real value ? Like the last post, when you press the button you must have some logic that does the comparison so the best way is to do it there.

The program is on page 1 and #7 of this thread. It's a zip of the rss file.

Yes Lary but I do not have RSL loaded at the moment so cannot view it.

Here you go; 1500 was the origina, IIRC; I used RSL Micro Starter Lite freebie which supports neither 1500 nor 1400, so I hope it cam out okay.

Lary said:

After loading parts on the scale you hit the start button on the machine it then takes the weight reading from scale and at that point the plc decides pass or fail depending on the criteria.

Click to expand...

It may complicate things some, but I think that scale has a way to receive a command over the serial line that tells the scale to send the reading.



But I think the continuous thing would be much better; have the [Start] button go to the PLC, which triggers the PLC to

• Clear the serial buffer
• Use ASL to read half-dozen or so lines into consecutive strings in a string file
  • string buffer should be at least 18 (20) chars
    • previous line's newline plus one line of 17 (19?)
• throw away the first line, which could be short
• parse the next few lines until you get one that is valid

I know I'm going to sound like a complete armature, but I don't even know what those changes would look like or how to put them in. Plus what lines where you talking about?

Lary said:

I know I'm going to sound like a complete armature, but I don't even know what those changes would look like or how to put them in. Plus what lines where you talking about?

Click to expand...

Oh, don't get all wound up about it, we all start from somewhere.


a line comprises the data between two line termination sequences i.e. one reading per Section 9.4 of the Aczet user manual.





TL;DR


A line is one reading from the scale e.g.
The ASL instruction reads data from the serial port. It breaks the data into lines using the line termination convention supplied to the ASL; in the Aczet case the line termination is a pair of non-printable characters: carriage return (<CR>; ASCII 13 = 0Dh); linefeed (<CR>; ASCII 10 = 0Ah).


The lines are sent continuously e.g.


which would be broken into


by a series of ASL instructions, with the last [ST,GS 157.9g <CR>] left in the buffer because the <LF>, second character, of the line termination sequence had not arrived yet.



So a line comprises the data between two line termination sequences.



Those are the same lines you saw in realterm, with a [CR] and [LF] shown as the last two glyphs the right, because you had some combination of realterm ASCII/Hex Font options turned on.



So the code would clear the buffer and then start reading lines into strings, throwing away the first one because the clear might have been done in the middle of a line so the first line would be partial, but the code don't care because the data are coming in continuously at 480cps and there are plenty of data to choose from.



Glossary


"File" is the Allen-Bradley (A-B or AB) moniker for what almost everyone else on the planet calls memory, but it goes a step further in that each file comprises data of a particular type (integer, real, string, etc.).


A "String" is in a string "file" comprising one or more strings; each string comprises one or more characters (bytes). String files have names like ST9 or ST255, containing individual strings accessed by syntax such as ST9:0 (the first string in string file 9), or ST255:10 (the eleventh string in string file 255).


Carriage return and linefeed terminology comes from teletypes, which in turn came from typewriters.



A carriage return moves the carriage to the right (in this case the screen cursor to the left) edge.


A linefeed rolls the platen up (in this case move the screen cursor down) one line, but if the cursor is at the bottom of the window it moves all lines up one line first.

The first problem to fix is that the current code has an ARD instruction on Rung 0000 of LAD 3, when it should be an ARL instruction, as Ken pointed out earlier.


However, that would involve a lot of editing of other things, and there may be a quicker solution: in the PLC program, change the

• [Index 2] to [Index 4] in the first AEX on Rung 0005 of LAD3
• LAD 3
• [Index 7] to [Index 9] in the second AEX on Rung 0005 of LAD3
• [Number 2] to [Number 1] in the second AEX on Rung 0005 of LAD3
• [Index 11] to [Index 10] in the third AEX on Rung 0005 of LAD3

That will make the parsing of the serial port work about twice per second; it will throw errors the rest of the time but hopefully the code will not care if you make Rung 0008 of LAD 3 look like the images below (to do the latter, double-click on the 0008, then replace the text that is there now with the text as shown e.g. copy-paste from here;

Then hit [Enter]




Heh, if this works ...

Also, remove the XIC of B3:0/7 in rung 0000 of LAD 5 (the highlighted instruction below).


Also, discrete input I:0/4 is the [Start] button for acting on a measurement.

First cut, based on the originally-supplied 11570_1400.RSS.


Lary will need to re-configure for his ML1400; also need to check the serial port channel, baud, bits, parity, etc.



If just the weighings work (reasonable values showing up in L12:0) I'll consider it successful.


PDF and RSS included.