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

Ted Z · Oct 22, 2021

drbitboy said:
I still do not think the read loop is robust as it is implemented now; relying on reading exactly 29 characters will eventually fail and hang up the process.

This is correct.

1. As of now, When i scan a good code, it does as expected.

2. When i scan a correct length bad code, the red light illuminates.
If i scan a good code after (without breaking PART_POS1) red and green illuminate and the cyl retracts.

(this is alright, but should switch from red to green, not both)

3. When an incorrect, mismatch length barcode scans, it does nothing, Then a good code scanned does nothing. (light should illuminate red)

Then if i break contact with PART_POS1, make and rescan, it does as expected.

So as of now, the logic cannot robustly verify good and bad codes.

What's next? I have this almost wrapped, this last bit and i believe im set. I am going to build one more assembly to practice on and work at fully understand the logic we've come up with here

** IS this code from post #60 http://www.plctalk.net/qanda/showpost.php?p=895960&postcount=60
still possibly the way to get this more robust?

drbitboy · Oct 22, 2021

This should fix the two-lights-on-at-the-same-time issue.

That 251-byte read *might* work, but I expect the most robust algorithm will be the one suggested in the Horner video i.e. wait for a time period where the number of characters read (RX Count) is non-zero (in our case, greater than two) and constant.

Btw, I would not bother with a timer as they did in the video; a counter that increments by 1 on each scan cycle should be adequate, probably about 250 to 25, assuming a scan time of 1ms to 10ms; you might have to find the best value empirically.

The increment would be unconditional whenever the counter is less than 251 (or 26).

The counter would be assigned a value of 0 if either the [RX Count] value was less than 3, or the [RX Count] value was not the same as the [RX Count] value saved from the previous scan.

When the counter is 250 (or 25), that is the scan which is the equivalent of the Read_Complete bit being one in the current code, so remove the [Normally Open Coil Read_Complete] from the output rung of the [RECV] instruction, and add a rung comprising

[EQ_INT %R00100(RX Count) 250] => [Normally Open Coil Read_Complete]

after the RECV.

Ted Z · Oct 22, 2021

drbitboy said:
This should fix the two-lights-on-at-the-same-time issue.
View attachment 59840

That 251-byte read *might* work, but I expect the most robust algorithm will be the one suggested in the Horner video i.e. wait for a time period where the number of characters read (RX Count) is non-zero (in our case, greater than two) and constant.

Btw, I would not bother with a timer as they did in the video; a counter that increments by 1 on each scan cycle should be adequate, probably about 250 to 25, assuming a scan time of 1ms to 10ms; you might have to find the best value empirically.

The increment would be unconditional whenever the counter is less than 251 (or 26).

The counter would be assigned a value of 0 if either the [RX Count] value was less than 3, or the [RX Count] value was not the same as the [RX Count] value saved from the previous scan.

When the counter is 250 (or 25), that is the scan which is the equivalent of the Read_Complete bit being one in the current code, so remove the [Normally Open Coil Read_Complete] from the output rung of the [RECV] instruction, and add a rung comprising

[EQ_INT %R00100(RX Count) 250] => [Normally Open Coil Read_Complete]

after the RECV.

Alright, That fixed my light issue.

If an incorrect barcode is scanned, it doesn't turn red (ie, water bottle, chip bag, etc)

If i break PART_POS1 then scan a good or bad correct length code after re-making PART_POS1 then all works correct...

I am not finding that Horner video at this time, Do you have the link?

I can attempt to do whats in there, Or if you don't mind a little more assist...

drbitboy · Oct 22, 2021

Ted Z said:
I am not finding that Horner video at this time, Do you have the link?

I can attempt to do whats in there, Or if you don't mind a little more assist...

It's a few posts back: https://www.plctalk.net/qanda/showthread.php?p=895784#post895784

I think I also implemented that method, untested of course: https://raw.githubusercontent.com/d...l_read_logic/master/drbitboy_barcode_time.pdf

L33er · Oct 23, 2021

boy, most basic thing in AB PLC perhaps.

Ted Z · Oct 23, 2021

drbitboy said:
It's a few posts back: https://www.plctalk.net/qanda/showthread.php?p=895784#post895784

