Multi-servo product metering

kamenges - Unfortunately, that isn't an option, no matter how much I may value my time. Not only is this in a plant for a large company with an Allen-Bradley spec, I wasn't brought in to the project until after the hardware was selected, and we are now well beyond going back unless there is no other option.

MichaelG - I'm seeing a lot about using MAM while MAG is enabled, but I'm not seeing where MAPC can be used while MAG is enabled. Are you sure you didn't use MAPC to do the gearing, and then merge into a "phasing" MAPC command?
 
Is there a way to scale the length of the cam table to you can use the same cam table but scale it to move different distances?

BTW, what would happen if you change the scale while executing the cam?

Yes - The CAM has Master scaling and Slave Scaling so you could use a unit CAM table then go from there - I do not, as I find that I want real units for jerk and accel, so I set up the CAM table with the master distance correct, slave distance at maximum and force the slave scaling to always be less than 1 - slave scaling of 0 is permitted

Change scale while executing - not possible, MAPC is executed and the next CAM is blocked (MAPC instruction will error) until this CAM has finished, (Note you can perform a pending MAPC while the current Cam is operating which adds onto the end of the current cam)
 
MichaelG - I'm seeing a lot about using MAM while MAG is enabled, but I'm not seeing where MAPC can be used while MAG is enabled. Are you sure you didn't use MAPC to do the gearing, and then merge into a "phasing" MAPC command?

Want to test it out?
Create a base project with 2 Virtual Axis - use rslogix emulator (no CPU needed)
Play


MAG, MAPC, MAJ and MAM (relative and master move only make sense) can all be running at the same time on the same axis
It is NOT possible to have 2 MAPC or MAG active on the same axis at the same time (there is a method to get this to occur but requires the use of a virtual axis in the middle that uses MAG to the final axis)

however (for peter) all the actions are summed so it is possible for the total accel or Velocity to exceed the axis limits - a proper motion controller would look after this correctly
 
Originally posted by JRoss:

Not only is this in a plant for a large company with an Allen-Bradley spec,...

Yea, I know. The customer is always right, especially when he is wrong.

Assuming products are coming at you slowly (that is "infrequently") enough that you can do it I would use MichaelG's method. I suspect in your case they are. The cam implementation requires an additional scan (or so) to get the table calculated and loaded.

I'm not as concerned with using the MAM as Peter is. It's not like you are moving a drill head with a bit buried in a log. The move you are making is required to put one package in the correct location relative to another. That distance is that distance. Whether that move occurs with all the other packages stopped is immaterial. That displacement still needs to occur. But if you like the motion flexibility of the cam then that would work too.

I agree that AB should have the ability to do something similar to a phasing move. It would be a nice bridge between a cam and a time based point-to-point move. Tell your customer you are getting you @$$ kicked by the AB motion instruction set. If your big customer is big enough we might all benefit.

Keith
 
however (for peter) all the actions are summed so it is possible for the total accel or Velocity to exceed the axis limits - a proper motion controller would look after this correctly
This is impossible to do in all cases. There speed of the line can change after the command is issued. It is possible to check to see if the desired speeds are exceeded each scan but not when the command is given. If the master lines speed suddenly increases the superimposed move may be too fast.

We have different ways of handling this but none is perfect for all situations. One method will simply make sure the phasing gets done no matter what. It is possible to exceed the speed and acceleration limits but the slave and master target positions will be phased correctly. You just have to hope the actual velocity and acceleration will catch up. The second method does limit the velocity and acceleration but if the master line speeds up there is no guarantee the slave will be able to keep up with the limits imposed. The slave may never get to the right position when the master moves its phasing distance. It is an option that the user has but it takes some thought. There is no perfect solution.

BTW, we can change cam tables on-the-fly, but a fault will occur unless a transition command is given that determines how the target will move from would cam to the next.
 
I think it will work on this different application, but I don't know, so I'd like more information about the way you are using camming. If you would be willing to actually share your code, that would be fantastic!
Code is not share able - however concepts are and questions are answerable
One other question: how did you have the wrapper tied in to the phasing belts? Were they controlled by the same PLC, or did you have an encoder on the flighted conveyor, or some other means?

My Wrapper was a sectional servo system on the same CPU so no issue
If your flighted conveyor is a different system then highly recommend huge count encoder per flight - Peter has discussed this at length in other posts
 
product phasing.jpg

Is this a sketch of your situation ?

Conveyor 1 is on the left conveyor 5 feeding the flight

PE's also count from the left

I have Conv 1 to 5 all using MAG to a virtual axis (virtual flight axis)
The virtual axis has a virtual phase mark that conv 1 to 5 get the product to match up to
I then let the operators set the phasing of the virtual to the flight - different product sizes and placement on the flights
 
