Handshake data between two PLCs

quadPLC

Member
Join Date
Feb 2010
Location
Milwuakee
Posts
51
Hello everyone,
I have a scenario where a machine is building boxes of widgets (we shall say...) and the boxes eject down a conveyor to another machine which places said widgets on a pallet to be shipped. The second machine ALSO tracks how many widgets total are on the skid

Under normal circumstances, each box has the same number of widgets in it, but sometimes less or more widgets end up in a box. I currently pass down the number of widgets in the most recently-ejected box to machine 2. however, I don't have any guarantee that the box will make it to the second machine.

An operator might take a box off the conveyor for inspection, or an operator might throw a box on the conveyor that he packed by hand.

Currently there are photo eyes on the conveyor so I basically know when a box disappears, but I am trying to formulate some sort of handshaking between the two machines to check that when I eject a box from machine 1, I should see a box get placed on the skid shortly thereafter. If the second machine places a box, and I haven't recently ejected one, then it should just have some default quantity in it.

Anyone have any thoughts on this? I was thinking a simple "SYN"/ "ACK" kinda thing where the machine 1 would send down "Hey, I just ejected a box" and when the box gets placed on the pallet machine 2 would say "I just placed a box". However, I dont know if that will end up being enough to deal with the situations I explained above.





Thanks for being patient with me, guys. I feel like I am always the one asking questions and never the one answering them...
 
An operator might take a box off the conveyor for inspection, or an operator might throw a box on the conveyor that he packed by hand.


the other idea is good but another thing to add may be a button for when the operator removes a box. As well as a button for when a manually placed box is added to machine two. Use the buttons in your program tracking. Granted this is no quarantee but it should allow some tracking improvements
 
Can anything but the operator cause the 'more' or 'less' widgets condition? In other words, can the first machine over or under pack a box? And does this machine know when it has done this?

🍻

-Eric
 
Can anything but the operator cause the 'more' or 'less' widgets condition? In other words, can the first machine over or under pack a box? And does this machine know when it has done this?

🍻

-Eric
Upon rereading, I have answered my own question... :oops:

I don't see any way to keep track of what the operator adds or subtracts, unless you make them responsible (as Mordred suggested). For accurate results, you might want to look at determining the quantity in the box at the palletizer. I'm thinking along the lines of a weigh scale, but I don't know what type of product it is.

🍻

-Eric
 
We use a simple Req/Ack scheme

Every time you send something you toggle a Request bit. The receiver must check if the Request bit and the Ack bit have the same polarity. If not then the receiver knows new data is present. The receiver then copies the data and sets the Ack bit to the same polarity as the Request bit. The sender must wait until the Ack it is the same polarity as the Req bit before sending more data.
 
use a counter

if im understanding correctly you could use simple counters one at the front of the line and one at the end if the line was empty at the start of the shift or adjusted by counting the # of boxes between each counter ...if you sent 10 boxes down the line frist counter would be 10 and the counter at the end of the line had a diffrent count say 11 then some one added one or if less took one off a simple photo cell would do this and a small program change in the plc if you are using plc if not a counter activated by a laser beam or photo cell...at make and brake make a count.....
 
Unfortunately the counter photoeye method does not cover all the range of possibilities. Particularly with operator interferance. One possible way to cause a problem with counter is say at the same time operator A removes a box at machine A and Operator B places a box back on the second machine. Everything would seem OK right up till the end when the total count is off but you would have no idea as to when it occured.
 
counter

If that where the case then all would still be in sink..a simple fix to correct a error as such from happening woud be to inform everyone not to add or take away at a said point say before the counter ...we had a similar problem at work our plant count and placed on yard was off by several hundred the count system worked most of the time but their is allways room for error when humans are involved we finally fail safed our counting system by bar code ......
 
yeah barcode is probably a better solution. After years of chasing operators or workers about not doing this or that. I've essentially given up on that ever being a possibility. You no sooner train one worker then he quits gets replaced by another proces starts over again etc etc etc. If you want a good example of that try getting them not to use an E-Stop instead of the process stop.
 
