kmonroe023

Ok. Thanks for the clarification.

I've noticed what I think is a bug with the way subroutines handle local (L) variables. I have a simple PLC that calls 2 subprograms, the first toggles the return value "bSecToggle" from 0 to 1 at the rate designated by the first variable passed. In the example below the output variable toggles at a rate of one second. Calling this subroutine is conditioned upon variable "foo1". The second subroutine simply accumulates a timer as long as the passed variable is non-zero. I've noticed that if both subroutines are called, neither functions as expected. If I set "foo1" equal to 0 to disable calling the first subroutine, the second performs as expected. Likewise if I disable the second subroutine the first functions as expected. It appears that the local variables of one subroutine are stepping on the other. Is this the desired behavior? I assumed that local variables inside sub-programs were unique to each sub-program. However, my tests indicate otherwise. Please see my code below: open plc 1 // one second toggle timer if (foo1 == 1){ call toggleTimer(1,&bSecToggle); } // Cycle Timer logic call mainCycleTimer(bCutterRunning,&cycleTime); close Here is the subroutine code (both subprogs are in the same .pmc file): open subprog mainCycleTimer (CutterRunning,&timerOut) local CycleTimeStarted,CycleTimeStart; if(CutterRunning==1 && CycleTimeStarted!=1) { CycleTimeStart=Sys.Time; CycleTimeStarted=1; } if (CutterRunning==1) { timerOut=Sys.Time - CycleTimeStart; } else {CycleTimeStarted=0} return; close open subprog toggleTimer (tTime,&outFlag) local ToggleTimer,ToggleTimeStart; // Toggle timer logic if (ToggleTimeStart==0){ ToggleTimeStart=Sys.Time; } else{ ToggleTimer=Sys.Time-ToggleTimeStart } if (ToggleTimer>tTime){ ToggleTimeStart=0; ToggleTimer=0; if (outFlag==0){ outFlag = 1; } else {outFlag=0} } return; close

Thanks for the reply Charles, I will try the comp table method. I think there may be a typo in the manual for the ECT method cascading loop example (page 322-323). The example starts by setting Motor[0] as the outer loop motor, but later assigns axis W to motor 4. See cut text below. Coordinate System Setup To assign all of the motors to axes in C.S. 1, with units of millimeters, the following definitions can be used. &1 // Address C.S. 1 #1->10000X // X-axis positioning in millimeters #2->10000Y // Y-axis positioning in millimeters #3->10000Z // Z-axis positioning in millimeters #4->4000W // Vertical gap (W) in millimeters Coupling the Loops with Position Following To couple the outer and inner loops using the position-following technique, the outer loop’s servo command value must first be processed through the encoder conversion table. Because this application has a limited movement of the inner loop from the outer-loop command, the value will not be integrated. The ECT entry will look something like this: EncTable[4].type = 11 // Floating-point read EncTable[4].pEnc = Motor[0].IqCmd.a // #0 servo cmd as source EncTable[4].index1 = 0 // No left shift EncTable[4].index2 = 0 // No right shift EncTable[4].index3 = 0 // No limiting EncTable[4].index4 = 0 // No integration EncTable[4].index5 = 0 // No pre-scaling EncTable[4].ScaleFactor = 1/256 // Scale to +/-32K range

I'm trying to implement cascading servo loops per the user manual. I'm trying to control the height of a tool over a surface using a sensor w/ a 0-10V signal into an ACC28E card. Once "following" is enabled the Z axis needs to maintain the gap between the sensor and the surface. I'm a bit confused by what the manual is telling me though: I've setup motor 0 to process the analog input from the 28E Motor 2 is the Z axis (real motor) In the manual EncTable[4] is setup to process the servo cmd from motor 0. Motor 4 is setup to be the secondary axis W, to Z in the CS. There's no motor setup listed in the manual for motor 4, should this be a setup as a virtual motor also? Or should motor 0 be setup as axis W since that is the sensor "motor" and EncTable[4] is only used to process the outer loop? In the present state, if I try to run a motion program I get a CS not ready message since motor 4 is not configured.

