ScottB

I have a question regarding lookahead on the Power PMAC and how to get arcs more accurate. We have a linear move at 2000 inches/min going into an semicircle with 0.1" radius at 330 IPM, followed by another linear move at 2000 IPM. Point A is where the semicircle should start and Point B is where the semicircle should end. The inner path shown is the actual path the PowerPMAC uses. What I was expecting to happen with lookahead enabled (Coord[1].LookAheadSize = 2048) is that the Y axis would slow down from 2000 IPM to 330 IPM at Point A so the desired path is maintained. The following is the same motion commanded on a Beckhoff control using their lookahead algorithm. You can see the Y axis Velocity slows down to 330 before the X axis starts to move. The path is maintained. The following plot is the velocity on the PowerPMAC. The Y axis does slow down but not slow enough when the X axis starts. The end result is that instead of a rounded slot, we get an egg shape. The only way we can get the shape to be close to accurate is to either program exact stops at points A and B (not desirable) or set the Ta and Ts very small (5 mSec) which causes the machine to shake pretty violently. Is there a way to get the lookahead control to reduce the velocity smoothly so that when it hits the tangent point of the arc, it is at the programmed arc velocity? I have tried explicitly specifying a feedrate on the arc, letting the acceleration limits of the motor slow the arc down, and using Coord[].MaxCirAccel to slow down the velocity of the arc. They all seem to yield the same velocity plot above.

I've successfully done the manually updating the driver in Windows 8 and 10 several times but today I ran into a new problem. The driver wouldn't install, I got the following error even when I was logged on as an administrator. The solution was to use "Run as Administrator" for a command prompt, then make sure I was in the C:\Windows\System32 folder and type DEVMGMT to start the Device Manager. This runs the Device Manager as Administrator and allows the UMAC driver to be installed.

Is there a way in the Power PMAC to determine what percentage of a programmed move is complete? We use Coord[].Nsync to determine which block is executing, but is there a way to tell what percentage of that block is complete? I didn't see anything in the Coord[] structure. I guess we could use the pread and tread commands to calculate it for linear moves but circular moves would be tricky.

I believe that it was added in firmware version 1.1 and is enabled by setting MI20=$30. That is what our Turbo PMAC code comments mention.

We are using Yaskawa Sigma V drives with a 85M Macro module connected to an ACC-5E card. The drives are in velocity mode and we are adding a thrust command to reduce following error. On the Turbo PMAC, we have an open servo routine that calculates the 32 bit thrust command and writes the upper 16 bits to the first 16-bit command register on the ACC-5E (Y:$78421) and the the lower 16 bits to the second 16-bit command register (Y:$78422). We are converting from Turbo PMAC to Power PMAC now. We have Motor[x].Ctrl Sys.PidCtrl and are a little confused about setting Motor[x].Servo.pAccOut. The manual says to set it to the address of a valid register and mentions Gate1.Macro[j][1].a or Gate3.MacroOutA[j][1].a when using MACRO. We tried using Acc5E[0].Macro[j][1].a but it seemed like the thrust command was very small and not changing sign, like maybe the upper 16 bits were always 0. We changed the pointer from Acc5E[0].Macro[j][1].a to Acc5E[0].Macro[j][2].a and it to appeared to work. Is this just problem with the manual? Where should we be setting the pointer so both 16 bit values are written correctly?

One of our servicemen captured the attached plot of the commanded position for a motor that is set up as an open loop, step and direction motor. The motor is being moved between two positions (0.43" and 0.20") with a "J=" jog command. The highlighted area shows an overshoot. Why does the motor overshoot its position when there is no real encoder signal or other feedback? I don't know if this caused a problem, I'm curious why the commanded position is not identical each time.

