Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Dock on June 25, 2013, 03:43:53 PM
-
Hi all, asking for a little help here.
I have been using the AD processors for some time now but am new to the DO MORE and some of the more complex programming functions.
Anyways I have experience with mostly discrete, and straight forward programs. I have a project now that is challenging me and I am looking for a little help from the Brain Trust.
I will try and describe the best I can to see if any of you have any ideas.
I have an application with a small recycling line and am having a little trouble with a bin queue.
DOO:
Operator picks a bin off of an incoming stack and places it on a load conveyor section. The operator then assigns a destination via an HMI (1,2,or 3 based on bin contents), after the destination assignment the bin advances one zone into a queue (there are four zones in the queue). When the queue reaches the last zone the bin is then sent down the line to be transferred off the main line via a right angle transfer. After the bin has been transferred the next bin in the queue is then sent down the line, transferring off the main line based on the destination assigned by the operator.
What I'm struggling with is trying to find a way for the PLC to execute the destination assignments in order. Example bin 1 goes to dest 2, send to queue. bin 2 goes to dest 3, send to queue. bin 3 goes to dest 1, send to queue. Bin 4 goes to dest 2, send to queue. Bin 1 has now landed at the last zone in the queue and now needs to be sent down the line to be transferred but it needs to know where to go and so does the one behind it and so on....
Clear as mud?
Any help on this would be much appreciated!
By the way HOST the new stage programming is really NICE!
Thanks,
-
Are you using barcodes on the bins with strategically placed barcode readers to know what bin is where?
OR just simple prox switches and so the PLC must "maintain" the position logically (what happens if someone manually removes a bin, or moves a bin? that could create confusion in the logic)?
OR combination of both
OR no feedback at all, because the system is mechanically simple and you can safely assume that all steps are executed properly
OR ? ? ?
-
There are lots of ways to do it, but, one way that may get you started:
Create a user unsigned byte block called "BIN" with a length of at least the maximum number of bins that could be on the conveyors at once (my understanding of your post suggests 4).
Whenever the operator places a bin on the line and presses the destination button, then load the destination number into BIN[0].
When that bin reaches the queue then perform a MOVER (MOVE Range), Source: BIN0, Destination: BIN1, Length: 3.
Now you can examine the contents of BIN3 and whatever number is in it tells you where to send the bin coming out of the queue.
Clearer? or muddier? ;D
-
Are you using barcodes on the bins with strategically placed barcode readers to know what bin is where?
OR just simple prox switches and so the PLC must "maintain" the position logically (what happens if someone manually removes a bin, or moves a bin? that could create confusion in the logic)?
OR combination of both
OR no feedback at all, because the system is mechanically simple and you can safely assume that all steps are executed properly
OR ? ? ?
No barcodes, the bins are used throughout the facility for other tasks and processes, that would be to easy!
The PLC must maintain its state throughout the sequences. They are aware of the issues if they had to remove a bin and start over. The line is not that big and mechanically simple, the probability of jams is low. So, yes it is an issue however one that I don't believe will be much of a problem, famous last words right?
The bin will be transferred when it reaches its destination (assigned by the operator at the HMI) so the PLC must maintain this memory until it arrives at its assigned destination, triggered by a Photoeye, then transferred. There is feedback after the transfer to make sure the product has arrived at its destination, which would signal the next one in queue to go down the line, again with a memory destination.
This is all because of timing, the operator can send bins and they can travel faster than the workers can process them. The reason for the queue is to allow the loading operator to load several bins at once without having to wait for whats happening downstream and be completing other related tasks as well... Also the fact that we have no other intelligent means of identifying where it needs to go (barcode).
-
There are lots of ways to do it, but, one way that may get you started:
Create a user unsigned byte block called "BIN" with a length of at least the maximum number of bins that could be on the conveyors at once (my understanding of your post suggests 4).
Whenever the operator places a bin on the line and presses the destination button, then load the destination number into BIN[0].
When that bin reaches the queue then perform a MOVER (MOVE Range), Source: BIN0, Destination: BIN1, Length: 3.
Now you can examine the contents of BIN3 and whatever number is in it tells you where to send the bin coming out of the queue.
Clearer? or muddier? ;D
Slightly clearer but still muddy, I think I could figure out the move instructions but im lost with the "Byte Block", care to elaborate on that? Again, I have never had to do much with the advanced programming and have no one here to really turn to for advice..
See if im on the right track with this but Im probably moving backwards!
Create a memory block with a least 4 destinations....
Input the memory block with a numeric via the hmi...
MOVE the numeric to a specific destination
Examine the numeric
Execute the task based on the numeric...
Not sure if im on track or not, probably way off. How would the memory block create a stack or execute them in the order they were input?
I was not at my desk today to try and play with what you suggested but will be there to give it a try tomorrow.
Thanks Fellas,
-
Ok so I didn't get much time on this today but I believe I figured out how to create the byte block. More tomorrow.
-
I think a picture here would help a lot, regarding data transfer. Picture the block of memory like the line. Create a block four elements long, assuming you have four stations.
B0 B1 B2 B3
--------------------------
| | | | |
| | | | |
| | | | |
--------------------------
Each memory address corresponds to a station. The value in the memory location is the ultimate destination of the bin. So, first bin is queued in the first station with a destination of, say, 3. Load the destination into B0:
B0 B1 B2 B3
--------------------------
| | | | |
| 3 | | | |
| | | | |
--------------------------
Next bin approaches. Operator sez it goes to two. MOVER B0 to B1 length 3. Then set B0 to the destination, 2:
B0 B1 B2 B3
--------------------------
| | | | |
| 2 | 3 | | |
| | | | |
--------------------------
Eventually you get a full stack, and the sequence will be:
Send bin to main line with destination B3 (station destination address in memory location B3)
MOVER B0 --> B1
Set B0 = selected destination.
To account for startup, you might initialize the memory block with zeroes. Then:
B[0-4]=0
While not error condition:
If B3 > 0 && B3 < 4:
Send bin to B3 destination
Elif B3 = 0:
No bin in position
Else:
Invalid destination error
MOVER B0 --> B1
If operator select:
B0 = selection
Else:
B0 = 0
End While
I'll leave translating the above pseudocode into efficient ladder logic to the experts.
-
CReese,
Thanks for the illustration, that helps. I think I have an understanding of how the user assigned destinations are inputted into memory, and I believe I have created the memory block correctly. Now I just need to figure out how to apply this data to the memory block via the HMI. From what I have read I need to use a read or write instruction to apply the data to the memory block. I have seen several read/write instructions available and need to try and figure out which one to use.
So far I believe I need the MRX instruction to read the user inputted data via Ethernet. I have created a new device called "HMI" to communicate with the instruction via MODBUS/TCP. I set the IP address in the instruction as the IP address of the controller. This is as far as I have gotten, am I on the right track? :-\
If I am now I need to figure out how to associate the memory block I created with the instruction?
-
Typically, the HMI is the "Master" and the Do-more is the "slave", hence no need for the Do-more to use MRX which is a Modbus Master instruction. Do-more as a slave is a passive operation, so there are no instructions to make the HMI work.
Are you using C-more? If so, it has a Do-more driver (no need to use Modbus). If not, whatever HMI you have, if it has Modbus driver, that will work just fine.
However, user created data blocks are not accessible via C-more, so you will still have to move the data from V or N (built-in blocks) into your B data block. The MOVER or SUBSCRIB can do that. If Modbus, your HMI will be writing to MHR data-block. Again, use MOVER or SUBSCRIB to move data from MHR data block into your B data block. If you need to READ Do-more values from your HMI, use MOVER or PUBLISH to write to M* data-blocks (MI, MC, MIR, MHR: Modbus (Discrete) Input, Modbus Coil, Modbus Input Register, Modbus Holding Register).
-
Thanks for the Reply! This keeps me from going down the wrong road!
Yes I am using a cmore panel, I will play with your advice and let you know what I come up with.
Thanks,
-
Try this:
In the Cmore create a push-button referencing C0 for example, set it up as a Set-bit.
Then in the DoMore have a rung with STR C0, RST C0, MOVE, Source: 1, Destination: BIN0.
Now copy this process for the other three destinations, ie: C1 MOVE 2, C2 MOVE 3, C3 MOVE 4.
...I'll try to make it easy... see the attached screenshots:
-
So I think I have the move and mover under control. Now the question is how do I examine the contents of the byte block and apply that with the ladder logic to trigger a stage? Is there a way to map the contents of the block to C bits for program control? This project is making me go bald with all the head scratching, but im learning!
-
See the attached screenshot.
It will set C10 for divert to 1, C11 for divert to 2 etc.
If the number is out of range it will set C20
-
Added a contact to the rung:
-
Thank you! This worked well. Now I just have to figure out how this will work if say two or more of the SAME destination assignments are made in a row...
-
You need to have a supervisory program (preferably in stage), and from S0, you can monitor C10 to JMP to S10(RST C10 on this same rung). In S10 you can RUN your program that controls destination 1, then monitor the .done for that program to JMP back to S0.
Do the same for the other 3 destinations from S0, and also place a S0 contact on each of the rungs that has a JMP so that only one destination can be triggered at a time.
In won't matter which order the destinations come in, it will always do the right thing.
-
After the command is executed (move to bin location), the bin execute bit is reset and the program returns to the initial stage.
-
Well its good and not so good so far. :-\
I wrote the supervisory program and I can get the memory block to shift the bin locations throughout the stages as PLC Nut described, but I'm still having trouble getting the program to output TWO or more of the same bin destinations in a row.
Example: If I input bin1,bin3,bin2, it works fine as long as there are none that repeat in the same order. I have problems when I try and do bin2, bin1, bin1,. When two are the same back to back it seems to not execute the second destination.
I assume this is a function of the C10 bit resetting at the same time it jumps to the S10 stage. I have yet to figure out a way to execute or move the same destination back to back, before the S10 is complete or the program is .DONE
I attached the MOVER inst. if someone would take a look and see if this is correct.
-
Don't worry about doing it in stage. Just maintain a shift register (your BIN0-BIN3 list of destinations). Push the new value into the queue on whatever one-shot condition indicates the addition of a new bin. Operator presses C-More button or whatever.
How does the system work physically? Is it the addition of a new bin that sends #3 down the conveyor? Request for the next bin from the downstream side? In any case, model that condition with some kind of one-shot logic for releasing the next bin.
Then you have to take care of things like making sure you don't allow the operator to claim he's added another when the queue is full, verify with photos that the correct number of bins are present (if available), deal with edge cases like filling partial queue, and so on.
-
The delta contact is what is holding you up.
MOVE 0 into BIN3 at the same time that you RST the C10(through C13) Bit(s).
This way each time the system completes a bin transfer and comes back to check the queue, IF there is a bin there, your system will always see a change in BIN3.
-
Well I think I'm getting there. My main problem was the MOVER, I should have spent more time trying to understand this instruction in the beginning and I would have been much better off. I figured out a way to MOVER the bin positions one at a time based on the introduction on new bins, I triggered the MOVER by the positions of the bins on the loading conveyor. This seemed to work well for the instance in where you had two or more of the same destinations in a row.
I love the sub programs and stage this is making my life MUCH easier, I couldn't imagine trying to do this in one MAIN program.
So now I have more questions. ;D Can someone explain how much the programs effect scan time? How many before the main will lag? Too many variables to give an answer? I need to read into the Yielding more to make sure I understand that aspect of the programs...
Were on the runway getting ready to throttle up but we're not flying yet! Will update.
Thanks everyone for your help so far!
-
What do you
require allow for a maximum scan time? If it's not an issue, I would never write logic for "minimizing scan time", but for "maximizing understandability". If it IS an issue, THEN worry about the SPECIFIC bottle necks, but only the bottle necks (and document them well).
-
Well the system is running for the time being. Projects are stacked up for the moment, when I get a little free time here soon I will update you all on my thoughts since this was my first project with DoMOre. :)
Thanks again for all who helped and provided input.