I think I also implemented that method, untested of course: https://raw.githubusercontent.com/d...l_read_logic/master/drbitboy_barcode_time.pdf

I am looking at this today.

While reading, i see that i can program the scanner to add a prefix/suffix to the data on scan. Would it be easier to have a known end character on all scans?

Ted Z · Oct 23, 2021

L33er said:
boy, most basic thing in AB PLC perhaps.

That's great. Too bad i dont have an AB PLC or experience programming them. Seems it would be solved already then

L33er · Oct 24, 2021

Ted Z said:
That's great. Too bad i dont have an AB PLC or experience programming them. Seems it would be solved already then

Ted, stick to the designer.

Ted Z · Oct 25, 2021

L33er said:
Ted, stick to the designer.

Thanks for the vote of confidence. Good luck yourself.

drbitboy · Oct 25, 2021

Ted Z said:
I am looking at this today.

While reading, i see that i can program the scanner to add a prefix/suffix to the data on scan. Would it be easier to have a known end character on all scans?

I think the carriage return, that is already the suffix/terminator, is all that should be needed.

Ted Z · Oct 25, 2021

drbitboy said:
I think the carriage return, that is already the suffix/terminator, is all that should be needed.

Even for scans where the code isn't expected length? (i assumed CR was from the code im scanning, It must come from the scanner?)

drbitboy · Oct 25, 2021

Ted Z said:
Even for scans where the code isn't expected length? (i assumed CR was from the code im scanning, It must come from the scanner?)

Yes, the scanner itself adds the CR, and by default, if I remember the documentation correctly.

So a CR will, usually I assume, will be followed by a pause (the scanner has an inihibit-duplicate-code timeout, again IIRC); the example in Horner's youtube video detects that pause. So if you do the same thing, all your code has to do is check the last three characters - 'BC<CR>' nominally - and act accordingly. N.B. that does not check the length of the scanned code!

Ted Z · Nov 2, 2021

drbitboy said:
It's a few posts back: https://www.plctalk.net/qanda/showthread.php?p=895784#post895784

I think I also implemented that method, untested of course: https://raw.githubusercontent.com/d...l_read_logic/master/drbitboy_barcode_time.pdf

I'll get this right one of these days... I am still unable to get a red light on a bad, unknown length code (ie doritos bag, water bottle, etc)

I'm back to your barcode_time.pdf for ref...

I'm not getting a green on good scan.
I see that the data comes into Rx_buf %R00101, But our compare string is using Cmp_Buf %R00501 as its source.... Im not seeing how we moved the data from 101 to 501, Or is there a typo here i'm catching?

Ted Z · Nov 2, 2021

Ted Z said:
I'll get this right one of these days... I am still unable to get a red light on a bad, unknown length code (ie doritos bag, water bottle, etc)

I'm back to your barcode_time.pdf for ref...

* this code is not working much at all * I thought it was, I'm back to grasping at straws i think. going back to the code that i had working a few days ago and see if i can implement the counter or timer (attached.... This one is working, except rejecting bad codes)

Guess @L33R is right. I should stick to mechanical things

drbitboy · Nov 2, 2021

Rung 5, grid positions 11/I and 12/I, should be transferring the data, which was read from the scanner and placed in [%R00100 through %R00127] by the RECV instruction, both to [%R00300 through %R00427] and to [%R00500 through %R00627].

I notice the TON has a 0.1s in it; that should be 0.01s, IIRC, so the timer expires after a quarter-second (twenty-five 0.01s steps), not after two and a half seconds (twenty-five 0.1s steps), although that may not matter.

Update: if the scanner sends another code before the timer expires (2.5s after the last code), then the [RX Count => RX_Cnt] may continue to increment, which will keep the timer from ever completing, so maybe that 0.1s/0.01s is the problem.

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

Ted Z

Member

drbitboy

Lifetime Supporting Member

Ted Z

Member

drbitboy

Lifetime Supporting Member

L33er

Member

Ted Z

Member

Ted Z

Member

L33er

Member

Ted Z

Member

drbitboy

Lifetime Supporting Member

Ted Z

Member

drbitboy

Lifetime Supporting Member

Ted Z

Member

Ted Z

Member

drbitboy

Lifetime Supporting Member

Similar Topics