We are trying to get an older TURBO PMAC2-PCI ULTRALITE working with a new Windows 8 PC and we are not getting interrupts from the PMAC. We don't get them in our software and we don't see them in Pewin32Pro2 (using the View Interrupts option). Our symptoms are identical to this Closed Thread (http://forums.deltatau.com/showthread.php?tid=864) but I never see a resolution to his problem. The board generates interrupts fine on an older motherboard running Windows XP, so I'm confident that it isn't a jumper or board problem. One difference is that on the Windows XP system, Windows is using PCI interrupt 16, but on the Windows 8 computer, it is using PCI interrupt 18. Could this be part of the problem?

Thanks, that fixed it!

I am having problems with CIRCLE commands being skipped or ignored. I have a linear move followed by a complete circle, the following is a portion of the program N34F200LINEARX128.39400Y10.00000 N35F100CIRCLE2X128.39400Y10.00000I130.00000J10.00000 ..... N69F200LINEARX128.44872Y9.58434 N70F100CIRCLE2X128.44872Y9.58434I130.00000J10.00000 The circle on line 35 executes but the circle on line 70 does not. If I move the start point around the circle it works when it is at 180°, 210°,240° and 270° but it skips the circle at 195°, 225° and 255°. We are using absolute vector mode for I and J, ABS(I,J) is at the beginning of the program. Our SegMoveTime is set to 1, I tried larger numbers but no change. If I change from CCW to CW circles (CIRCLE2 -> CIRCLE1) some circles are still skipped but not the same ones. Is there a tolerance value that determines when a complete circle is executed and when a small arc is executed? Our start point and end point are identical to 5 digits so I don't see how this could be an issue. As a temporary work around, I broke the CIRCLE into two 180° pieces. This works for now, but I can't tell our customers that they can't program full circles.

I was missing the .NetPath.ldt.gpg file in my download folder. That was causing the error string "Error: on gpg command, rtnstatus = 512" . Note: When this happens, the download fails and Download.DownloadResults.Errors returns 1 string (above) but Download.DownloadResults.TotalErrors is 0. This seems like a bug to me.

It looks like this only works if you don't use encyrption. Is there a way to may it work with encrypted files and projects?

I made some progress after copying the entire "downloadtools" folder under my Window application folder. It is is now building and downloading my PPMAC project. Any additional documentation of the Download class would still be greatly appreciated.

I appreciate the assistance. Is there any documentation available for the classes in PowerPmacBuildAndDownload.dll? I couldn't open the example project without getting an error, so I created a new Winforms project and added Form1.cs into my new project. It builds OK and "Select a project to Build" says it works OK (although I don't think it does anything), but "Select a project to Download" crashes with an unhandled Win32Exception in DownloadAllProgramsRSYNC() -> "The directory name is invalid". All the parameters being passed to DownloadAllProgramsRSYNC appear to be valid.

We would like to update the project in the Power PMAC from our Windows HMI application so the end user does not need access to the IDE. Our project is fairly simple, no C files, all script files (pmh, pmc, and plc). I've got our application FTPing the project files to the "/var/ftp/usrflash/Project" folder on the PPMAC, but I don't know what to do next. Is this possible to do without using the IDE? I've searched through all the slides and App Notes and can't find any information.

I am trying to use the Plot tool to display a simple XY plot with my X Motor Actual Position as the Horizontal axis and the Y Motor Actual Position as the Left Axis. Is there a way to force the scaling of the vertical axis to be the same as the horizontal axis? Without this, my arcs end up looking like ellipses.

Steve, Thanks for responding. I ended up calculating the free memory by using the Coord[].RotStore and Coord[].RotExec values, but I am going to change my logic to use Nsync instead. Scott

I am trying to set up and use a rotary buffer for a motion program and I'm having trouble determining when the buffer is empty. The "ROTFREE" command in the SRM says that it will "Report number of unexecuted lines in rotary buffer". If I type: define rotary 10000 rotfree I get 9988, so I guess this is really returning the number of bytes free, not the number of lines remaining as the manual states. Now if I type the following: open rotary N100 x10y10f100 N110 x20y20f100 n120 x30y30f200 Close rotfree I get 9877, which makes sense, the amount of free memory decreased. The problem is that if I issue the Run command so the program starts, the rotfree command always returns 9877, it doesn't increase as the lines are executed. If I do a "list rotary" command, the lines are gone, but the rotfree command doesn't reflect this. The only way I've found to get Rotfree to increase again is to delete the rotary buffer and define a new one (not very useful). If the ROTFREE command doesn't work, how can you determine when the rotary buffer is getting empty? I noticed through Intellisense that there are Coord [].RotLine, RotFill, RotEnd status variables but these aren't mentioned in the manual at all. Is there any documentation for these?

Is Source Control integration with the IDE supposed to work? We use Visual Sourcesafe for source control and I can't get this to work with the Power PMAC IDE even though based on the menus available, it should be available. I saw a couple posts on this forum from 2011 where people had trouble with the IDE changing the read-only attributes on files when the solution was opened and the IDE is still doing this in 2015. This makes it very difficult to work with Visual Sourcesafe.

