kmonroe023

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.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.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.

I think I found a bug with the System Setup Program in the IDE. After a factory default reset ($$$***), a system that contains Acc24E3 cards seems to default to a 4 channel setup, even if 2 channel cards are installed in the backplane instead. When the System Setup Program is used to setup motors on the 2 channel Gate3 cards, some of the "Addressing" elements don't seem to get set properly, leaving these elements at their default 4 channel equivalent. See the attached jpg file for a screenshot from the Setup Variables applet right after using System Setup on a motor. Most of the elements associated with commutation get setup correctly, but a few elements pertaining to flags don't get set, and can cause a little confusion when trying to home these motors. Currently running IDE ver 1.5.0.21. (If this isn't the correct place to report this, please let me know). Regards, kmonroe

I experimented a bit more with this, and I found that the value in the Gate3.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.

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.

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.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

I just noticed that the Power Pmac Web page talks about an optional IEC 61131 development environment. Just curious about how you go about getting it and how it works with the existing IDE. Does it install on-top of the existing IDE or is it a separate application that can run in parallel with the IDE?

I'll give it a try. Thanks Curt!

I've been working on developing kinematics for a machine tool that utilizes r,theta tooling. Tool tip coordinates are in x,y and I need to convert those to r (radius) and theta values, which is pretty simple, its just rectangular to polar conversion. That seems to work well, where I'm running into problems is with the rollover. I've got the rollover working in the positive direction but I'm struggling with negative rollover values. I know I'm missing something simple, and I'm wondering if you guys have some equations I could look at. I know you handle it the Pmac for axis defined as rotary axis so I'm assuming you have some algorithms to cleanly handle rollover. Thanks, Kmonroe

We have seen a sporadic problem were the PPmac will not boot up correctly after a controller reset ($$$). It appears that the configuration does not load since the Pmac will report no project loaded and will show no defined motors. System settings are also set to their default values. This has happened several times on production machines with mature Pmac control programs and settings, so I don't think it is related to a bad configuration. Generally, resetting again will allow the controller to configure properly. Has anyone else had this happen, or do I possibly have a questionable controller? We're running the latest firmware: 1.5.8.0

I've been experimenting some more with this. I am still having issues with toggling the EQU output when the motor is moving in the negative going direction, but only under certain circumstances. I can get the output to toggle in both directions if the Gate3 Comp registers are setup prior to running the motion program, or if I setup the Comp registers by hand and run the motors from the command line. However, if the Comp registers are updated while the motion program is running the output will not toggle in the negative going direction. Toggling in the positive going direction works as expected, and seems unaffected by updating the Comp registers while a motion program is running. This behavior is very reproducible, I've even seen this happen while running 'cpx' programs from the command line. It just seems like I am running into an issue baked into the PMAC3 IC. Thoughts??? Regards, Kmonroe

Thanks for the information Curt. I will give all this a try.

Curt Could you post your motor setup that uses the internal counter as feedback. I'd like to compare it to my setup and see if I have something setup wrong. Also, the Gate3 card setup might be helpful as well. I've tried everything I can think of to get it to toggle in the negative direction and no luck so far. Thanks, kmonroe

Bump.... Just wondering if there has been any progress with this. Thanks.

Thanks for the info Curt. On my system, edge suppression failed to function when running a continuous series of circle/linear moves (our part profile) with segmentation and look ahead enabled. With CompA=CompB, it always toggled in the positive direction. Regarding not seeing the position reversal problem; do you have the PFM motor setup similar to my project? Would it be possible for you to post your motor setup and Acc24E3 card setup if applicable? Thanks, kmonroe

This will work if I want the output off, but I would like to also keep the output on. Setting the EquOutMask=0 turns off the output. If I leave the mask as is (3 in my case), the output still turns off when ServoCapt runs through 0. I was hoping having compA and compB equal would keep the output from toggling, either from 1 to 0, or 0 to 1. So far these are the two problems that are preventing me from implementing this: 1. The EQU output toggles when the CompA and CompB registers are equal. The manual specifically states that for a Pmac3 style IC the EQU output should not toggle if CompA and CompB are equal. If I set the CompA and CompB registers to values larger than our work envelope I can get around this problem. The output won't toggle because the motors will not travel far enough to reach the Comp values. 2. I can only get the output to toggle when the motor is traveling in the positive direction. If the motor is traveling in the negative direction, the EQU output will not toggle, even though the encoder position value in ServoCapt matches or passes one of the values in CompA or CompB. It's entirely possible I have a card or motor setting that is causing the above issues, I'm just perplexed as what I could be doing wrong. The users manual basically says that the EQU output will toggle when the encoder value matches or passes one of the Comp register values. Motor travel direction should not matter. Update: I also tried changing the value of the Gate3.Chan[j].EncCtrl value. Since the EQU channel is setup as a PFM motor, EncCtrl is set to 8 for Internal Pulse and Direction CW. If I set EncCtrl equal to 12 (CCW), then the output would not toggle on either the positive going or negative going direction. If I change it back to 8, the output would again toggle in only the positive going direction.

I am using the position compare output on a Acc24E3 card to turn an output on and off at a specific point on a closed 2D profile. We're performing contour following and want the output to turn on then off at the same point; on when the profile is started and then off when the profile is completed. There should be as little overlap or gap between the start/stop points as possible, hence the need for using the hardware position compare output. We want a perfectly closed shape. A script PLC monitors coordinate system sync variables programmed into the shape program to set Gate3.Chan[j].CompA and .CompB registers. This is to make sure the output comes on when starting the shape and not as the tooling moves through a transitional point to get to the part position. To do this CompA and CompB are set to zero prior to starting the part program and only set when the sync variables indicate the tooling is close to our desired start position. According to the user manual the EQU output should not change state if both Comp registers are equal. This part seems to work fine, the EQU output toggles and comes on as expected at the start of the profile. Now for my problem: After the EQU output toggles, the Comp registers are again set to zero. Like the start point, the script PLC monitors the coordinate system sync variable to set the Comp registers for the off point. Again the thinking is that we don't want the output to toggle as the motors move through a compare position while the tooling moves around the profile. But...I'm actually seeing the EQU output toggle when both Comp registers are zero! It seems to occur as Gate3.Chan[j].ServoCapt goes from a negative to positive value. I've made sure there are no PLCs forcing the EQU signal on or off. Only the state of the Comp registers should be controlling the EQU output. I used the plot utility to capture pertinent data, then I imported it into an Excel spreadsheet, see the attached image for a screen cap of the position where the signal toggles with both Comp registers at zero. As you can see both Chan0 comp registers are zero when the Equ output toggles off, but the ServoCapt position goes from a negative to positive value. What could be causing the output toggle in this state? If both Comp registers are zero, the output shouldn't toggle, but the output is toggling when when the motor position moves through servoCapture zero. Motor[6].ActPosition is on Chan[0] and .HomePos was non-zero (-30 when this data was taken). I can upload or send you the complete Excel and project file if that helps. I'm running firmware 1.5.8.0. Thanks for the help. kmonroe

After a little more run-time on this machine, I had to go back to using jog commands in a script PLC to run the motor to its programmed position properly. Even using masterCtrl=3 seemed to result in the motor overshooting its programmed position in some cases when running a motion program.

I figured out what was causing the watchdog faults; it was the tsel(-1) command I described in the post above yours. Apparently you can't use that command in script PLCs.

Curt, thanks for the info. I did try your recommendation and it seemed to have fixed my problem. I'll need a little more run-time on the machine to verify it completely, but for now it appears to function as I originally expected. Thank you

One other bit of information, the housekeeping PLC that handles machine recovery runs the small bit of code below right before it actually enables PLC8. Ldata.coord =1; //deselect any cs1 transforms tsel(-1); call timer(0.25); Could trying to disable transforms in a script PLC cause the watchdog faults? Coordinate System transforms are used while running the motion programs.

I'm having a weird problem with a Power Pmac running the latest version of the firmware (1.5.8.0). It seems that something is causing the background task to hang; Sys.WdTimer counts down to zero and everything on the PMAC stops. I've isolated the problem to one PLC that gets enabled when the machine is recovered after it has been E-stopped. Once the e-stop is cleared and power is re-applied, this PLC is run to enable all motors and run them to their 'home' positions, once that is done it disables itself. Now for the strange part: this will only happen if the E-stop occurs while a motion program is running (in CS1). If the e-stop occurs while the machine is enabled (all motors on), but not running any programs, the machine recovers normally. I've attached the PLC so you can have a look at it; nothing too complex here so I fail to see how this could cause the background task to hang, plus it works just fine any other time except under the conditions I discribed above. I monitored Sys.WdTimer and Sys.BgTime, when plc8 is run, BgTime stops updating, WdTimer will count down and watchdog the system when it gets to zero. When we estop the machine we just remove line power from the Geo DirectPWM drives, 24vdc control power to the drives stays active. Thanks, kmonroe 8 - plc8 fast homing.zip

Sounds like your gantry system may not be mechanically aligned. The cross-coupled algorithm will work real hard to make both motor positions the same. If your bearing rails are not straight, and 1 motor travels farther than the other over the Y-axis travel distance, the position difference will increase causing one motor to work against the mechanical system. Depending on the stiffness of the structure and the position difference between the two motors, the motor may not have enough torque to align to the other motor, causing I2T faults. I speak from experience here; in our gantry one rail had a slight curve to it (our mechanical engineer determined it had a 3 mile radius!). This curve meant one motor basically traveled farther than the other; when the position difference between the motors was large enough...POW!...I2T faults. If the leader motor faults first, this can cause the follower motor to basically run away. One easy way to test your system: kill all motors then pull your Y-axis gantry against the hard-stop, 'homez' the Y-axis motors, then push the gantry to the opposite hard-stop; note the positions of each motor, they should be basically the same (for us, less than 0.1mm difference). If the positions are different, then there may be a problem with the gantry structure or with the feedback sensors; either the encoder tape or the sensors themselves. Good luck, this can be tricky to fix. You may need to enlist the help of some good mechanical folks to get your system setup properly. Regards, kmonroe

I fought this problem some more today. As stated in my original post, I am having problems with a motor going to a programmed position after master following is used for that motor (the motor in question is the slave). Here's a simple outline of the program (CS1 is our gantry, and our Z-axis motor (motor[4]) is assigned to CS2). 1. Program started in CS1, custom G code called to lower Z-axis to part. The CS2 program is started in the normal way (begin 2:10; run 2). 2. When the z-axis is lowered, motor[4].masterctrl is set equal to 1, and the gantry runs our profile to perform the cut. 3. When the cut is finished, motor[4].masterctrl is set equal to 0, then another custom G-code is called to raise the z-axis. Step 3 is where things don't work correctly, the axis does raise but it never gets to the target position, its always several millimeters away. I've plotted the actual and commanded motor positions, and the PMAC is actually commanding the motor to run short. For example, my raised position is -2.5mm, but the motor only goes to about 5mm and stops. It appears to me that even though following is turned off, there is still some offset getting applied to the axis position. There are no other transforms, offsets, or kinematics applied to CS2. If I jog the motor from the terminal, the motor runs right to the target position. I did get our machine to run, but my solution was ugly. Instead of calling a motion program, I run jog commands from a script PLC; the jog commands are nested inside of a while loop that says 'if my motor isn't high enough, jog again!'. Ugly, but it works; I also have a counter in the loop that will bail if it goes through more than 100 iterations, this keeps my PLC from getting stuck. Strangely, jog commands issued by the script PLC still exhibited the position offsets, if I jogged from the terminal command line, the motor went right to the designated position. My question is: what the heck am I missing? If I turn following off for a motor, shouldn't it just be off? What could be adding or offsetting my motor commanded position? Multiple jog commands work, but why? Help! Thanks Kmonroe

Hello Richard, The delay did not seem to make much difference, so I took it out. If I jogged or moved the axis from the terminal window, I did not see the overshoot. Which is why I was so perplexed about why it was happening when invoked via the program. But your comment about PMATCH made me think....the raise program (program 10) is called via a custom g-code from a motion program running in Coordinate system 1 (the top snippet shown in the OP is from the g-code routine). The Z-axis is in coordinate system 2. I may try to add a PMATCH command to the raise program and see if that fixes the problem. Is there some reason why the z-axis position would not be re-calculated if the cs2 program is called from coordinate system 1?

I have a motor driving a z-axis in a cutting application, we are cutting a curved part; cut pressure is controlled by an air-spring. As the cutting wheel rides over the part, the air-spring compresses or extends, this displacement is read by an encoder, which our z-axis motor is slaved to during the cutting process. The motor[x].MasterCtrl bit is turned on/off to control whether the z-axis motor is in following mode. Now for my problem: It appears that following is still enabled, even if MasterCtrl is set to 0. See the attached pdf for a plot of the move profile. Motor[4] is the z-axis. "zRaisePos" is the programmed raise position the motion program uses to position Z. As you can see from the plot, after the MasterCtrl bit is turned off, the actual motor position overshoots the programmed position. But only for the first move after MasterCtrl is turned off. During all subsequent moves, the z-axis motor returns to the proper home position. "zRaisePos" does not change at all during the moves. Here's a code snippet from the motion program that raises the z-axis: zRaisePos = -2.5; Motor[4].MasterCtrl = 0; // turn off following //call timer(0.2); begin 2:10; // raise z run 2; Motion program 10: open prog 10 cs2ProgramRun=10; N10; abs; // absolute move mode ta50; ts10; F100; // set feedrate z(zRaisePos); // move z axis to home point dwell0; cs2ProgramRun=-10; N-10; close To me it looks like the motor is still being affected by the master encoder, even though MasterCtrl is turned off. Is there any other reason to explain the overshoot right after following is turned off? Thank you, Kmonroe zAxis Profile 2.pdf