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.