Regarding my OP. I think I may have fixed this. I used a double register read, type 2. Pointed pEnc2 at a shared user memory register that I will set to zero in a BgPLC. So I end up with the ADC data in bits 8 to 23, and the 'zeroed' data from shared memory in bits 24-32. Shift everything down 8 bits with index2=8 and voilà, unsigned integer result in PrevEnc. I find it weird that the single register read with a 16-bit right shift didn't work though. Shouldn't the MSB of the original source data not cause the register to roll over once it's been shifted right?

I've got an application where I'm trying to slave a motor to an analog sensor connected to an ACC28E card. I'm processing the input from the ACC28E through the ECT. The input is 0-10V (0-3000microns), so I want an ECT output of 0-3000. The data from the 28E card shows up in the PrevEnc Register in the high 16 bits as expected, so I set index2 to 16 to shift it all down to the lower 16 bits. Then I set the ScaleFactor to scale the output of the ECT in my user units (microns). All works great until the input from the 28E is greater than 32767, at which point the ECT output goes immediately negative. I assumed that if I got the MSB out of bit 32 that it would no longer be used as a sign bit and the data from the 28E would show up in PrevEnc as an unsigned integer. However, as soon as bit 16 goes high in the PrevEnc register (with index2=16), the register still goes negative. I'm missing something here. How can I take the 0-65535 counts raw data from the 28E and scale it to 0-3000 so I can use it to slave the motor. //ECT setup EncTable[25].type=1 EncTable[25].index1=0 EncTable[25].index2=16 EncTable[25].index3=0 EncTable[25].index4=0 EncTable[25].index5=0 EncTable[25].pEnc1=Sys.pushm EncTable[25].pEnc=Acc28E[8].AdcUdata[0].a EncTable[25].MaxDelta=0 EncTable[25].ScaleFactor=3000/65535;

Thanks for the info Steve and Curt, I will give these a try when I get a chance.

Any hints as to what to look for? I've checked everything that I am familiar with and the settings look normal. What would cause the servo loop to not output a torque command? The machine in question runs the x-coupled gantry fine with FW 1.5.8.0, but not with 1.6.1.1 or 2.0. All the motor settings came from that 1.5 setup. When I get access to the machine and have time to flash it back to 1.6, I'll double check settings, but admittedly I'll be shooting in the dark since everything seems to be correct.

The motor settings carried over from the 1.5.8.0 system where the gantry works fine, but I did check those settings just verify they were correct. In my setup motor 3 is lead and 4 is following. Both Motor[x].Ctrl were set to sys.GantryXCtrl, motor[3].ExtraMotors=1, motor[4].CmdMotor=3. Even if .Ctrl and ExtraMotors where not set correctly, that would not explain why there was not a torque command to both motors, would it? I would expect to see a torque command to 3 but maybe not 4. Also, I checked with another engineer here and he saw the same problem with a new PMAC running 1.6 earlier this year. He had to flash it back to 1.5.8 to get the gantry functional. We have about 20 to 30 systems here running PMAC with the x-coupled gantry so we're fairly proficient in setting them up. Our inability to get one setup with the new firmware is a bit baffling. From the users manual I know adaptive control was added to the x-coupled algorithm in 1.6. Is something there stepping on our gantry setup???

I recently tried to upgrade one of our existing machines running FW ver 1.5.8.0 to 1.6.1.1. The machine uses the cross-coupled gantry algorithm for the Y-axis on a X/Y cartesian gantry system. The motors are brushless servos so the PMAC is closing the current loop. Drives are 2-axis PWM Geo Amps; Axis cards are two-channel Acc24-E3. The machine has been running fine for the last couple of years using the 1.5.8.0 FW. When I tried to enable the gantry motors after upgrading to ver 1.6 FW, the drives on the x-coupled gantry would enable, but there was no torque applied to the motors. When I checked the Motor[x].IqCmd value for the motors running the x-coupled algorithm, they were 0, even when the motors where enabled. It appears that the x-coupled algorithm was not outputting a torque command. This only happened when I tried to close the loop on the gantry motors; ampEna was on, but no torque. Of course as soon as I moved the motors by hand, the PMAC issued an following error and killed the motors. I verified all the motor hardware was functional; current loop tests ran fine as did any open loop commands. Am I missing something? Is there a new command/feature that needs to be set in 1.6 (or 2.0) to get the x-coupled algorithm working? I assumed motor settings from 1.5 would run fine in 1.6... The motors running the standard servo algorithm enabled and ran fine. I eventually flashed the PMAC back to the 1.5.8.0 FW and the gantry worked fine. I'd like to upgrade to 1.6 but can't do that if the cross coupled gantry doesn't work. Any suggestions would be appreciated.