That's basically it, though the conveyor sizes are different. I have an infeed conveyor that will provide product at a constant speed to the first servo conveyor. I'm thinking that I will set the speeds/gearing, so that I always pull a gap on the first conveyor. Servo conveyors 1-3 are 16" long. Servo Conveyors 4-5 are 12" long. Servo Conveyor 6 is longer (60"?) with a slot in the middle for the wrappers flighted conveyor to mate to. The wrapper and infeed are on different PLCs. The guy who picked the hardware planned on transmitting the master conveyor position over Ethernet, but I don't think that will be fast enough for the higher speeds. I am recommending an encoder attached to the flighted conveyor, and it sounds like that's the consensus here as well. Fortunately, I can use the aux encoder port on the Kinetix, so the cost to add the encoder is relatively low, so it shouldn't be a hard sell.

I'm still conceptualizing how to do the camming, as I've only done camming on one other project, and didn't use scaling at all. Here's roughly what I think needs to happen on each conveyor 1-5. Please comment!

1.Smoothing cam profile is set up with Master and Slave positions 1:1 from 0.0 to pitch length.
2.Sensor (where should this be on the conveyor?) detects leading edge of product and calculates how far forward it needs to move to be in phase. This is divided by the pitch to give a percentage.
3.Percentage from previous step becomes slave ratio in MAPC instruction, and instruction executes to move product forward into position.
4.Camming is stopped when cam profile is complete or product leaves belt (second sensor?).

Obviously, I'll need to make sure I don't advance the product into the back of the previous stack. How does that sound?
 
Transferring speeds over Ethernet isn't a good solution.
Usually I recommend slowing down the upstream lines but if you can make the upstream line the master and advance the phase of the down stream lines but like you say, you can bump into items on the wrapper.

I think your plan can work but I would rather let the destination be the master instead of the source for reasons you explained. What happens if a down line conveyor stalls? Then you need to add extra code to stop the upstream lines.

Phasing should be this easy.
http://deltamotion.com/peter/Videos/Phasing.mp4
 
Looks ok - what is the length of the product?
If the 1st conveyor is stopped /slowed can the product accumulate upstream for a short time up to 1/5 of the product - it can make phasing easier


Ethernet from what? if RSLogix PLC then the update rate would be at best about 2ms - still to slow
Also Motion wants a MASTER axis for the gearing reporting position - it then calculates its speed and accel (I do not know the method used but I know that we cannot access it)
The slave axis in a Gear then uses this information to work out its position

The second encoder is definitely best in this case


Gearing Ratios - I found that the final conveyor needed to be running about 10% to 15% faster than the flight conveyor
Maths for ratio length of flight + flight turning distance : flight distance

I do not use pitch for units - it is harder for you to think in - use whatever length units you are familiar with (mm for me, inch for you?) let the first gear ratio change pitch to inch

CAM must be complete before the next product gets to the sensor and you no longer have control of the product (it has begun to move onto the next belt)

CAM profile for MAPC - we will keep it simple continuous accel - once working you can improve it later
Unit CAM which you need to scale before use

0 0 Cubic
0.25 1/12 Cubic
0.5 0.5 Cubic
0.75 11/12 Cubic
1 1


Master is distance to move in
Slave is maximum distance that you will phase change in any move
 
Sorry guys, I was on a startup this week, and didn't have much discretionary time...

MichaelG, that's fantastic information, and should get me going. Here are some answers:

Length of product varies between 2.5" and 3.5" depending on the variety. The pitch is 6.5". I do plan to have my units be in inches. I can translate between SAE and metric fairly well, but having been fed SAE since an early age means that's it's still a translation. I don't dream in metric yet...

My last servo conveyor is essentially my flighted conveyor. It's a split-belt conveyor that will mate onto a third party wrapper, with the wrapper's flights fitting between the split belt. So my last metering belt will be servo conveyor number 5. I think that's why the guys sizing the system didn't put in a master encoder. They figured that the final servo belt would be speed matched to the flights and act as the master for the metering belts. I would still need to monitor and adjust for drift, which may be possible over Ethernet, but I'm still a little concerned about lag.
 

Similar Topics

This is a question for anybody out there who has an in depth understanding of AC motors and how they work with VFDs, particularly in a...
Replies
16
Views
3,880
I have an application that allows an operator to jog a servo forward or reverse, slow or fast speed with push buttons. As I understand the MAJ...
Replies
3
Views
2,839
Hello, I had a question about benchmarking the Rockwell FactoryTalk View SE software. I've installed in the neighborhood of 30 different...
Replies
2
Views
279
Hello, I'm trying to test Acopos multi using Automation Studio. Ready LED is green blinking, how can i know what error of Acopos on Automation...
Replies
1
Views
131
Good Afternoon , I'm sure there are many Ishida Muti-Head Weigh Systems . We have a Ishida CCW-M-214W Multi-Head system . We are...
Replies
1
Views
533
Back
Top Bottom