[quote='wehg' pid='8149' dateline='1437663862'] I use the '\' on occasion in script for line continuation and it seems to work fine. [/quote] I wasn't aware of that, thanks. That helps break up long lines although the text editor in the IDE doesn't like it, it marks the lines with the red squiggly underline.

I'm not sure I understand, I thought standard C ignored whitespace. IF ((M1 == 0) && (M2==0)) is supposed to be identical to: IF ((M1 == 0) && (M2 == 0) ) and is identical to: IF ((M1 == 0) && (M2 == 0)) This is not the case in Power PMAC script (although it was in Turbo!). If this is never going to be "fixed", then is there at least some type of line continuation characters that we can use to break up extremely long lines?

[quote='bradp' pid='80' dateline='1226700531'] [quote=DT-Europe] In a script PLC, how can we have a IF statement with conditions on multiple lines. As a very simple example for testing purpose, I tried following things without any success: IF(M2000 == 1 && M2100 == 1) IF(M2000 == 1 && M2100 == 1) IF((M2000 == 1 && M2100 == 1)) IF((M2000 == 1 && M2100 == 1)) When very very long conditions, we need multiple lines. [/quote] We will look into this and see what can be done. Look for more information in awhile. [/quote] Has this been fixed yet? Hard to believe in 2015, that you can't break complex conditional statements into multiple lines.

Brian, The jerk limit for this machine was given to me by the director of engineering many years ago and he has since retired. I suspect he arrived at this value empirically but I don't know what process he used.

I appreciate the comprehensive reply. I spent quite a bit of time yesterday trying various values of ixx40 from .01 to .99 and the only values that had any significant effect on the jerk were extremely high values (~0.99) but then the actual path was so far from programmed path, it was not useable. A little more backgound of what I am trying to do may help. Max Acc/Dec = 1.65g Max Jerk = 18,000 in/sec³ We have a linear move at a high feedrate (2000IPM) followed by a 0.125” diameter arc at a much lower feedrate (400 IPM) then another long linear move at 2000 IPM. We calculate the TA,TS to keep the above limits and we end up with TA=95, TS =41. The feedrate of the arc is actually slowed to 126IPM to keep the move time of the arc greater than TA. The result is shown in the following plot: Because of the long blend times, we end up with a tapered slot instead of a slot with nice round ends. To try and fix this, I turned lookahead on and then reduced the blend time between the linear moves and the arc to TA=10, TS=5. This appears to work on paper, because the actual path is very close to the desired path but when it is run on the actual machine, it is noticeable louder, you can feel the machine shake and the following error becomes excessive. The following plots show this motion. The first plot shows Velocity and Acceleration and the second plot shows the jerk. The acceleration is staying within our limits but the max jerk is over 100,000. Is there anything I am missing? Using your car analogy, the driver is slowing down in advance of the corner, but he is mashing on the brake and accelerator, not smoothly applying them. If I can’t get lookahead working for me, my next approach will be to split the linear move leading into the arc into 2 pieces with a short “slow down” zone before the arc and do the same thing with the linear move leading out of the arc.

I am experimenting with using lookahead mode to get sharper corners during high speed moves. The problem I am having is that the jerk becomes excessive. Our existing application doesn't use lookahead and calculates the minimum TA and TS between each move to keep the acceleration and jerk limits within machine configuration settings. I thought I would be able to just turn lookahead on and then reduce the blend times to get sharper corners. This works to some degree, the corners are sharper and I can limit acceleration with Ixx17, but the Jerk goes through the roof. Even if I leave the TS value alone and just make TA = 2*TS, the Jerk goes up by a factor of 3. (Without lookahead, TA 95 and TS=41 and Jerk was 14000 in/sec³, with lookahead turned on, TA=82, TS=41 and the Jerk went up to over 40000). Is there any way to limit the jerk when using lookahead? I noticed in the PowerPmac manual that Motor[x].InvJmax is used to set the maximum jerk for a motor and it says that the legacy I-Variable alias for this is Ixx18, but there is no mention of Ixx18 in the Turbo PMAC SRM. Does Ixx18 exist in the Turbo PMAC? I appreciate any insight or advice. Scott