Just got the email from DT regarding the new Laser Scanner Interface. Looks interesting. Is there documentation for this yet? When will it be available? How is it implemented? New piece of hardware, or does it utilize existing axis cards? Thanks! kmonroe

Is there any other way to save data structures to the PMAC from a script or C program? Our machine UI allows an operator to modify a rotary motor reference (zero) position, the motor uses an absolute encoder as feedback. The reference position needs to changed when tooling is mounted to the equipment. When they press a button on the UI a script PLC modifies the Motor.HomeOffset position accordingly. Since this is part of a saved data structure, I would like it automatically saved to the PMAC when they do this. I can't hard-code the values into the PMAC because they will change as tooling is added/removed from the machine, but I would like the changes to be retained in the event the controller is reset. I know I can have them start the IDE and issue a save from there, but I would prefer to not have them mucking about in the IDE if at all possible. In the past we've had our UI software save P-variable parameters in a settings file, but for some reason, I don't like the idea of external software downloading data to saved data structures on the PMAC. Thanks, kmonroe

Is it possible to use the cmd instruction in a script PLC to issue a "save" command to the PMAC command parser? I've tried to do this in a script PLC on a Power Pmac running firmware v1.5.8.0 and Ldata.CmdStatus will return a -20, which indicates an invalid syntax. cmd "save"; // Moves CMD to local CMD program buffer & waits if full If I try: cmd "sav"; // Moves CMD to local CMD program buffer & waits if full CmdStatus returns 0, but the save does not appear to work. After rebooting, any Saved Data Structures that were altered prior to executing the cmd instruction revert to their pre-altered values. I also tried adding carriage return and newline escape characters to the string ("save\r"). Same results as without the escape sequence. Does the online "save" command not work when used via the cmd instruction, or do I actually have the syntax wrong in some way? Thanks, kmonroe

