merge program

Do any of you guys have a merge program you could show me? Like when 2 conveyors join one and it speeds and slows each depending on placement and makes on lane out of them. I have one but am interested in seeing how others do it, because once in awhile it will mess up out of nowhere and merge 2 product together. Eyes are all good and machine is fairly new so I dont know about the problem has alot of MAM functions which I dont understand and would like to see a educational topic on this type of thing.

thanks alot
-Newbie

not one person?

This is a pretty generic request and I would guess that while merges are common, the implementation could be quite specific to the installation, specifically actuators and sensors used.

Also, I don't know what a MAM function is. Maybe it's specific to what processor you are using.

MAM is used for an Axis in motion on the AB CLX line. MAM is the Motion Axis Move command, and it can be absolute, linear relative, angular, etc.

Now the merge function is completely different. Say you have a MAM instruction going, which is an auto move on a crane, and the operator presses the manual joystick. Obviously, the operator control should take priority. The command for jog is MAJ, Motion Axis Jog.

However, if you're running at 3 m/S and your operator joystick is commanding a move at 4 m/S, you want to MERGE the 2 motions together, and start accel from 3 m/S to 4 m/S, rather then starting the accel profile from scratch.

I'll attach 2 RS5000 files from the Rockwell Knowledge base that use motion.

I did a project like that once, but I didn't use a plc. The conveyor came with a proprietary logic system and I just had to figure out how it worked. Anyway, the secret to my application was to make one conveyor have the right of way. In other words, conveyor 2 could not go unless conveyor 1 was clear; then if conveyor 2 did run then conveyor 1 had to wait. Conveyor 1 had the right of way since a large portion of it had to be clear before allowing conveyor 2.

This help?

"Right of way" can suck... in some conditions. Think of you sitting at a Stop Sign on a main highway.

I don't have a process fitting the particular case.

However, I'm willing to discuss the concept... it is, after all, simply a control problem.

So... you have two conveyor lines converging... apparently the items on the conveyors are spaced rather haphazardly.

Both lines come together at a particular point.

The speed of each line is controlled so as to ensure that the items from each line interlace without trying to place two items in the same space on the out-going conveyor.

So... let's try to visualize this...

Conveyor-A is of such-n-such length... it can hold X-items, tightly packed.
Conveyor-B is of such-n-such length... it can hold Y-items, tightly packed.

I have no reason to believe that the conveyors are the same length.

An initial stab at it involves a shift register for each conveyor.
Also, there is an encoder that tracks the relative position of the conveyor.
The "position-value" varies according to the speed of the conveyor. Hang on... there's a twist to this...

Looking at Conveyor-A, each item loaded onto Conveyor-A is "registered" with the current conveyor position according to the associated encoder position-count. At some point, the position-count is reset to... Maximum! This means, each subsequent pulse from the encoder causes a subtraction on the current position-count. In other words, the position-count works downward from maximum towards zero.

The same applies to Conveyor-B. This means that both conveyors are converging toward "zero".

Also, as each item is added to one conveyor, or the other, a counter is incremented to indicate the number of items on the particular conveyor. As an item leaves the conveyor, the count is decremented.

Also... the "registration" of the leading item, on each conveyor, is maintained in separate variables.

As a leading item of one conveyor is converged onto the out-going conveyor, the registration associated with that item is over-written by the registration of the following item on that conveyor.

So... you always have a positional relationship between the two leading items, as well as a total item-count on each conveyor.

Now... a critical consideration...

If one line is full and the other line has only one newly entered item, you might tend to let the full line run for the majority of the time...

However... unless there is a jam at the convergence point, both conveyors must run at some minimum speed. This is to ensure that the next item loaded onto a conveyor has room to be loaded. If either conveyor is stopped, for whatever reason, that conveyor can not accept new items.

Because of this, the conveyors must run at some minimum speed. That minimum speed is dependent upon the feed-rate from the source (manual or automated). Unless there is a way to regulate the source.

That means, the speeds of the conveyors can vary between that minimum speed and some maximum speed.

While the conveyors are moving, the encoder based current-position, logged into the shift-register for each conveyor, has to proceed forward with each new item entered onto the particular conveyor.

Now... the MGD-effect is starting to occur...

So... I'm done doing this head-bending for now.

The deal is... the speed of the conveyors is controlled by the position-count of the leading item, the total count of items on the conveyors, recognizing the minimum speed...

Gotta stop... Damn! I love MGD!

But I gotta say... this is a FUN problem!

Amazing what google will turn up.

http://www.cba.uc.edu/faculty/keltonwd/Paper-MergingConveyors.pdf

A little more on this set up. Basically we are cutting an item and we have 2 feet one after the other one goes to one conveyor one to the other. Then about 7-8 feet later they hit the merge. So as you see the items come 1-1 not really at random. The only randomness is how long it takes for them to begin getting pulled by their respective conveyor. Hope this helps