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

[drbitboy]

... or more likely their wives have highlighted to them, that they aren't going to have endless healthy days to do all the things they had thought they would like to do when they don't have to earn a $.

@PLCnovice61 thank you for the kind concern; it is a question I often ask myself, and been asked by my wonderful wife. And not to put too fine a point on it, I would be foolish to not listen to someone who agrees with my brilliant wife.

That said, you are not normative, my wife is not normative, and I soytenly am not normative.

But again, thank you for the well-meaning and kind concern; it will not be ignored.

 

[drbitboy]

I've never once sat back and though, Hmph, what am i wasting my life for, buncha sods

Hmph, I think that all the time ...

Speaking of which: @Ted Z, do you have a robust read algorithm working yet, that can handle short or long codes, and recognize valid an invalid codes? Forget about the 1-prox, 2-prox, red-light, green-light stuff, that is trivial; you are dead in the water on this project without a robust read-parse-evaluate cycle.

 

[Ted Z]

Hmph, I think that all the time ...

Speaking of which: @Ted Z, do you have a robust read algorithm working yet, that can handle short or long codes, and recognize valid an invalid codes? Forget about the 1-prox, 2-prox, red-light, green-light stuff, that is trivial; you are dead in the water on this project without a robust read-parse-evaluate cycle.

Sorry for the lack of info/communication past few days


I'm trying to get back where i was on friday, I had to get it all wired in to the final cart it's installed on and also had a machine to repair before coming back to this.


I really thought i had a good cycle going on friday when i left... I'm back to stumbling around on wishful thinking programming.

 

[Ted Z]

Sorry for the lack of info/communication past few days


I'm trying to get back where i was on friday, I had to get it all wired in to the final cart it's installed on and also had a machine to repair before coming back to this.


I really thought i had a good cycle going on friday when i left... I'm back to stumbling around on wishful thinking programming.

So yeah, This is getting close... Hard for me to answer HOW.


At this moment, it is "working" as i expect on the table.


Of course, i cannot get the program to run once i'm disconnected from my PC. I have set this program as default and set it to autorun and autoload on power loss/etc.


I reached out to Horner again to understand what to do or check next

 

[drbitboy]

I had a quick look at Horner XLE user manual; it looks like there may be quite a few option to tweak in the Fail-Safe system (chapter 17?) to make it restart in run mode.

 

[Ted Z]

I had a quick look at Horner XLE user manual; it looks like there may be quite a few option to tweak in the Fail-Safe system (chapter 17?) to make it restart in run mode.

Thank you, I saw that. Now i'm finding that the internal battery was dead, but not faulting as a bad battery.


I had to attempt to run production today. It's going alright, It seems to stop (maybe after too long in-between parts) and it takes some fumbling around before it will run again.


The barcode reader is beeping every 10s or so, probably need to figure out how to request read on it still.


Also, I wonder if i can work the logic to reset the cycle when Part_POS2 switch is made, But then allow another part to scan and pass, before the first one is removed from Part_pos2



I'm going to start putting the second assembly together and get back into the logic, Hopefully i can make enough sense to improve function on the second and can put a new program into the first once its better.

 

[parky]

Many BC readers also have a digital trigger input if it has then you could trigger it from an output from the PLC.

 

[drbitboy]

Also, I wonder if i can work the logic to reset the cycle when Part_POS2 switch is made, But then allow another part to scan and pass, before the first one is removed from Part_pos2

Use a one-shot to detect the rising edge of of Part_pos2, and then do the reset with that one-shot. We may need a debounce on the falling edge i.e. disable the rising edge one-shot for a few seconds once Part_pos2 becomes 0 again.

Post your code; a working machine is better than a comfortable ego.

 

[Ted Z]

Use a one-shot to detect the rising edge of of Part_pos2, and then do the reset with that one-shot. We may need a debounce on the falling edge i.e. disable the rising edge one-shot for a few seconds once Part_pos2 becomes 0 again.

Post your code; a working machine is better than a comfortable ego.

I know my code understanding and ability isn't great... My ego is never an issue


I'll be back at it Monday morning Have a great weekend!

 

[drbitboy]

There is no way that implementation is robustly reading the scanner data.

Suggested improvements:

• Remove the [NO Contact PART_POS1 %I0001] on rung 2
  • The scanner will perform a scan when the part is in position,
    • we don't was noise from the position sensor interrupting the read
• The bit [Read_processed_oneshot %M00013] is unnecessary
  • Replace all occurrences of Read_processed_oneshot (rungs 2, 7, 8) with Read_complete
  • Remove rung 4
• [Compare_complete %M00014] is redundant with [GRN_LIGHT %Q0011]
  • Remove [NO Coil Compare_complete $M00014] from first output branch on current rung 7
  • Replace remaining two occurrences of Compare_complete, one on seal-in branch of current rung 7, one on Start branch of current rung 8, with GRN_LIGHT
• [Compare_fail %M00015] is redundant with [RED_LIGHT %Q0012]
  • Remove [NO Coil Compare_fail %M00015] from first output branch on current rung 8
  • Replace occurrence of Compare_fail, on seal-in branch of current rung 8, with RED_LIGHT
• Replace [SET CYL_RET %Q00002] on current rung 7 with [NO Coil CYL_RET %Q00002]
  • Remove current rung 8

 

[parky]