I generally build any diagnostic routines into a background PLC. As a matter of fact, I have a dedicated PLC just for this purpose. Motion programs can be disabled for any number of reasons; soft limits, run time errors etc. Lookahead (if you're using it), blending etc, can also make performing discrete actions in a motion program somewhat cumbersome. Having said all that, DT has built in some nice commands and status elements that make tracking what is happening in a coordinate system easier. First, I would not use P variables, instead use synchronizing line labels. There are two coordinate system elements that you can monitor when using these: Coord.Nsync and Coord.Ncalc. Read the help file or users manual for more detail on how each of these work. Note that these will be set to zero once the motion program stops running. Also, remember that a motion program can run in multiple coordinate systems at the same time, using a P variable in this case could lead to some confusing values, depending on the state of each coordinate system. Normally I'll use a background PLC to monitor Ncalc to track progress through a program. Coord.ProgRunning will be set to 1 if the coordinate system is actively running a program (ProgActive is set to 1 if the program is active, again, see the manuals for differences between active and running). So, between ProgRunning and sync labels, you should be able come up with some pretty detailed diagnostic logic in your PLC. One other thing I do..at the beginning of the program I set a specific global variable to the number of the motion program, at the end it gets set to the negative value of the program number. So for program #10, the variable gets set to 10 at the very beginning and to -10 at the end of the program. In combination with the status elements listed above, this is an easy way to see if that particular program is running and/or successfully finished. Hope all this helps. kmonroe

mshaver, There is a timer subroutine that works quite nicely for PLC applications. It should be in the project solution under the 'Libraries' folder (subprog2.pmc). It takes care of all the while loop nonsense, all you need to do is specify the time in seconds. Usage in a plc ... call timer (0.250); // dwell PLC for 250msec ... If you don't have the subroutine in your project, just add a new pmc file to your Libraries folder and add this code to it: /****************************************/ // Sample calling timer SUBPROGRAM // open plc 1 // call timer (3); // have a 3 second delay // close // // Brad Pedersen Sept 9th 2010 /****************************************/ open subprog timer (time) local EndTime; local count; EndTime = Sys.Time + time do count++ while (EndTime > Sys.Time) close Of course you can forgo calling the subroutine and implement this code right in your plc, adding whatever other conditionals are required.

Ok, that's kind of what I figured. For the most part, we have standardized on firmware v1.5.8.0 for the Power Pmacs in our production equipment. Limiting our installations to a single firmware rev makes support allot easier. We don't need to maintain multiple PC's with different IDE versions, or try to document and/or remember which machine has what version of firmware. If we stick with 1.5.8.0 can we easily 'downgrade' new Power Pmacs that might arrive with the v1.6 firmware? Can we use the firmware upgrade tool to download an earlier firmware version to a Power Pmac controller, and not have to worry about bricking it? Thanks, Kmonroe

I just installed the new IDE (v1.6) and went online with our development Pmac running firmware ver 1.5.8.0. If I'm online with the Pmac and try to open the System Setup Program from the 'Tools' menu, the IDE will crash. This happens every time I try to run System Setup. All the other tools seem to work fine and I can build and download with no problems. I have the 1.6 IDE installed in a virtual XP environment and have the same problem. Is this an IDE bug, or does the System Setup Program not play nicely with earlier firmware versions? Operating system: Win7 64bit.

That's a good question Curt, I don't know why we're not using it. We've done it for so long this way that I didn't even think about cutter compensation as a possible solution. I guess that's why it's good to ask questions sometimes. I'll look into 2D cutter compensation and see if that will work for our application. Thanks for the input. kmonroe

Which AntiVirus? Trend Micro OfficeScan

I know that the anti-virus software my company uses seems to interfere with the compile and make programs used by the Power PMAC IDE. I can get my C programs to compile when the anti-virus is running, but it generally takes 2 or 3 minutes. If I temporarily disable our anti-virus, the IDE will compile in less than 30 seconds.

I work with a Pmac application that runs a 2D profile using a Cartesian gantry. Part of the kinematic equation is an offset value that allows the operator to increase or decrease the size of the shape by the same amount on all sides, for example, to add 0.5mm to account for material ground off in a subsequent process. The procedure itself works fine in that the part shrinks or grows as desired, but since the offset operation effectively makes arcs (circle moves) longer or shorter, I notice that the velocity increases or decreases as required to maintain the original move time. Our application is particularly sensitive to changes in the programmed feed-rate. Is there a way to have the Pmac recalculate the block move time after the inverse kinematic equation does its thing? (I think I know what the answer will be, but I wanted to ask anyway...just in case). Thanks, Kmonroe

You may want to check the archive for the new IDE. I downloaded it twice and got errors when I tried to de-compress it. I tried a couple of different archive programs, as well as the native windows archive program. They all indicated the archive was corrupt. See output from one of the archive programs below: ! C:\Users\Desktop\Power PMAC IDE (01-13-2014).zip: The archive is corrupt ! C:\Users\Desktop\Power PMAC IDE (01-13-2014).zip: CRC failed in Power PMAC IDE (01-13-2014)\PowerP~1.cab. The file is corrupt ! C:\Users\Desktop\Power PMAC IDE (01-13-2014).zip: The archive is corrupt Regards, Kmonroe

Hopefully this is a fairly simple question. We have an x/y gantry, and one axis uses the x-coupled gantry algorithm. We will be using a laser interferometer to compare actual position to commanded. We plan to use the results to setup a comp table for both axis in the gantry, which leads to my question. When setting up a comp table for a gantry axis using two motors with the x-coupled gantry algorithm, do you setup a comp table for the leader motor, or both motors? Thanks, kmonroe

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

Ok. Thanks for the update Sina.