Motion cam design

I have seen many times in motion programs where camming of a slave axis to a master axis is done, that the 'startcam' begins with a 'dwell' section (slave is stationnary while master moves).
I was told this is done give all slave axes the opportunity to set into position before motion following the master is started.
Do others have experience with good practice of designing a startcam?

The shouldn't be a need for a 'dwell' section at the beginning when starting a cam profile.
I have lots of experience with cam tables. They are used all the time in curve or shape sawing sawmill machines. We also use them to linearize motion.

What is the application?

As long as you are not trying to clutch the slave to a moving master it shouldn't matter. Even then it works but has brutal dynamics.

If I need to clutch a slave I would normally cam the slave to a virtual axis. You can then chain together ramp-up, constant velocity and ramp down cams to make the virtual axis go in and out of phase with the master.

Clutching to a moving master shouldn't be a problem. It can be done smoothly without a virtual master. It just takes some mathemagic.

I also thought it isn't necessary. I assume in the step before you start the camming you always position the slave axis to the 'startposition' of the 'startcam'.
Project I am working on now is a master that is normally always moving and at more or less constant speed. The slave has to be coupled in at a specific master position if some conditions are ok. Camming goes on until a condition is not ok anymore.
Camming is done with 'startcam', 'runcam' and stopcam that are coupled after eachother. This is working fine for now.
I just asked the question about the dwell at start of the starcam because I heard about this principle couple of times, but I also doubted the need for it.

aand74 said:

I also thought it isn't necessary. I assume in the step before you start the camming you always position the slave axis to the 'startposition' of the 'startcam'.

Click to expand...

That is old technology from over 20 years ago. Things have change with floating point processors. Now the slave axis doesn't need to be on the starting point anymore.

Project I am working on now is a master that is normally always moving and at more or less constant speed. The slave has to be coupled in at a specific master position if some conditions are ok. Camming goes on until a condition is not ok anymore.

Click to expand...

This doesn't tell me what the application is.

Camming is done with 'startcam', 'runcam' and stopcam that are coupled after eachother. This is working fine for now.
I just asked the question about the dwell at start of the starcam because I heard about this principle couple of times, but I also doubted the need for it.

Click to expand...

The dwell time is not necessary if you have the right controller.

If the slave axis is not at the starting point then the motion controller generates a superimposed move to the starting point while the cam is executing. The means the slave axis will smoothly get in sync with the cam.

Look at this.
https://deltamotion.com/peter/Videos/CurveTransition.mp4
Even 20 years ago we could do this. Each board gets its own set of splines, 6 of them, or cams to cut it in the optimal way. As one set of cam tables is executing the next set is downloaded. This was done with our old RMC100.

https://deltamotion.com/peter/Videos/JAN-04%20VSS_0001.mp4


aand74, I really doubt there is nothing you are trying to do that hasn't been done before. In many cases we don't need to use cam table because the calculations can done on-the-fly. A good example if flying shears or cut-offs.