Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Gate3 Position Compare output anomalies
#1
While implementing position compare outputs on the Acc24E3 card I found a couple of issues. I was wondering if there were fixes or updates in the works for these.

First, the Pmac Users manual states that Gate3[i].Chan[j].ServoCapt should be zero at boot and/or power up. I found that this is not the case. After boot the ServoCapt register contains some seemingly random value. If this is not taken into account in the algorithm that converts axis position to UINT servocapt motor position, the compare position will be incorrect. The work around for is is fairly easy, just save the value in the servoCapt register to a P variable at boot. Then use this value to effectively null the ServoCapt register when calculating the toggle position. The down side is that if the P variable ever gets changed or corrupted, then the compare position results are invalid and the outputs don't work as expected. When this happens it is rather difficult to diagnose.

Second, there is a hardware issue when reversing direction, the output will not toggle when reaching a compare position. Again, I found a work-around for this; both position compare registers are set, one shortly before the desired position, the other at the desired compare position. The compare function will skip the first value, but toggle at the second value. When running in the positive direction, the output will toggle as expected at each compare position. I exchanged several emails with Steve Milici about 3 months ago, so he should be aware of this problem.

Both of these issues have work-around's, but it makes the overall solution somewhat fragile. I am hoping that the Gate3 chip is getting an update at some point, and was curious as to the timing. If there is no update planned, I may try to implement this on the Gate1 card. I assume it does not have the same issues.

Thanks,
kmonroe
Reply
#2
I cannot duplicate your issue with the ServoCapt register not being set to 0 on power-up/reset. There are both hardware and software mechanisms to force it to zero.

Regardless, it should not matter at all for the robustness of your algorithms. Status element Motor[x].HomePos stores the sensor position (converted to motor units) at the home trigger. Therefore it holds the difference between motor zero and sensor zero. It does not matter what the power-on position is. If you are not planning on doing a real homing search move on the motor, at least do a "homez" (zero-move homing) to get this element set properly.

We are looking into the issues with the position compare. Because the DSPGATE3 ASIC is "hard wired" (not an FPGA), there is no possibility of a quick change.
Reply
#3
Hi Curt,

I've seen the ServoCapt reset issue on several different E3 cards I have here, strange you can't duplicate it.

Is there something with my setup that could cause ServoCapt to be non-zero at start? The motor on this particular card is setup as a PFM virtual motor.

Since my real motor is using a BissC serial encoder (connected to an ACC84E card) I can't use the Gate3 card that is driving the real motor as my hardware position compare output. Using a virtual PFM motor on a different Gate3 card seemed like the easiest way to implement hardware position output with this setup (this method was recommended by Sina).

Part of the startup sequence is to homez the virtual motors; I'll investigate using HomePos instead of the P-variables. Maybe that will prove to be more robust that what I currently have.
Reply
#4
In the DSPGATE3, the value of the PFM output is saveable, so you may have saved it as a non-zero value, and on power-up/reset, it first gets restored to the last saved value before your virtual motor operation zeros it. This could explain what you are seeing. While there is a method for zeroing the counter, I think it will be better regardless to use the HomePos offset. That is what we recommend in the manual.
Reply
#5
I experimented a bit more with this, and I found that the value in the Gate3[i].Chan[j].Pfm register when a "save" is issued from the terminal definitely effects the result that gets written to the .ServoCapt register at reset.

Curiously, in my case, saving with the Pfm register at zero resulted in a value of 128 in the ServoCapt register after the system was reset.

For the position compare output, the algorithm that converts motor position to units of CompA and CompB already takes HomePos into account. It also applies the power-up value recorded from the ServoCapt register after boot. If the ServoCapt offset is not taken into account, the EQU output toggle position will be off by whatever amount ServoCapt booted up with.

Here's the equation that converts from motor position to CompA/B register positions:


m8HomePos = pshm->Motor[8].HomePos;
m8PosSf = pshm->Motor[8].PosSf;
// xfrmMtr1CompA is motor position after kinematics and transform equations are applied.
// ch0PwrUpOffset = Gate3[3].Chan[0].ServoCapt at power-up/reset

ch0CompA = (xfrmMtr1CompA+m8HomePos)/m8PosSf;
Gate3_3_ptr->Chan[0].CompA = (((int)ch0CompA % 1048576)*4096)+(ch0PwrUpOffset*16);


This all works great, the only problem is if the ch0PwrUpOffset variable gets corrupted, then the CompA and CompB positions are calculated incorrectly. Not a huge problem, because the power-up variables don't get messed up often, but when they do, its hard to diagnose. Resetting the Pmac is about the only way to fix it.
Reply
#6
I can't duplicate this issue. Motor[x].HomePos stores the sensor position at the home trigger (or zero move homing event), regardless of what the power-on position was. There is no need to use the power-on offset.

If you use a non-zero value for the power-on offset, I would expect you to have trouble when the value is zero (or a fraction of a count as you have seen).
Reply
#7
I still don't understand how HomePos applies to values in the Gate3 CompA/B and ServoCapt registers. HomePos only seems to work with motor power-up position, not with the encoder value captured in the Gate3 ServoCapt register. In my situation, ServoCapt boots with some non-zero value, with motor ActPos and HomePos values both zero at the time.

From reading the documentation, and from experimentation, HomePos seems to store the offset of the motor from the power-up/reset position (which is zero in my case); not the servoCapt encoder position, which is what the CompA and CompB register values are ultimately compared to when using Hardware Position Compare functions.

This is what I saw on my Power Pmac system:
* After boot, Gate3[i].Chan[j].ServoCapt = -28800
* Motor position as displayed in position window was zero, Motor[x].ActPos = 0 and Motor[x].HomePos = 0.
* Issued motor homez command, Motor[x].HomePos = 0. This was done before any motion was applied.
* Moved motor to position of 100 motor units, Gate3[i].Chan[j].ServoCapt = 6524800.
* Issued motor homez command again; Motor[x].HomePos = 100, This makes sense according to what is in the manuals.

But...in my case, just using the HomePos alone won't compensate for the non-zero encoder value in the Gate3 ServoCapt register at reset. Since the Gate3 EncCtrl is set to 8, the internal pulse and direction counter drives the encoder count. What seems to be happening is that saving when the Gate3 Pfm value is non-zero results in this value getting written to the Pfm register at power-up, which then causes encoder ServoCapt register to count up, resulting in the non-zero values in the ServoCapt register at power-up. Since the Gate3 card compares the values in CompA and CompB to the ServoCapt value, the power-on offset does need to be used, otherwise the position output just won't work correctly.


HomePos is also used, but only to compensate for a motor zero position that is different than the motor power-up position.
Reply
#8
It looks like it would be best for you to force a reset of the encoder counter to zero when you start up. This can be done by setting bit 19 of Gate3[i].Chan[j].InCtrl to 1. The amplifier enable bit for the channel must be 0 when you do this. The write-protect key (Sys.WpKey in Script, Gate3[i].WpKey in C) must be set properly as well. This "position clear" bit clears itself when the operation is done.
Reply
#9
I tried this and the ServoCapt registers did get reset, but there still seemed to be some offset present. When I ran a motion program, the output toggle positions were off more than 0.6mm, which is allot for our application.

I made sure the power-up P variable offsets where 0, so those should not have been effecting the results.

When I went back to the original method of saving the ServoCap power-up values to P-variables then using those as part of the position compare calculations, the system worked as expected. The outputs toggled exactly when they were supposed to.

At any rate, thanks for the help Curt.

Regards,
Kmonroe
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)