kmonroe023

Thanks for the additional information Curt. I can get the subroutine to run fine if called from a PLC, but if it is called from a motion program, nothing happens. What I think the problem is, is that the calling motion program is running in coordinate system 1, but the sub-routine needs to run a motor in coordinate system 2. I originally thought setting Ldata.Coord=2 in the subroutine would fix this; but as I thought more about it, I came to the conclusion that since the sub-routine was called from CS1, it was running in CS1 and setting Ldata.Coord would do nothing to change this. Therefore, nothing happened because the commanded axis in the sub-routine does not exist in CS1. I did eventually get it workiong by setting a program flag and letting one of the PLCs call the sub-routine. Not the most elegant solution, but it works.

Thanks, that makes sense Brian. I'm already using a custom G-code to call the subroutine. I'll experiment a bit and see what I can come up with.

I have a subroutine written in the Libraries folder that performs a RAPID move with a trigger: z(position)^-0.1. If I call the subroutine from a PLC, it runs as expected, the motor runs until the trigger and stops, then backs up 0.1mm. However, I really need to be able to call this subroutine from a motion program and have it work like it was called from a PLC. I tried to call it from a motion program and nothing happens. I assume the subroutine runs as a motion program if is called from a motion program, and the PMAC chokes on the Rapid command when doing this. Is there anyway I can call a subroutine from a motion program and have it run as a PLC, so the Rapid move command works?? Thanks, Kmonroe

But...the file in question (pp_save.tpl and/or pp_save.cfg) is actually generated on the PMAC when you type 'save' in the terminal window. The user only gets the files if they are explicitly uploaded to the IDE. So, can't the preFilterEna bit be set incorrectly if the PMAC is saved while a motor is disabled with trajectory pre-filter? The reason I make this point, is because I think this is how I first discovered this issue. I had disabled all motors then saved to my PMAC, I then uploaded the config files to save the latest settings to the IDE. A little while later I reset ($$$) the PMAC; at this point the PMAC started up in the default state...no PLCs or programs and clock settings were set back to default. It was only when I attempted to download the pp_save.cfg file (that was originally uploaded from the PMAC) that I discovered that the preFilterEna flag was set to -1. Hope all this makes sense. Thanks, Kmonroe

Motor 4 on one of our systems is setup with a trajectory pre-filter. It ran fine with the pre-filter enabled, but the system won't re-load the pp_save cfg files at boot because Motor[4].PreFilterEna is equal to -1 in the config file. If I try to download the pp_save.cfg file, the download stops at .PrefilterEna with an illegal write error. I normally upload the configuration files to the IDE after I save changes to the Pmac, so the system settings are backed up. Just wondering how PreFilterEna got set to -1 in the cfg file. Any ideas?? Thanks, Kmonroe

Win7: Trend Micro OfficeScane (installed by our systems dept.) I have no anti-virus running on the virtual XP machine.

I've run IDE V1.5 in Windows 7 64bit, and in a WinXP Virtual PC. I've noticed that the time to compile a background program while running the IDE in Win7 is much longer than when running the IDE in the WinXP virtual PC. In Win7, it takes almost two minutes to compile background programs; but it only takes about 10-15 seconds to compile the same project when running in virtual WinXP. Just wondering if this is a know issue, or if I have something unique happening. Thanks, Kmonroe