if a box disappears then do not count.
if a box extra is on the line take your default.
and yes you could use the count when it passes the cel of machine 2
and if the conveyor gets empty the count is not used.
btw take care of stopping machine 1 when conveyor is full.
 
any possiblity of adding a scale on the second machine. If so each widget would weigh y amount. If less than total weight take the difference devide widget weight Y to know how many widgets to add.

If I understand your problem you need to know how many widgets are in each box at machine two from machine one. As you have operators that move things around you need some form of accurate record of that number of widgets/box.

The use of counters are too easily fooled to keep track of this reliably. Another example box 1 has 30 widgets box 2 has 40 widgets, operator places box 2 ahead of box 1 (Uh OH)

If the widgets are all equal weight adding a scale and performing simple math would give you an accurate amount of widgets per box.
 
Last edited:
if im understanding correctly you could use simple counters one at the front of the line and one at the end if the line was empty at the start of the shift or adjusted by counting the # of boxes between each counter ...if you sent 10 boxes down the line frist counter would be 10 and the counter at the end of the line had a diffrent count say 11 then some one added one or if less took one off a simple photo cell would do this and a small program change in the plc if you are using plc if not a counter activated by a laser beam or photo cell...at make and brake make a count.....


Yeah, I have sorta settled on something like this, mixed with what shooter suggested.


In the normal scenario, a box of product issues from Machine 1 and a counter is incremented. When the product gets to machine 2, it is decremented again. If the counter is zero after decrementing, I can assume with some confidence that the box had the 'ejected quantity'. This value is saved in a rolling average of the quantities for the past 5 boxes.

In the scenario where a box is added to the conveyor by an operator, the decrement via machine 2 would make the counter go negative, meaning that we don't know with much certainty what the quantity is. Therefore, we use the average quantity claculated from previous boxes.

In the scenario where multiple boxes are queued on the conveyor (doesn't happen that often, usually only when machine 2 breaks), then we have likely lost the logs' ejected quantity from machine 1, so we again just use the average. Again, this doesn't happen very often so the count is not usually affected much by this scenario.

Since the product is being stacked for intermediate storage, it is not going out to customers and the quantities aren't under quite as much scrutiny. However, we definitely want to have the most accuracy we can, with as little operator intervention as possible.
 
In the scenario where multiple boxes are queued on the conveyor (doesn't happen that often, usually only when machine 2 breaks), then we have likely lost the logs' ejected quantity from machine 1, so we again just use the average. Again, this doesn't happen very often so the count is not usually affected much by this scenario.
Since there can be multiple boxes between the 2 machines, I would lean toward using a FIFO instead of a plain ol' counter. Then you can keep track of the quantities of all boxes in the queue.

🍻

-Eric
 
Since there can be multiple boxes between the 2 machines, I would lean toward using a FIFO instead of a plain ol' counter. Then you can keep track of the quantities of all boxes in the queue.

🍻

-Eric

This. I have never had any luck using simple counters on conveyors. After my first couple conveyors (or equivalents) I just use a FIFO every time I have a conveyor in a machine. If I have multiple conveyors at different places in the machine, then I have one FIFO for each.

It's as close to foolproof as you can get, but remember the fools can ALWAYS think of things you can't even imagine!
 

Similar Topics

Hi, I have some batch files to run on a PanelView via the Program Launcher ActiveX. Those batch files use the inbuilt FTP client to pull files...
Replies
0
Views
681
Does anyone else toggle bits, or increment words as a messaging technique? To start a sequence or process I will hold a bit true (To avoid...
Replies
6
Views
1,703
I'm having some difficulty with the Handshake between the PLC and the Fanuc Palletizing Robot (M410ic/185 with a R30iB Plus). DO32 turns on and...
Replies
2
Views
2,074
Hiya, Currently at a customer and they requested me to setup a handshake between the SCADA Server running WW Historian and the PLC since its in a...
Replies
0
Views
1,669
Hello Everyone, Can you guys please clear the concept of handshaking between PLC and Robots? Let's assume very common example A factory has a...
Replies
6
Views
4,942
Back
Top Bottom