I have done this exact process, what I found was that it takes a 100ms or more to get the data into the buffer (note the buffer is not the uart one but the buffer you tell the coms function to put it in %R1000).
So on rung 3 do a compare of the rx count (%R0100) > 0 then put a small timer of 200ms (about right for 9600 baud) then do a check on the amount of chars if not 29 then you have bad data, if good then process your data.
I cannot test this on your system but from what I gather it is similar to many other non protocol coms on other PLC's. Yesterday I did a test, I wrote it this way, then echoed the data in a send block back to my PC based coms program tried 100ms but a character length of 60 characters it missed a few, found 200ms worked consistently.

 

[Ted Z]

There is no way that implementation is robustly reading the scanner data.

Suggested improvements:

• Remove the [NO Contact PART_POS1 %I0001] on rung 2
  • The scanner will perform a scan when the part is in position,
    • we don't was noise from the position sensor interrupting the read
• The bit [Read_processed_oneshot %M00013] is unnecessary
  • Replace all occurrences of Read_processed_oneshot (rungs 2, 7, 8) with Read_complete
  • Remove rung 4
• [Compare_complete %M00014] is redundant with [GRN_LIGHT %Q0011]
  • Remove [NO Coil Compare_complete $M00014] from first output branch on current rung 7
  • Replace remaining two occurrences of Compare_complete, one on seal-in branch of current rung 7, one on Start branch of current rung 8, with GRN_LIGHT
• [Compare_fail %M00015] is redundant with [RED_LIGHT %Q0012]
  • Remove [NO Coil Compare_fail %M00015] from first output branch on current rung 8
  • Replace occurrence of Compare_fail, on seal-in branch of current rung 8, with RED_LIGHT
• Replace [SET CYL_RET %Q00002] on current rung 7 with [NO Coil CYL_RET %Q00002]
  • Remove current rung 8

I'm making these changes so i can try them out on the machine...


"remove current rung 8" I need Part_pos2 somewhere to reset the system and raise the cylinder, no?

 

[Ted Z]

I have done this exact process, what I found was that it takes a 100ms or more to get the data into the buffer (note the buffer is not the uart one but the buffer you tell the coms function to put it in %R1000).
So on rung 3 do a compare of the rx count (%R0100) > 0 then put a small timer of 200ms (about right for 9600 baud) then do a check on the amount of chars if not 29 then you have bad data, if good then process your data.
I cannot test this on your system but from what I gather it is similar to many other non protocol coms on other PLC's. Yesterday I did a test, I wrote it this way, then echoed the data in a send block back to my PC based coms program tried 100ms but a character length of 60 characters it missed a few, found 200ms worked consistently.

I'm going to look at testing this after i get the recent changes from Drbitboy made

 

[drbitboy]

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.

"remove current rung 8" I need Part_pos2 somewhere to reset the system and raise the cylinder, no?

Sorry, that should be "Remove current rung 9"

And I forgot that a [NC Contact PART_POS2 %I0002] should be added to current rung 8, replacing the existing [NO Contact PART_POS1 %I0001] as the Stop portion of the Start/Stop pattern.

So

1. If a valid code was read, AND GRN_LIGHT was assigned a 1 turning on the green light and retracting the cylinder, AND after that the part passes the retracted cylinder and triggers the position 2 prox so PART_POS2 becomes 1,
   1. Then [NC Contact PART_POS2 %I0002] will become False,
      1. Which will assign 0s both to GRN_LIGHT and to CYL_RET,
         1. Which will in turn turn off the green light and extend the cylinder

The point here is that PART_POS1 is not required detect, or react to, a valid code: the scanner and the rest of the logic will do that without PART_POS1, because when a barcode enters the scanner's field of view (i.e. the area it scans), and more specifically when a carriage return is detected, PART_POS1 is redundant.

In an earlier post @Ted Z asked if another scan could start on a new part while the previous part was at position 2, so PART_POS2 would still be 1. In that case having [NC Contact PART_POS2 %I0002] as the anti-Stop condition of the Start/Stop pattern would leave the green light on and the cylinder retracted. So the way to accomplish this, i.e. make another scan while a part is still at position 2, would be to replace that [NC Contact PART_POS2 %I0002] as the Stop condition with a [NC Contact PART_POS2_rising_edge], where PART_POS2_rising_edge is a one-shot that reacts to a 0-to-1 transition of PART_POS2, i.e. there would be a new rung, just before the GRN_LIGHT rung, with two elements in series: [NO Contact PART_POS2 %I0002]; [Postive Transition Coil PART_POS2_rising_edge].

 

[drbitboy]

There is no way that implementation is robustly reading the scanner data.

Suggested improvements:

• Remove the [NO Contact PART_POS1 %I0001] on rung 2
  • The scanner will perform a scan when the part is in position,
    • we don't was noise from the position sensor interrupting the read

I am going to back off, somewhat, from this statement and recommendation. According the the Horner Automation video, when the RECV instruction's input rung is False, that clears the internal serial buffer.


So when PART_POS1 goes from 0 to one, the RECV will have an empty buffer. That being the case, as long as that happens before the barcode scanner starts sending serial data, and if the scan is a complete 29-character (28+carriage return) read, then the %R01000 buffer should contain a full barcode scan and the RECV will complete and the rest of the logic should be okay.


However, if there is a short or long scan, I am not sure the current code will alwyas trigger the red light. That said, with the [NO Contact PART_POS1], the read and system will be reset for the following part.