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 ?