In over my head (ladder logic) Horner PLC, serial Barcode scan

Minor change to second rung; I am not sure how RECV instruction works, so putting a [NC Read_Processed_oneshot] back in, between the AND and the NEQ, may be required.
 
Converted to Cscape (not too bad; at least not as awkward as TIA or CCW ;)); placed on Github: https://github.com/drbitboy/PLC_Cscape_serial_read_logic




Thank you for all the time and working with me, I was trying to convert to Cscape and got so many errors, then saw you did it...


We're close-ish, Trying to debug right now.


I've added green and red light firing below the coils for Compare_(complete/fail)


Currently, It only extends the cylinder while the PP1 is made (retracts if part is taken away)


all barcode results in red light right now, and PP2 is not currently in shown in the ladder. It should reset the cycle and raise the cylinder.
 
Thank you for all the time and working with me, I was trying to convert to Cscape and got so many errors, then saw you did it...


We're close-ish, Trying to debug right now.


I've added green and red light firing below the coils for Compare_(complete/fail)


Currently, It only extends the cylinder while the PP1 is made (retracts if part is taken away)


all barcode results in red light right now, and PP2 is not currently in shown in the ladder. It should reset the cycle and raise the cylinder.


I am not getting any characters updating on the Horner screen


What should reset the M13 Read_processed_oneshot NC? It stays lit after first scan
 
Last edited:
I am not getting any characters updating on the Horner screen
Hmm, but you were getting characters on the Horner screen before, correct?
What should reset the M13 Read_processed_oneshot NC? It stays lit after first scan
Well, here is how I assumed it would happen:

  • Scan N
    • Rung 2
      • [Read_complete %M12] becomes 1 when one character is read by the RECV instruction
    • Rung 5
      • [Read_processed_oneshot %M13] becomes 1 (lit)
        • because [Read_Complete %m12] is 1
        • I.e. Read_processed_oneshot is the one-shot "memory" for detecting the rising edge of [Read_complete %M12]
  • Scan N+1
    • Rung 2
      • [NC Read_processed_oneshot %M13] is false
        • because [Read_processed_oneshot %M13] is 1 from the previous scan,
      • so "power flow" through RECV instruction should, I assumed, be false,
      • which should result in assigning a 0 to [Read_Complete %M12]
    • Rung 5
      • If [Read_Complete %m12] is 0,
      • then [Read_processed_oneshot %13] will be assigned 0
If that is not happening, then the most likely problem is that I am making ignorant assumptions of how "power flow" through the RECV instruction works.

N.B. I am using the phrase "power flow" only because that is the terminology in the Cscape manual.
 
P.S. If you are a beginning PLC programmer, this series of videos:will be well worth the sub-two hours of time investment. It's not Cscape/Horner, but you will learn to read a ladder diagram.

N.B. I realize that is a suspect statement as I seem to have gotten it wrong, but I am pretty sure the problem is in my understanding of the RECV instruction, specifically what the RECV input rung means.
 
P.S. My first rungs, with the screen and the OPEN instruction, are different than yours; perhaps the OPEN needs to be fed by an [NO ALW_ON]?


Also, I was focusing on the serial comm port code; I assumed the logic for PP_POS2 et al. would be added later.
 
I know this doesn't help you immediately, but when it comes to serial data stuff and interfacing with scanners, sometimes you need an experienced plc programmer to figure these things out. You might need to add a bit of extra code to debug what is happening and go from there.


Have you thought about just hiring an experienced guy to help you out for a couple of days?
 
I know this doesn't help you immediately, but when it comes to serial data stuff and interfacing with scanners,

Good advice; I should have mentioned something like this a couple dozen posts ago.

