MAOC Flexibility

I'm rewriting an older process that essentially uses a feedback only axis encoder to drive 8 CAM outputs. Not physical outputs, but internal outputs that in turn operate 8 real Kinetix axes through MAM's.

There is also a calibration mode where the physical encoder doesn't operate (machine not running), but instead uses a virtual axis.

Then there are multiple recipes that define the turn on/off points of the CAM depending on what product is being ran.

The previous programmer has multiple MAOC's, for each mode (run vs calibrate) and for each recipe. I don't see any inherent problem in condensing all of this to 1 MAOC? Because right now there are CAM tags and Compensation tags for each combination (recipe and mode) and it clutters up the logic significantly. There's multiple branch and interlocks as to which MAOC output to look at depending on conditions.

I propose to use one MAOC with a virtual axis geared to either the real encoder or the virtual calibrate axis. Two MAGs would be used based on which mode. And then simple COP instructions to copy all the various recipes with the output profile and compensation profile into the single MAOC instruction tags. That way, the setup of the MAOC is guaranteed to be the same between online and calibration mode which is important.

Is there anything I'm missing that would render this not a good idea? It would greatly simplify the number of motion instructions and tag arrays that are used, and eliminate the possibility of the calibration MAOC being slightly different than the online MAOC as we would always use the same Recipe and Output compensator source tag.

Not sure if anyone is interested, but the above methodology worked fine. Now the speed compensation feature of the MAOC im finding is very restrictive, if not almost unusable. If there's anyone out there that's had success with speed comp on an MAOC, would love to get some insight. The issue is that speed comp uses a time base to calculate an internal position offset on top of the latch/unlatch positions. Works fine unless the speed comp offset pushes the latch before 0 or the unlatch past the cam reset limit. Then it either doesn't fire the output at all, or it truncates the output against the cam limit. Kind of useless as you have to insure your cam pattern is well within the limits of the Cam limits, accounting for whatever maximum speed you may achieve ahead of time. I was hoping speed com was going to be a time base adder and it would ignore the cam limits.