maxvoxel8

Update: The error occurred with Coord[x].GoBack set to 1. I tried setting it to 255, and it caused the PMAC to become unresponsive to the NC UI, which I also don't understand. Now testing with the value set back to 3. Update 2: The error still occurs with Coord[x].GoBack set to 3. So it seems that Coord[x].GoBack is not helping.

We defined a g-code which sets some variables and then fsaves. We are using the recommended code for sending a command: Ldata.CmdStatus = 1 cmd"fsave" sendallcmds do dwell 0 while( Ldata.CmdStatus == 1) We have found that sometimes (maybe one in 20 program executions) the program aborts while inside the while loop. I figured this out by setting a variable in the while loop and clearing it after. I found that the variable is set when the program aborts. It doesn't set any error flags that I've found when this happens. I found this previous thread which recommends setting Coord[x].GoBack to deal with a similar-sounding situation: http://forums.deltatau.com/showthread.php?tid=1041&highlight=sendall I set GoBack to 1 and we will see if that helps us. However I am confused about how Coord[x].GoBack behaves. According to the manual: "When this function detects (GoBack + 2) jumps back in the program while looking for the next command that creates equations of motion of sufficient time, it automatically recalculates the end of the most recently calculated move to bring it to a stop at its programmed endpoint, just as if there were a dwell command after the move." So it sounds as if a lower value of GoBack should simply result in the equivalent of a dwell 0 being inserted into the program. But I already have a dwell 0 in each loop. So does GoBack behave differently from the manual? Or is something else going on?

Ah, yes, the default NC UI machine state Running #define. When I get rid of that, yes, Running has the same issue. What I would need is a property that says the Plc is currently in a scan. But the Ldata.Address approach seems to work.

This gives me the index of the first active PLC, not necessarily the one the code is being called from. I thought maybe Plc.Running would work, but for some reason it refuses to let me evaluate this. It says "Error : ( error #31) invalid parameter number in conditional : if (Plc[L0]. 4 == 1)" on build and download, or ILLEGAL CMD: Plc[6].4 on the command line. This seems like a bug. What works for me is testing Plc[idx].Ldata.Address == Ldata.Address with the rest of the code the same.

I ask because we've been using Sys.CdTimer as recommended in the manual and we realized that there could be race conditions if a subroutine using a given timer is being called from multiple PLCs. So ideally we would use a different timer based on which PLC we are being called from.

Ok, that worked, thanks.

Ok, thanks. Are you sure there is no way to delay execution by issuing a system command or something like that? As an aside, I see there is also pp_inc_disable and pp_inc_startup. What are these used for?

I tried doing &0 #0->1X And then doing &0enable after Sys.AbortAll was set. It did not work. Isn't there some way that does not rely on enabling a motor?

In the manual it says: The Sys.AbortAll status bit is set to 1 when Power PMAC is stopping or has stopped due to the “Abort All” input, even if the input is no longer set in the abort state. Sys.AbortAll is set back to 0 when the input is not set and any motor or coordinate system is commanded to exit its final “abort all” state What commands cause exiting the final abort all state? We have been using &1enable for this, but we now can't do so anymore because the drives can only be engaged under certain conditions. As a workaround I tried defining a second coordinate system assigned to an unused motor, and enabling that also clears the flag. But I don't like this approach because we may need that motor in C.S. 1 at some point. Is there a better way to do this?

Yes, we have an initialize PLC and it looks like it does run as it should. The issue is that if we've changed some variables and we build and download, the variables get initialized, and then the fload loads the last-saved values. What we need is some way to automatically run fsave before the build and download process starts to save the current values. Is there any way to do that?

Thanks, that clears it up!

I am finding the documentation unclear on this topic. In the software reference it says, "If the top-level program is a motion program, the initial commanded acceleration profile for all motors must complete before the next command in the motion program is executed." for all jog commands. However I am finding that indefinite jog moves (jog+/jog-) behave this way, while jog= and jog: wait until the jog is complete before moving to the next line. Is this an error in the manual? Specifically, do I need to have a while(Motor[x].InPos == 0) {} after a definite jog in a motion program if I want to wait for it to end before continuing?

Is that defined in pp_startup.txt? We are using the default version which runs InitializePlc, and we do have fload in there. But that seems to only run when we actually restart the controller. Is it supposed to run when we just build and download?

We have a pp_custom_save.tpl script which saves some variables. But they are initialized to 0 in the header files. We find that when we build and download, the variables are initialized to 0, and we would like to automatically run fload to give them their last-saved value. How can we do this?

Thanks, I think that solved the problem.

I reproduced this problem on my Power PMAC Clipper with a minimal configuration. I had no actual motion hardware attached to the Clipper. I used the NC UI to run the Gcode, but also reproduced it just running from the IDE (Set RunOptions = 8 to enable dry run). The following plot shows this GCode running: G1 X10 F10 G1 Z300 G1 X20 G54 G1 X0 G1 Z0 With dry run off, everything is fine. With dry run on, everything is the same, except for a strange pause at the start of the "G1 X0" line. I've attached the PMAC source code that should allow you to reproduce this. sample.zip

We are not using kinematics, but we are using a transformation matrix as defined in the work offsets (I noticed the release notes mention that the pmatch command didn't use to work with that). In general, when pmatch is called, what is the rate at which it tries to match the coordinates with the motor positions? Is this a value that we can control?

I have tried the trajectory filter approach and it seems to have a problem. Let's say I'm suppressing Z motion and I have a program like G1 Z10 G1 X5 G54 G1 X10 A strange pause occurs in the last line, where the machine moves in X very slowly for a while, and then begins to move at normal speed again. I believe this must be caused by the pmatch inside the default implementation of G54, which I confirmed by trying the same program with just pmatch instead of G54 and seeing the same behavior. Without the trajectory filter, the same program runs fine. Perhaps there is some slew rate that I need to adjust to fix this?

Thanks, the trajectory filter approach looks like it could work, I'm testing it now.

Let's say for example I had a CNC router and wanted to make a mode in which the machine only moves in X and Y but not in Z for dry run purposes. I want to run the same exact G-code but not actually plunge into the material. I also don't want to mess with coordinate or motor scaling factors.

Yes, I am talking about G-Code. So for example if I want to suppress the X-axis in G1, and my axes are X and Y, I could do: n1000: linear read(X, Y) if (ArgPassVar & YargMask) Y(Yarg) But then if there are multiple axes, I have to check each axis argument, and have an if statement for every combination of axis arguments, which is messy. What I really want is something like n1000: linear readAll(X) or n1000: linear read(X, Y) unread(Y)

I know read(X) can be used to suppress the X argument if it appears first in the line, but is there some way to suppress the X argument regardless of where in the line it appears? Alternatively is there some way to read all arguments and mark only certain ones "unread"?

Thanks, but I already sent the clipper back and got another one which has not developed this problem.

FYI, I think we found the cause of the problem. It seems that in firmware version prior to 2.4.0, if a program has built up a non-trivial following error before the pause, it will not resume from the pause. If such a following error is present, subsequent programs did not reset the following error, and also would not resume from pause. Resetting the controller would reset the error and allow pause to work again until the error increased. After updating to 2.4.0.180, the following error seems much less for the same program, and resuming is always successful. I think this is related to the line in the 2.4 release notes, "When restarting a motion program after a Q (pause), S (step), or breakpoint stop, positioning axes do not have to be in the same position as they were in when the program was stopped."

The Power PMAC Users Manual, May 14 2018, p.523