If you have absolute encoders on your motor, you should not need to do a homing search move. I have several linear motors with absolute encoders, and to set the zero position, I set motor[x].HomeOffset equal to the position where I want zero. The recovery program just issues a homez to set the motor position, then jogs to the home position. I use this procedure to set the value for HomeOffset: first set motor[x].HomeOffset to 0, homez the motor from the terminal (#1hmz), note the position that is displayed in the position window, then set motor[x].HomeOffset to this value. Save to the Pmac. Now when you issue a homez command, the motor should be set with its absolute position. kmonroe

Dan, Thanks for the detailed response! It is good to know about the limited servo rate available using Ethercat; the dynamic performance required by our application means we're closing our servo loops at 8khz. A no-go for Ethercat. I also like your idea of setting the Macro network up to auto-configure the drives. We build our machines for internal use, but the last thing we need is for maintenance to replace a drive a two in the morning and then have the machine down until an engineer can come in and setup the drive.

Curt, Thanks for the information. We're currently very comfortable with PWM control, but looking in our crystal ball, we may have some applications where the noise immunity, and options for distributed control offered by a Macro setup, make sense. We'll probably get a small setup, a couple of motors and drives, to experiment with before committing ourselves.

We currently do a fair amount of work on the Power Pmac using Gate3 cards and PWM (DT GPL) drives. But we're considering also using either Macro or EtherCat drives. We are not familiar with either, so we're not sure which one to go with. So I'd like to ask the DT folks, and probably the Power Pmac community in general: EtherCat or Macro; what are the advantages and disadvantages of each? If you were building a system, which would you pick? Have you designed a system using either and what did you like or dislike? Thanks, kmonroe

Nevermind...it wasn't the kinematics after all. I am using axis transformations to cut multiple shapes. If the process was interrupted, the recovery routine was not deselecting the transformation before moving the motors. Once I fixed that, everything works as expected. Thanks to Charles this morning for taking my call and shaking loose the cobwebs for me! Kevin Monroe

I am setting the KinAxisUsed in the Forward kinematic routine(see below), not in the inverse routine. if (KinVelEna>0) callsub 100; // double pass for velocity calcs? KinAxisUsed=$C4; // X,Y,C returned N100:

Is there anything that would cause axis values returned from the kinematic routines to be incorrect. Not sure what caused this, and rebooting the Pmac fixed it, but when I queried the axis positions from the terminal ("&1p"), they were clearly wrong. I also set P variables equal to the axis and motor positions at the end of the kinematic routines and monitored those in the watch window, and those reported the correct positions! So I know the kinematics were working properly, the values just seemed to get mis-reported to the system. The only thing I did before experiencing this problem was a script PLC download, after that both kinematic routines reported the same incorrect values. Rebooting the PMAC fixed it though. The kinematic routines I'm using "have alot of miles" on them so I'm just curious as to what could have caused this problem. Thanks, Kevin Monroe

I have a PPMAC system with 2 Acc24E3 cards; the feedback encoders are 2000 cnt/mm quadrature encoders. We also have an Acc24E2 card in the same rack. I found that we started to loose encoder counts at a motor velocity of approximately 1400mm/sec on the E3 card. Putting the same encoder on the E2 cards we didn't loose counts until about 2000mm/sec. After re-reading the E3 manual I discovered the Gate3[x].EncClockDiv parameter and set it from 5 to 4; now the E3 encoders don't loose counts until about 1900 mm/sec (which is better for our process, 1400mm/sec is too close to where our process wants to run). My question is: knowing that you rarely get something for nothing; what are the pitfalls of increasing the Encoder Clock Frequency? Can I just set EncClockDiv to 4 for all my E3 cards and call it good? Anything else I need to consider when changing the hardware clock frequencies? Are the default hardware clocks just higher in the E2 cards? The motors are already setup and running, we just experienced problems at higher velocities. Thanks, Kevin Monroe

Hello Sina, So, would the PLC code for the startup PLC look like this: Gate3[1].AdcAmpCtrl=$FFFFFC02; call timer(0.25); Gate3[1].AdcAmpCtrl=$c0000304; call timer(0.25); Gate3[1].AdcAmpCtrl=$a0002304; Setting the strobe words makes sense, but I don't understand why the ADC header bits need to change from 2 to 4. Are there delays in using the extended mode that need to be accounted for? Thanks!

What is the proper way to disable low voltage faults on a GPL PWM drive being controlled by an Acc24E3 card? The drive is being supplied with 48VDC. On a PPmac with the E2 card I ran the following PLC code at start to disable the low voltage fault: Gate1[5].AdcStrobe=$3FFFFF; call timer(0.25); Gate1[5].AdcStrobe=$c00003; call timer(0.25); Gate1[5].AdcStrobe=$a00023; Running similiar code for the E3 card yielded some strange behavior, the motors did not seem to commutate correctly and/or had very little torque. Gate3[1].AdcAmpStrobe=$3FFFFF; call timer(0.25); Gate3[1].AdcAmpStrobe=$c00003; call timer(0.25); Gate3[1].AdcAmpStrobe=$a00023; I found that if I leave the AdcAmpStrobe at $a00023 the drives will run (the code above has been commented out of the program). However, there are occasional problems getting the motors on that card to run after a reset. What is the proper way to disable low voltage faults using the E3 card. I read through the GPL Drive manual and thought I understood the procedure when I got the motors running with the E2 card. What am I missing when applying the E3 card? Thank you, kmonroe

Sure. The machine is currently running production, but we've got some time on it this Friday. I'll try to get some screen shots then.

We are utilizing the cross-coupled gantry algorithm for one of our machines running the Power Pmac. We hare having a sporadic problem I would like your opinion on. Occasionally, when the gantry is holding position the two gantry motors appear to start fighting each other. I've observed that the I2t sum on one of the motors will gradually accumulate to the point were it exceeds the limit, causing an I2t fault on that motor. When that happens the motor will disable, but then the gantry will run away making a howling sound (sorry for the low tech description, but I don't know how to describe it any other way). Disabling, then re-enabling both motors generally gets things back to normal and the machine will run fine for a significant period of time (several days) without problems. There does not seem to be any identifiable precursors to the motor problem, it seems to 'just happen'. The gantry structure itself is very rigid so I don't believe that is the cause. Any ideas as to what could be causing this? I thought I might have a problem with the way the motors are homed, but it runs normally the vast majority of the time so I basically ruled that out. Thanks, Kevin Monroe

