Triggering on passing positions in a CK3C AX1100 (Power PMAC Clipper)

[HJTrost]

I am trying to get triggering on hardware position converted from Turbo PMAC to Power PMAC.

On Turbo PMAC I use the 24-bit full encoder counts registers M108 or M208.  This gives me a range of 16,000,000+ encoder counts, sufficient for 300 mm of counts at 0.1 micron/count.  I do not bother with the fractional counts in M188 and M288.

Now, if I understand the Power PMAC User Manual correctly, I have to put my trigger position into Gate3[0].Chan[j].CompA in units of 1/4096 encoder counts and am thus limited to just over 1,000,000 full encoder counts range (20 bits rather than Turbo's 24).  So I essentially write

CompA = (myTrigPosition + HomeOffset) * 4096 ;

and take a run of the respective motion stage to see the trigger light up.  On the Turbo PMAC the equivalent (no 4096, of course) works.  On the Power PMAC, I do not see any triggers - I have put CompA into my watch window in Power PMAC IDE, and I know that the value of myTrigPosition is valid and within my motion range for the trigger run.  HomeOffset stands for M173 or M273 on Turbo PMAC and Motor[x].HomePos on Power PMAC.

There is one oddity in my programs: When I am moving about without triggering, CompA and CompB are set to 8,000,000 on the Turbo PMAC and (because I thought initially that the Power PMAC gives me *more* range) 80,000,000 on the Power PMAC; the autoincrement is always 0.  I don't touch CompB any further.  When triggering, I preload the first sensible value into CompA and then start the move.  Once a trigger shows up in Gate3[0].Chan[j].Equ, I clear the trigger in software with EquWrite = $1 and set the next value in CompA.

Where am I losing it on the Power PMAC?  How do I accommodate my 3,000,000 encoder counts on the Power PMAC?  I'd absolutely hate to have to throw virtual motors in there with scaled virtual encoders (e.g., virtual = real / 4096, which would give me 32 bits of full encoder counts).

Hans-Jochen Trost

 

[steve.milici]

The act of writing to the CompA element automatically enables auto-incrementing on the next compare event. The act of writing to the EquWrite element automatically disables auto-incrementing on the next compare event (but it is enabled on subsequent events). This could be your issue.

 

See the “Power PMAC User’s Manual” in the section “Hardware Position-Compare Functions” starting on page 780. Specifically see the section “Setup on a PMAC3-Style IC” starting on page 783.

[HJTrost]

I have looked through those passages before, and I've looked again.  I just don't recognize the answer there.  My trigger strategy goes like this:

Load first trigger point into CompA.

Start the move of the stage.

When Equ has turned on, load the next trigger point into CompA.

Clear the old trigger by writing to EquWrite.

When Equ has turned on, load the next trigger point into CompA.

Clear the old trigger by writing to EquWrite.

Here is the core of my program code:

Open plc TriggerPlc
If (Gate3[0].Chan[1].Equ == 1)
{
    TrigPtr=TrigPtr+1 ;   //Increment Pointer.
    If (TrigPtr == 60000)
    {
        TrigPtr=0 ;
              DataLap=False ;
    }
    PReadPtr=(3000+TrigPtr) ;
    Gate3[0].Chan[1].CompA=(P(PReadPtr)+Motor2.HomePos)*4096 ;
    Gate3[0].Chan[1].EquWrite=$1 ;    //Clear old Trigger.
}
Close

I have no use for the increment, it is left at its default, which should be zero.  I have no use for CompB either, which I set to an out-of-range-of-interest position (8,000,000 for the Turbo PMAC, currently 80,000,000 for the CK3C).  I don't see what keeps me from getting trigger output signals.

[steve.milici]

I think your “scaling” is off.

Note that since Gate3[i].Chan[j].ServoCapt, has 8 bits of fraction, it has units of 1/256 of a count. The “CompA” and “CompB” registers are in 1/4096 of a count. The value in ServoCapt will be 16 times that of the compare registers for the same position.

Also note that writing a value of “1” to “Gate3[0].Chan[1].EquWrite” does not “clear” any trigger it just sets “Gate3[i].Chan[j].Equ = 0”. Occurrences of “Gate3[i].Chan[j].ServoCapt = Gate3[i].Chan[j].CompA/16” (or CompB) will toggle the value of “Gate3[i].Chan[j].Equ” regardless.

I don't know what your "motor" units are in.

[HJTrost]

It took me a while but I think I am finally getting a grip on this.  The cutting off of the trigger in software that I am used to from the Turbo PMAC does not work here, and I need CompA and CompB to define the pulse length.  The scaling with 4096 is correct.  My motor units are quadrature encoder counts.  So my trigger update looks like this:

    Gate3[0].Chan[1].CompA=(P(PReadPtr)+Motor[1].HomePos)*4096 ;
    Gate3[0].Chan[1].CompB=(P(PReadPtr)+50+Motor[1].HomePos)*4096 ;
    Gate3[0].Chan[1].EquWrite=$1 ;    //Clear old Trigger.

Here I have previously set Gate3[0].Chan[1].Equ1Ena=1 to get the x axis triggers on the EQU2 output line.  I can flip Equ1Ena on the fly and thereby accommodate curved motions, in which triggering in the x-y plane uses the larger of the x and y projections.

My problem now is that the hardware pulses do not show up on the EQU2 line, pin 18 of the JMACH2 port of the CK3C.  I have yet to take an oscilloscope to it for a close look.  But as there is no user manual for the CK3C yet, I'd like to know if that output pulse still is supposed to be a TTL pulse of 5 V amplitude.  I also need to know what happens when the motor counts in .CompA and .CompB roll over as they will on my 300 mm long motion stages with 0.1 micron quadrature counts.

[Alex Anikstein]

I've flagged to the web team that the CK3C manual seems to have been missed--it does exist, though.

That said, the EQU signal on the CK3C should not be different from any other Power PMAC--it is still 5V TTL, and the Gate3 itself should handle the rollover.

CK3C User's Manual.pdf

[steve.milici]

Note that “Chan[1]” would be associated with the second channel on the Power Clipper (and second channel encoder). That would use the EQU1 output (correctly on pin 18 of J4). The channel index has a range of 0 to 3, corresponding to hardware channel numbers 1 to 4, respectively.

[HJTrost]

Yes, that is intentional.  By flipping Equ1Ena, using Chan[1] allows me to change the axis selection for the triggering on the fly.  A working pair of programs is attached, updated slightly from my previous inline quotes.  Setting Gate3[0].Chan[1].Equ1Ana=0 and using Motor[2] instead of Motor[1] converts this from the x axis to the y axis.  This is what we did with the Turbos.  "Working program" means I get the state changes of Equ and EquOut in software and count the correct number of trigger pulses (counter p793).  The CK3C still does not give me the TTL pulses.

TestTrig.pmc TriggerTestPlc.plc

[HJTrost]

Progress!

Reordering the code by writing to EquWrite first and CompA and CompB thereafter makes the electric trigger pulses appear.

Gate3[0].Chan[1].EquWrite=$1;    // clear output signal
Gate3[0].Chan[1].CompA=(P(P606)+Motor[1].HomePos)*P2999;
Gate3[0].Chan[1].CompB=(P(P606)+P611+Motor[1].HomePos)*P2999;

So the enabling of the autoincrement operation does actually more than that as my CompAdd is at default, i.e., 0.

That leaves the 300 mm in 0.1 micro steps encoder issue.  I'll open a new thread for that one.