BRX AXCAM master axis

[kgallagher]

Hoping to understand what is going on behind the scenes with the AXCAM instruction a little better.. I have a servo axis that I am trying to run a cam based off of an external encoder signal. Servo axis is ax1 on an HSIO4 module, and the master encoder is ax2. While offline testing I set up axis 0 to make the same move as the master encoder. Camming worked great. However, switching the master source to the external encoder causes the cam to not run correctly. Verified the virtual axis and the physical encoder .currentposition members make the same move, and the servo is in camming mode at the correct times. Only difference I can see is the source of the master position.

Does the AXCAM instruction use the .CurrentPosition member of the selected master axis as its master reference, or is it something different? Otherwise not sure why the same master move with the same cam table points would cause very different reactions by the servo.

[Controls Guy]

I think a lot of people intentionally use a virtual axis as the master, presumably because it will be easier and smoother to follow than the feedback from an actual axis.    I've seen a few AB motion apps done that way.

Not sure of the answer to the question you asked, but noting that you might want to consider actually using it that way.

[kgallagher]

Yeah, I've used virtual axes as camming masters in the past for that exact reason, but unfortunately this time I think I might be stuck having to use the encoder. The application is integrating the servo axis into an existing line with multiple processes tied to one main encoder.  My camming routine has to base the servo position on the current position of the line, and I don't have control over starting, stopping, or speed.

[Controls Guy]

Oh, was afraid of that.    Hopefully the Host guys will chime in!

[franji1]

The AXCAM Master needs to be  High Speed Counter input from the Encoder, not another Axis.  An Axis is probably driving what the encoder is monitoring (I'm guessing).  Configure the Encoder high speed inputs as a Counter function.  Then make that Counter's Accumulator be the Master, e.g. @HsCtrTmr1,, not $Axis1/2/3 that drives the encoder.

You configure High Speed Counters in the System Configuration dialog.  From the BRX Local I/O page, select High Speed I/O.  You see options for Axis, but also for Input Functions.  Pick one of the Input Function resources (e.g. Function 1).  Select Counter, then tie it to the specific X inputs that are wired to your encoder.

Make sure the X's are High Speed Inputs.  Not all onboard inputs are high speed (they show up in the list as HS vs. Std).  Also, make sure the filter values of your high speed inputs are good (you will be prompted).  They default to "standard" input filter values (25 Hz) since majority of PLC applications do not utilize HSIO.  Set them to at least 2x faster than what you think you need (4x?).

Make sure this Counter is behaving properly - trend $HsCtrTmr1.Acc to see it behaves similar to your virtual Axis as you actually drive the encoder.  It may be scaled differently since the Axis values is the "driving" pulses, while the encoder is the "feedback" values - there may be a different factor involved.  Regardless, if the shape and behavior appear good - just tweak the AXCAM table values to correspond to the $HsCtrTmr1.Acc master values vs. the $Axis0.CurrentPosition virtual axis values.

You may need to look at scaling the High Speed Counter/Timer - that's done in the same High Speed Counter dialog (right side).  This is done by the high speed co-processor.

[kgallagher]

Thanks for the reply. I may not have been clear enough about the setup I'm using. The axis the encoder is set up on (axis2) is configured as a virtual axis with no pulse outputs and its current position is set by encoder feedback from a High speed counter .acc value. I guess I don't really need to make the encoder input its own "axis" but comparing the axis2.currentposition (phyiscal encoder) vs axis0.currentposition (virtual master I used for testing) gives the same profile /has the same scaling.

I will try setting the master directly to the counter.acc value instead of the Axis 2, however, these should be the same in theory I believe? When I select "$HSIO_002_Axis2 (Axis 2 position)" is that using some value other than axis2.currentposition?

[franji1]

Thanks for the reply. I may not have been clear enough about the setup I'm using. The axis the encoder is set up on (axis2) is configured as a virtual axis with no pulse outputs and its current position is set by encoder feedback from a High speed counter .acc value. I guess I don't really need to make the encoder input its own "axis" but comparing the axis2.currentposition (phyiscal encoder) vs axis0.currentposition (virtual master I used for testing) gives the same profile /has the same scaling.

I will try setting the master directly to the counter.acc value instead of the Axis 2, however, these should be the same in theory I believe? When I select "$HSIO_002_Axis2 (Axis 2 position)" is that using some value other than axis2.currentposition?

I would skip Axis2.  Just make the HS Counter .Acc value be the Master of the AXCAM.  Do you need to utilize Axis2 for anything?  Not sure if that's your actual problem, but it sounds unnecessary regardless.

Again, make sure your HS Counter .Acc behavior is right.  Filters on the X inputs of your HSCtr are good.

[kgallagher]

Skipping over the Axis2 part and just using the HS Ctr.Acc  instead of the axis position as the master reference did actually fix the problem. I can see that the values of Axis2.currentposition and the HS Ctr.acc are the exact same thing, but only using the counter as the master works, not the axis position, not sure what the difference is internally to the command.

Either way, thanks for the help with this!

[franji1]

not sure what the difference is internally to the command.

The High Speed I/O functionality is implemented at the hardware level.  A virtual axis is "software" driven.

A virtual axis utilizes Image Register (IR) data values for position and velocity.  The hardware output functionality of AXCAM output must access these Image Register (IR) memory based values as inputs, which are updated synchronous to the PLC scan, MUCH slower than HSIO hardware based counter.

A hardware counter register based value is processed at super high speed, so the AXCAM functionality can access the actual hardware accumulator value (think interrupt level), not a "published" value written to IR every once-in-a-while (relatively speaking).

This is one of the reasons that there is a limitation of HSIO resources on BRX MPUs and on HSIO modules - there are physical hardware resources that must get "wired up".  Axis outputs, Counter/Timing Inputs are hardware based, so they can achieve 250 kHz or even 1 MHz on HSIO-4, MUCH faster than a typical PLC I/O scan (1 kHz).

I've always said, one person's real-time control system is another person's batch system.  PLC scans are fast.  HSIO processing is MUCH faster.