Would there be any problems using the Power Pmac X coupled gantry servo algorithm with a single encoder and hall sensor for both motors, assuming the gantry is sufficiently stiff? The single encoder is used for commutation and position/velocity feedback on both motors and the hall sensor to establish phasing upon power up. Both motors are the same size linear motor. In theory it seems possible, but I want to make sure that I'm not missing something here. Thoughts... Thanks, Kevin

I'm using several Delta Tau PWM drives with our Power Pmac system. Occasionally the motor[x].AmpFault flag will stay set even though the drives are not indicating any faults (LED display = 0). This normally happens after I hit estop and the amps get a low voltage fault ("L"). Most of the time they'll clear when the motors are re-enabled, but sometimes the ampfault flag stays set after the drive re-enables. The only way I can get the AmpFault flag to clear is to $$$ the Pmac. Is there a way to clear the fault flags w/o rebooting? My control PLCs monitor the AmpFault flags and won't let the machine run if they're set. Thanks, kmonroe

No problem... I know this is new so its a given that some features will be discovered in this way. Thanks...

I noticed something interesting today relating to the cross coupled gantry servo algorithm (Sys.GantryXCntrl). In a nutshell, I found that if I don't explicitly close the loop on the follower motor, I can run motion programs in the the gantry C.S., with the master motor closed and the follower motor loop open. I know that the follower motor is technically not part of the Coordinate system, but should I really be able to run a motion program that uses the cross coupled gantry with only the master motor enabled? Once I found this out, I fixed my homing and recovery PLCs so that the loops on both gantry motors are closed (i.e. "jog 3,4=0" instead of "jog 3=0"). We have a very stiff gantry, so I really didn't notice any problems until I tried to push accel/decel rates beyond about 1 to 1.5Gs. At that point, the master motor servo command was saturating at MaxDac and the path started to degrade in sharp corners. My question is: Is this how the algorithm was designed? I would expect that if the follower motor loop wasn't closed, then the Coord[x].ClosedLoop flag would be 0, preventing any motion programs from running. Thanks, kmonroe

Hi Sina, Very nice...thanks. One question. What if motor units change from the Turbo to the Power Pmac application? For our Turbo application, motor units are encoder counts. For the Power Pmac application, Motor[x].PosSf and Motor[x].Pos2Sf are set so motor units are in millimeters. Thanks, Kmonroe

I thought about that, but I like having the alarm message show up in the unsolicited message window. Its not uncommon for us to monitor equipment remotely, so I won't always have the HMI to look at.