How does the position target get loaded with CTAXDYNP? Is it only updated during the PLC scan as opposed to getting a master encoder value directly from the quadrature input? I have to admit that finding something I saw a second time is a little difficult in Help.
Specify a variable for the target position in CTAXDYNP, enable the CTAXDYNP instruction, set the .GotoPosition bit in the associated structure from code. With CYAXDYNP, you can feed it a new position every other scan or so.
CTRUNPOS looks like it can follow a quad encoder directly with Trapezoid Plus or Trapezoid with Limits, but... I need to be able to adjust the scale on the fly and I don't think that can happen.
A little deeper look. If I set the CTAXDYNP Target Position to a Quad Input that should also follow. Pointing to a scaled CTRIO2 input should also work. But neither of these is going to allow changing the ratio on the fly, much less reversing.
The profiles that have encoder inputs are not followers in the sense that you are wanting, they are simply using the encoder as the position instead of the accumulated stepper pulse count, and the specified move is performed in encoder units instead of stepper units. The stepper is still the driving element, and the scale factor there is the ratio between encoder and the stepper.
In your case, you would be creating your own linkage between the two different axis mathematically, therefore the scale ratio between the two is up to the math that you choose.
In dynamic position mode, the axis reverses automatically when you specify a position behind the current position. There is nothing for you to do.
So I am going to need to massage the encoder input in ladder and set the target position each scan, correct?
The servo we are looking to use allows smoothing the pulse train input without losing pulse counts and this being a traverse that should be acceptable. The servo is also not going to lose track of the rotor due to any jitter like a stepper might.
Precisely. The question is just what is the best way to do that. When you specify a target position, the module is going to constantly accel/decel as it sees fit. This is the jitter I was referring to. If the slaved side is far enough behind that effect will be mitigated to a great degree, and if the servo has some filtering that will help too. An alternative would be to control the slaved servo with velocity control and use PID. I'm reasonably certain that could work, depending on how much slop you can handle between the master and slave, but that would require a bit more math and/or tuning.
If this would work, it might be feasible to add the servo traverse with the single H2-CTRIO2 we will already be using anyway.
With all that said, I don't want or need any surprises. I wish I had a CTRIO2 on hand to experiment with.
Then again, I don't have a servo to hand either. 
And that is my only concern. I *think* it could be made to work, but that depends on a large number of variables that I don't have answers for. We'd like to add a follower mode to a future product, just aren't quite there yet.
When are we going to see the CTRIO/2 simulator module?

That'd certainly be nice, and you're not the first to ask. Right this moment we are peddling the bike as fast as we can on the development of the new Do-more platform...