Using a PC with HyperTerminal or Kermit (I'm dating myself; use whatever is current) to manually sort out exactly how the scanner's serial comms work should be done before trying to use the PLC's serial interface.
 
Most PLC's have a separate processor for communications (especially if it is an add on card). If these ports have a selection of modes/protocols most of the work is done for you, for example on receiving a communication there are a number of possibilities, the configuration is set up to expect a start and (or) end chars i.e. STX & CR, the in-built code in the communication processor will then depending on the settings only post the complete packet into the user buffer when the CR char has been seen, there are many ways in which packets can be processed, simple ASCII where everything is put into the buffer & relies on char timeout for end of packet, control chars, fixed length etc. Many give the option for a strict packet length. some even have specific protocols so things like checksum etc. are evaluated.
Unlike writing a coms program on a PC, PLC's will at least have some of these features, Not used the latest bar code readers but in the 90's most would give a simple ASCII string with terminating char, in saying that, even in those days I wrote a number of protocols using the Siemens 525 communication processor, the only real code to master was things like CRC's or checksums of varying types. TBH the last communication system I did that required some code was with some weigh indicators in 2008
The only things I had to do was wait for the RX buffer to populate, check the address & calculate the checksum, convert the packet into a real number. As far as sending commands again pretty simple, poll them to request weight, send tare & gross commands & that was it.
 
Below is everything I found for the RECV instruction in Horner's Cscape program. No intelligence or other options looking for Carriage Returns and such.

I assumed the [RX Count] parameter, because it was on the right-hand side of the visual, was an output reporting how many characters were copied, but perhaps it is an input parameter? Ya gotta the parenthetical "(or -1 when the instruction is not)." at the end of the description for [RX COUNT]; not ... WAHT? In over twenty years I have seen very few manuals describing serial protocols that were either accurate or not marked "DRAFT" on the title page, and this one keeps that statistic alive.

In any event, its interaction with input parameter [BYTES], the "maximum number of bytes to be received" is unclear. Maybe [BYTES] sets the size of the UART input buffer, and [RX Count] is an instruction input parameter declaring how many characters we want to copy for each positive edge of the input rung?

@Ted_Z: try putting a 1 in %R00100?

xxx.png
 
Last edited:
I know this doesn't help you immediately, but when it comes to serial data stuff and interfacing with scanners, sometimes you need an experienced plc programmer to figure these things out. You might need to add a bit of extra code to debug what is happening and go from there.


Have you thought about just hiring an experienced guy to help you out for a couple of days?


I would... But there is no-one available, Multiple sources, All busy with large projects


I'm really stumbling at this point.


I've gotten my code working, Almost, It won't work once i have a bad read. Works for good reads as i expect. I'm sure the logic is ugly as hell.


If i use work from the code that @drbitboy generated, I cannot get it to work so far...


I've watched about half the videos he sent, i just don't know why i cant get this into my thick skull
 
@DR: Hmm.... Very poor PLC in my opinion, Even in the Mitsubishi FX brick PLC's there are about 10 blocks of registers that deal with communications
here is a sample of just one of them
RS instruction and computer link [ch1] (Refer to the data communication manual for details.)
D 8120*3 RS instruction and computer link [ch1]: Communication
format setting
3333 3 -
D 8121*3 Computer link [ch1]: Station number setting 3333 3 -
[D]8122*4 RS instruction: Number of remaining send data points 3333 3 M8122
[D]8123*4 RS instruction: Monitoring of number of received data points 3333 3 M8123
D 8124 RS instruction: Header (Initial value: STX) 3333 3 -
D 8125 RS instruction: Terminator (Initial value: ETX) 3333 3 -
[D]8126 Unavailable - - - - - -
D 8127 Computer link [ch1]: On-demand head number specification 3333 3
D 8128 Computer link [ch1]: On-demand data quantity specification 3333 3 M8126 to M8129
D 8129*3 RS instruction and computer link [ch1]: Timeout time setting 3333
Something I just caught glimpse of was something to do with a CRC instruction :doh2:does that mean I have been trying to invent the wheel,
I know you are a perfectionist but it appears the OP already has the data so is more concerned in getting the logic correct.
 
...
I know you are a perfectionist but it appears the OP already has the data so is more concerned in getting the logic correct.
OP is using Horner/Cscape RECV instruction to read fixed-length data, presumably 28 characters of code plus a carriage return.

As long as that is what continues to come in on each RECV read
, the 'BC' character pair just before the <CR> starts at an offset of 26 from the first character, so it is easy to test, the program works, God is in His heaven and all is right with the world.

However (and as I predicted oh so many posts ago ;)), one bad, or noisy, or short, or long, bar code read and all subsequent codes go out of phase with the fixed-length, 29-byte reads, and it's a mess (God is still in His heaven - of course, I'm Reformed - but all is not right with the world;)).

So what OP needs is a robust reader-parser.

So, yes, I may sound like a perfectionist, but really I only want to (a) detect with certainty between perfection and imperfection, and (b) recover from the latter.
 
Last edited:

Similar Topics

Good Afternoon , I'm sure there are many Ishida Muti-Head Weigh Systems . We have a Ishida CCW-M-214W Multi-Head system . We are...
Replies
1
Views
418
Hi all, have a project which requires reading a weigh head weight over ASCII. Never really touched ascii so struggling a bit. The weigh head is in...
Replies
11
Views
1,182
Good Morning , We have a Ishida Multi-Head Scale . I had experiece with them for chips , crackers , etc. , but now we are using them for...
Replies
7
Views
424
Hello expert I have migrate legacy project that use Applicom OPC DA with 3rd client and S7-400. I see in client code add item string call...
Replies
0
Views
344
Got another one a whole team of us and the OEM cannot figure out. Powerflex525, 20HP VFD, commanded over Ethernet won't turn a motor it's turned...
Replies
32
Views
7,640
Back
Top Bottom