gshort

I have the following subprog: open subprog disableLookahead send 2 "disableLookahead: ENTER\n"; if (LOOKAHEAD_BUFFERSIZE != 0) { dwell 10; Coord[PARTPROG_CS].LHDistance = 0; dwell 10; Ldata.CmdStatus=1; cmd "&%d delete lookahead", PARTPROG_CS; sendallcmds; // Force commands from buffer while (Ldata.CmdStatus > 0) { send 2 "disableLookahead: IN LOOP Ldata.CmdStatus=%d\n", Ldata.CmdStatus; dwell 10; } // Wait for command to execute send 2 "disableLookahead: END LOOP Ldata.CmdStatus=%d\n", Ldata.CmdStatus; if (Ldata.CmdStatus != 0) { call StopOnError(ERR_DELETE_LOOKAHEAD_FAIL, 0, 0, -1); return; } dwell 10; } send 2 "disableLookahead: EXIT\n"; close This command works without fail in nearly all conditions. I follow it with a similar subprog that defines the lookahead prior to starting a script in the coordinate system to ensure that the lookahead is set up. The condition that fails is when I call this subprog after I have rebooted the powerpmac and have started running from a saved configuration. It never fails if I run it having downloaded the configuration from the IDE. The failure condition is that it gets stuck in the loop waiting for the command to complete: Port 2: disableLookahead: ENTER Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 etc. Following a download however, I get the following: Port 2: disableLookahead: ENTER Port 2: disableLookahead: IN LOOP Ldata.CmdStatus=1 Port 2: disableLookahead: END LOOP Ldata.CmdStatus=0 Port 2: disableLookahead: EXIT I would appreciate it if you could give me some ideas as to why the command never completes and indeed how I can debug the situation further. Thanks Graham

Thanks, Brad. We would like to have the next IDE release as soon as that's available as that will give us the option on how to resolve this.

Just setting Motor.ServoCtrl=0 isn't sufficient to prevent the watchdog. We will experiment with setting Motor.Ctrl = Sys.ServoCtrl when we get a chance but the machine is being heavilly used at present.

Thanks for the update, Brad. This is not a show stopper so we can wait for the IDE release.

Thanks, Sina, but that only really tells me half of what I want to know. It tells me how to control the ppmac before a download, but it doesn't provide me with the specific instructions of how a user servo can be safely disabled. It seems that if I do nothing then the ppmac goes into hardware watchdog, so this is a particularly severe state for the rest of my system. I'm looking for the recommended method from DeltaTau to avoid this condition. I would recommend that such instructions are added to the discussion on user servos in your documentation.

I have a second issue with user servo, which is different from the User servo persistence thread I just posted. I hit an issue when trying to build and download to a system that is running my user servo code. Whenever I do this the power PMAC goes into hardware watchdog. This does not happen if my user servo is not running. I presume I need to safely turn off the user servo. Can you provide me with instructions as to how I should do this and ideally have this performed automatically during the download process in a future IDE release. Thanks Graham

I have hit an issue with the setting up of a user servo from the IDE. If I use the "User Servo Setup" menu item from the Realtime Routines to select my servo code and then build and download, my servo works fine. If I close the IDE and some time later reopen it, the fact that I have previously selected a user servo does not appear to be saved in the project, so if I perform subsequent changes and do a new build and download, my user servo does not appear to be active. This is particularly true if I have to reboot the power pmac for some reason. When I go in to the IDE after the reboot, I have to remember to select the user servo each time before building and downloading, otherwise my servo will not be running. I would have expected this configuration to be saved in the project rather than my having to select it each time. There is some information being saved in the IDE as when I invoke the "User Servo Setup" menu item again it already has the name of the user servo function in the box for the motor concerned. I am using Firmware 1.5.8 and IDE 1.5.0.21 Thanks Graham

We've recently upgraded from version 1.3 of the Power PMAC Suite to 1.5.0.21. In doing so we have hit a problem that didn't used to occur. We used to share our sources for projects between the various developers on a development PC. We would check out the sources for the project from a subversion repository to a given directory and whichever developer was working on the project at the time could access the project and its files. This appears to not work under version 1.5. If developer 1 checks out to a directory, then developer 2 attempts to open the project then the IDE reports the error "The .ppproj project is too old for converstion, please upgrade your project manually, by creating a new project and transferring all your files to the new project.". If developer 2 checks out to a separate directory then the project opens with no problems. It would appear to be an issue with access control.

Many thanks, Curt. That works fine.

The documentation specifies values for Gather.Type as being in the range from 0..5 inclusive which specify various sizes of integer and floating point data. I observe however, that if you plot Motor[x].AmpEna a Gather.Type is set to 26566 and Coord[x].Ldata.Status sets Gather.Type to 50694. Since we want to control gathering programmatically and would like to have the option of adding any possible variable into the gather buffer it would be useful to know how to specify the correct gather type for these types of data. Is it possible therefore to have a more complete document on the values for Gather.Type. Thanks

Sorry, Curt. I can't reproduce it either now. I must have made a mistake, although I could have sworn I saw the g command have non-zero values for a new motion script for axes that I wasn't moving. If I manage to reproduce it again reliably I'll let you know. Thanks again for your attention.

Although you've paraphrased my question to some degree, the one thing that appears incorrect to me in this is if having aborted a motion script and start a new one and that then initiates a move, that the g command has its buffer cleared for all axes. As I mentioned if this second motion script never moves a particular axis that axis will still have a reported distance to go from a motion script that has been aborted and is no longer running. If this is the expected behaviour and this has to be cleared manually its worth at least pointing this out in the documentation, but it does seem wrong to me.

I've been using the g command successfully now, but have found one further gotcha. If I have a motion script that say moves the X axis by 10 which is aborted when it has only moved 5 for instance. If I then load another motion script which may not move X at all, the g command will still report that X has 5 units to move. After a subsequent move of X the g command reports the correct data, but until the move occurs the reported positions are incorrect. I'm finding a similar problem if I have a spindle which I then turn to a positioning axis. Its reported position from the g command after I stop it as a spindle and before I move it is incorrect.

Thanks, Curt. We were hoping to do it without issuing a command, as all our other MMI axis status are retrieved directly from the data structure.

OK, I've figured it out. I was performing the rapid move from a PLC. Until you run a motion script, TPExec.Pos[x] remain at nan. This is not ideal if you intend to monitor this from an MMI. When I run a motion script, I was rather expecting TPExec.Pos[x] to reflect the position for distance to go calculation. However it just looks to match what is in Coord[c].CdPos[x] i.e. the target demand for that axis. Whereas the g command, for instance, provides an intermediate position information for the time the command is run. Up to now, our MMI has not needed to run an online command to gain status information and we'd really prefer not to have to do this, especially as the status information we read is done on a per axis basis. Is there any way you can suggest us doing this i.e. does the intermediate position information exist somewhere in the Coord[c] structure ?

I've been trying to use the "distance to go" methods as described in the "Setting up Coordinate Systems" document. I have set Coord[1].TPSize to 1024 for now as I have lookahead set and set Coord[1].TPCoords to the bitmask for my coordinate system axes. If I have a watch on Coord[1].TPExec.Pos[x] for the axes of interest they all seem to be set to nan. Indeed all the 32 Pos[x] array elements appear to be that way. Additionally I tried to use the &1g command from the terminal window and got "No data to display" while the &1t gives "No targets defined", whereas "&1d" does report the current demands for the axes. I'm running on firmware 1.4.0.63. I'm clearly doing something wrong, any pointers much appreciated.

We'll need to do more testing to make sure that there are no gotchas but so far it seems to work a treat and does what we're looking for. Thanks for your help.

Well it doesn't seem to work for me. I would appreciate some pointers as to what I might be doing wrong. Here's an annotated series of commands sent to GetResponse... LOAD PART PRORAM Cmd "open prog 1" --> 0 "NO RESPONSE" Cmd "N65537 L1=1.000000" --> 0 "NO RESPONSE" Cmd "N65538 WHILE (L1==1.000000) {" --> 0 "NO RESPONSE" Cmd "N65539 G0.000000 X20.000000 " --> 0 "NO RESPONSE" Cmd "N65540 G4.000000 X1.000000 " --> 0 "NO RESPONSE" Cmd "N65541 G0.000000 X30.000000 " --> 0 "NO RESPONSE" Cmd "N65542 G4.000000 X1.000000 " --> 0 "NO RESPONSE" Cmd "N65543 }" --> 0 "NO RESPONSE" Cmd "N65544 M2.000000 " --> 0 "NO RESPONSE" Cmd "M2" --> 0 "NO RESPONSE" Cmd "close" --> 0 "NO RESPONSE" START PART PROGRAM - we first run a script (10000) to initialise the environment Cmd "Coord[1].pDesTimeBase=Coord[1].DesTimeBase.a;" --> 0 "NO RESPONSE" Cmd "&1 start 100000;" --> 0 "NO RESPONSE" Cmd "&1 b " --> 0 "NO RESPONSE" Cmd "&1 start 1" --> 0 "NO RESPONSE" PAUSE PART PROGRAM - what we call pause, which is feed hold Cmd "&1 h" --> 0 "NO RESPONSE" STOP PART PROGRAM - now stop the part program, which is the PMAC pause Cmd "&1 q" --> 0 "NO RESPONSE" ATTEMPT TO LOAD A NEW PART PROGRAM - this was a "&1 a" which does work but stops the spindle, now replaced with your suggested "cpx return" Cmd "cpx Ldata.coord=1; return" --> -38 "memory:136:1: error #38: PROGRAM RUNNING: cpx Ldata.coord=1; return " Cmd "open prog 1" --> -33 "memory:137:1: error #33: BUFFER IN USE: open prog 1 " ...any ideas what I'm doing wrong ?

I guess I'm still having a degree of confusion here, and this is why we have struggled to resolve this issue so far. To my mind the fundamental issue is that there is no on-line "stop" command. You can have a part program stop itself and run the stop command in the motion script, but for external control there is no "stop" equivalent. We are aware of the online "q" command but hit issues when trying to use a "q" and then reload a new part program, which is why we thought the only option was an "a". The "cpx return" is new information. However from your earlier post, I read the comment that "cpx return" was just setting the PC for the motion script. I assumed that the script itself remained in its "paused" state and therefore a new motion script can't be loaded into that CS. Can you confirm that the "cpx return" approach will allow this ? Have you also considered adding an on-line command version of the "stop" command ? It would seem like a simpler approach.

Thanks, that certainly improves matter, although there is still an issue. Using stop rather than abort in M02 certainly leaves the part program running. I think, however, we started using "abort" to be consistent with controlling the part program from a background C program. I didn't write this code and the engineer concerned is on his Christmas holiday already, so I can't provide all the details. However we have a requirement that we can stop a part program on user interaction at any point in the program. This is currently done by sending an "a" on-line command. In looking at the manual, I can't find an on-line equivalent of "stop". Is there such a command to perform this type of function.

Curt, since we intend to use buffer lookahead, we are using the ->s mechanism for controlling spindles. At the start of an RS274 part program the C axis (motor 1) is set to a positioning in the CS used for RS274 i.e. &1#1->200c. If I try the following RS274 part program: M21 S60 M03 -> Here we turn the motor to spindle mode i.e. &1#1->s0 as we use CS0 for Spindle Speed Override. G04 X5 M02 -> Here we perform an abort to end the program G04 X2 The abort in the M02 also stops the spindle. We need to be able to potentially load a new part program so we need the CS to be put in a state by the M02 so that this can happen, but I can't find a way of doing this while leaving the spindle moving. Any pointers much appreciated.

I am running RS274 part programs as motion scripts on a Power PMAC. I have a rotary axis that can be controlled either as a positioning axis or as a spindle. If I start the axis moving as a spindle (an M03 or M04) when the motion script ends, the spindle also stops. Can you advise on a method of leaving the spindle running on exit of the motion script ?

I think that's a bit harsh to say that I'm fighting them. What I'm trying to do is implement a policy that is laid down as a safety requirement in a consistent manner. The faults that you mentioned are only a subset of the source of errors that I am handling. The error handler needs to be running all the time to monitor for error conditions and depending on a classification of the error they may estop, stop motors immediately or coast motors to a stop. Yes in the errors you mentioned the motion script is aborted automatically and the offending motors automatically killed and other motors in the coordinate system brought to a controlled stop. However in the case of other errors this won't be the case and I'll need to handle them myself. Indeed as I need to bring all motors to a stop and, as you mentioned, there is no automatic handling of motors outside the coordinate system that has faulted, I have to deal with those myself anyway. So as we Brit's say "I'm doing me best" in an unfamiliar scenario. And don't get me wrong, I very much appreciate the advice given.

Thanks guys for your input, it has been very helpful. Fundamentally I am not trying to re-enable a failed motor from inside a PLC. What I'm trying to do is implement a safety policy requirement on the machine we're building. The rule this part of the code was trying to do was on a certain type of error, (of which the following error was an example), the motion program should be aborted at the point of detection and all motors should be brought to a controlled stop where possible (clearly for the motor in fault this may not be possible). It seemed sensible to me to have a PLC running all the time that did the monitoring as it is conceivable that such an error could occur when no motion script is running since for instance we have the ability to control motors from the HMI. This can interact with other PLCs running in our system to do the move (e.g. jog moves to start spindles etc.). So that's why I'm not doing this in background C, although I expect I could do it there. In terms of re-enabling the failed motor, I'm not trying to do that at all. I'm trying to bring all the other motors to a controlled stop. I understand that if the motor that fails in is in a coordinate system then it can in turn cause other motors in the CS to abort. However the failed motor may not be in the coordinate system, but I still need to stop all other motors as soon as possible. I naively thought that the "jog /" followed by "kill" of all my motors would do this. Although this is the effect I want, from your comments I believe I need a more involved approach in the motor stopping. In particular a) I musn't perform the "jog /" on a motor in error and b) since this is running in a plc context I need to wait for the motors to stop before performing the kill.

Graham wrote "One final suprise that I hadn't come across previously because I have been inadvertantly clearing the motor errors with the jog/ is that when I attempt to re-enable a motor that has an error I see that all the motors that are enabled are instantly killed and I have to go and enable them again. Is this expected and indeed can I control this at all ?" Ignore this comment. Further investigation showed this was also my fault.