gshort

OK, now I know what is supposed to happen I can see what is going on, although some of the things I'm doing have definitely had some unexpected and undesireable consequences. You're correct in your guess, Sina, that I have a background plc that is monitoring my motors and reporting errors to the MMI. It's also doing some clean up that was having unexpected effects. On detecting the following error it did the following: 1) jog/ 1..10; // Bring all the motors to a controlled stop 2) kill 1..10; // Disable all the motors 3) cmd "undefine all"; // Remove the motors from the CS 1) has the side-effect of enabling the motor with the following error and thus clearing the motor's latched following error which is why I didn't believe it was latched. My fault. 2) has the side-effect of hiding the fact that 1) had happened. As it wasn't obvious that the motor had been enabled in between the error being triggered and it being cleared. 3) I do this because its only when I enable the motor I put it in the coordinate system, so as I'm disabling all the motors in 2) I also remove them from the CS. However this has a further side-effect of disconnecting the Motor[x].Status[0] from Coord[x].Status[0] so although the motor has its FeFatal bit still set in Status[0], it no longer shows up in Coord[x].Stauts[0]. So if I remove 1) and 3) I get the Status persistent in Coord[x].Status[0] which is a good thing. It's a shame that this sort of error is not incorporated in Coord[x].ErrorStatus. Yet this does not appear to be the case. 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 ? Thanks again Graham

Thanks for your reply, Charles. I had already tried this. Unfortunately the FeFatal error that provoked the abort, is transitory. It lasts just a few clocks and then the following error disappears as the motors are killed. There is therefore no indication in ErrorStatus (or indeed Status) that any error occurred so programmatically it is not possible to tell the difference between a normal and abnormal termination. Yet there must be some difference in internal state that indicates an abnormal termination because it is indicated by the fact that "list apc" behaves differently.

I would appreciate some advice on determining when a motion script has aborted. I am controlling the execution of the motion script from a background C program. What I've found is that when the script errors, such as if I provoke an excessive following error (FatalFeLimit), it aborts as I expect but I don't really see any difference in Coord[x].Ldata.Status. It merely changes from 0x60 to 0x01 which is what happens on a normal termination of the script. I can see that "list apc" is correctly telling me where the abort has taken place which is useful but it is an awkward method to determine programmatically that an abort has occurred. Can you suggest a simpler method ? Thanks and regards Graham

This worked a treat. I could then see that PosSf was correctly scaling the follower. It also revealed that in my MMI where I display the motor position in engineering units, I need to take PosSf into the scaling equation. Thanks for this.

No, Curt. You were correct in your original presumption. It was just my bad wording. The physical move is intended to be identical but the motors have different encoder scaling. I was just trying to test it on the one set up I had which had physical motors. Unfortunately in this test rig, these two motors have identical encoders on them, so I thought if I changed PosSf I should get a different physical movement, just to prove to myself that PosSf was having an effect. In my experiment it changing PosSf appeared to make no change, but from your explanation it should have. So I'm thinking I messed up somewhere.

Hmm. I tried a very similar experiment but without your success. I was initially trying this with virtual motor as the follower, so there was no encoder. I then ganged up two physical motors but that had two identical encoder ratios, but I thought by changing PosSf I would get a different reported physical position. However that didn't seem to happen for me. I guess I must have made an error somewhere. If this is indeed how it is supposed to work, I'll wait until the physical machine is built and perform this experiment then. This was really a test to accelerate development prior to having the physical machine. Thanks again for your help in trying this.

I did experiment with PosSf. If I change it on a standard motor with ServoCtrl set to 1, I can see that this scales the Pos value based on the encoder position. However if I change the same motor to be a Gantry follower with ServoCtrl set to 8, it looks to me that changes to PosSf are ignored. Would you be able to check this your end ? Thanks Graham.

Is there a restriction that the scale factor for the encoder of a gantry command motor must be the same as its follower ? I'm experimenting with virtual motors and I can't seem to get them to work correctly if I have different scale factors between the two motors ?

Yep it looks like its Sys.ServoCount. Thanks for the pointer.

I'm actually setting up the Gather buffer from a background program, rather than using Plot. I had tried adding Sys.Time into the Gather buffer but this doesn't seem to work for me. If you try dump Sys.Time.a for instance you just get Sys.Time not a valid address to put in the Gather buffer. Am I missing something here ?

I plan to use Gather in rotary fashion (Gather.Enable = 3) and read out from the Gather buffer in a background program. Since this will be a "best effort" approach it is possible that if the background program doesn't get enough cycles it might miss reading samples from the buffer. Is there any indication back from the Gather hardware that an overflow has occurred ? Although there is not much you can do about it, it would be useful to be able to indicate that a loss in data has occurred. Thanks Graham

I would like to have my own configuration file for a background program. In my case this would be an ASCII file that the background program would read at start-up that I could affect it's behaviour. Is it possible to add such a file to a Power PMAC project ? I've so far failed to find a way.

Fair enough that it is expected behaviour from your perspective. It would be at least useful to add a warning in the docs.

I had a subprog that consisted of: open subprog EnableESTOPReset // Nothing to do close I was calling this conditionally from a PLC that is common to other projects and in those other projects this subprog had code in it to perform machine-specific functions. What I found is that when I called this from a background PLC, that PLC stopped with a status of 7 which according to http://forums.deltatau.com/showthread.php?tid=11&pid=16&mode=threaded means "7 == Stopped on a Called and non-existent program". The subprog does exist and is included in the symbol table and there's no error in the mapping of the subprog.

I just tried adding the extra dwell, but I'm afraid it didn't make any difference.

I am attempting to use buffer lookahead but need to change the CS to add or remove motors from it. I am following the example in the "Power PMAC Move Mode Trajectories 2011-01.pdf" manual on Page 65 which shows the following: dwell 10 // Stop lookahead execution cmd "&1 delete lookahead" // Delete buffer cmd "&1 #4->100C" // Assign new motor to C. S. 1 cmd "&1 define lookahead 10000" // Redefine buffer dwell 10 I've enhanced this to wait for the command to complete and check the return status: open subprog disableLookahead if (LOOKAHEAD_BUFFERSIZE != 0) { Coord[PARTPROG_CS].LHDistance = 0; dwell 10; Ldata.CmdStatus=1; cmd "&%d delete lookahead", PARTPROG_CS; sendallcmds; while (Ldata.CmdStatus > 0) {dwell 0;} if (Ldata.CmdStatus != 0) { send 2 "disableLookahead: delete lookahead failed, Ldata.CmdStatus=%d\n", Ldata.CmdStatus; } dwell 10; } close What I've found that this will from time-to-time fail with error 33 (buffer in use). When the failure occurs there has been a move before it but there has since been a dwell so I would have thought that the buffer was no longer in use. When the failure occurred I tried "holding" the motion script with a while loop on a P variable. I then tried manually deleting the lookahead buffer from a terminal window and I continued to get the buffer-in-use error: &1 delete lookahead; stdin:4:17: error #33: BUFFER IN USE: delete lookahead; delete lookahead; stdin:5:17: error #33: BUFFER IN USE: delete lookahead; delete lookahead; stdin:6:17: error #33: BUFFER IN USE: delete lookahead; delete lookahead; stdin:7:17: error #33: BUFFER IN USE: delete lookahead; delete lookahead; stdin:8:17: error #33: BUFFER IN USE: delete lookahead; Can you give me some ideas as to how to proceed with this ?

Thanks. I tried this but sadly there was no additional information output to the console.

I would appreciate some help with a crash I'm seeing inside a gpascii terminal. I first saw the crash when running GetResponse inside a background C application, but I've reproduced it here just using a terminal window. I was actually testing what happens when buffer lookahead is set up to use 4 motors in a CS when there is actually only 3 defined in the CS. I was expecting an error, and I get this error, however I wasn't expecting a crash. Referring to the attached screen shot. I have a subprog which I use to reset the environment. I call this from the terminal with: cx ldata.coord=1; call ResetPartProgEnviron; In the adjacent unsolicited output window are various send prints from inside this subprog which show the progress of the subprog: Port 2: Enter ResetPartProgEnviron Port 2: ResetPartProgEnviron - 1 Port 2: ResetPartProgEnviron - 1a Port 2: ResetPartProgEnviron - 1b Port 2: ResetPartProgEnviron - 1c Port 2: ResetPartProgEnviron - 1d Port 2: ResetPartProgEnviron - 1e Port 2: ResetPartProgEnviron - 1f Port 2: ResetPartProgEnviron - 1g Port 2: ResetPartProgEnviron - 1h Port 2: ResetPartProgEnviron - 1i Port 2: ResetPartProgEnviron - 1j Port 2: ResetPartProgEnviron - 2 Port 2: ResetPartProgEnviron - 3 Port 2: ResetPartProgEnviron - 4 Port 2: ResetPartProgEnviron - 5 Port 2: ResetPartProgEnviron - 6 Port 2: Exit ResetPartProgEnviron I then show that there is at this point no error in the CS by running Coord[1].ErrorStatus; in the terminal, which responds with... Coord[1].ErrorStatus=0 I've then listed my motion script which I know to generate an error in the CS: list prog 1 N65536M21 N65537S51 N65538M3 N65539F100 N65540G1X(-10)Z(-20)B10 N65541F300 N65542G1X0Z0B0 N65543M5 I then run it with... &1 start 1 ...and check the error status Coord[1].ErrorStatus; which is again the error I expect... Coord[1].ErrorStatus=18 However when I try and re-run the subprog to reset my environment, this time the gpascii terminal explodes: cx ldata.coord=1; call ResetPartProgEnviron; Illegal instruction root@192.168.0.200:/opt/ppmac# The unsolicited output window, this time shows it has started running the subprog, but never completed. More worrying is the fact that the terminal has crashed, and this is what I also see when I try to do this programmatically from my background C application. Any guidance on how to proceed is much appreciated. gpasciicrash.bmp

Run New->Project which brings up the New Project dialog box. In the lower centre is a check box that has the attached text of "Create directory for solution". This check box works in the sense that it creates a further sub-directory under the given solution directory, so if I create a new project called test1 and give the Location as C:\test and don't check the box, the project hierarchy is built in C:\test\test1. If I DO check the box it is created in C:\test\test1\test1. However I can't create a second project called test2 and have it share some files with test1 without manually moving the project files after it has been created. It's not a huge problem, but I would have thought it not an unreasonable requirement. newproject.bmp

I didn't find it hard to achieve :-) I would have thought that it would be fairly common to want to have multiple projects that are really just variations of one another i.e. they share some amount of files in common but have some files different. This was what I was trying to achieve. I had a project that used some motors as virtual, whereas a second project, they were physical motors. It wasn't actually very easy to achieve this. When you use the IDE to create a new project, there is a checkbox that asks whether you want to create a new directory or not. Yet this seems to be ignored. It always creates the new directory, so all projects appear to be in their own hierarchy. This is not really what you want if you want to share files between projects. That's perhaps why you hadn't come across this problem.

OK, I've created a couple of simple test projects that show the problem up. These are created from your new project wizard. I think I know what is causing some of the problem. It is that I'm creating these two projects in the same folder hierarchy. This doesn't happen by default from the IDE. When you create a new project you always put it in a new directory. I then copied the project/solution files manually into the same directory as an original. We need to do this as we want to share files between two projects. In the attached zip file there are proj1 and proj2 projects. Proj1 has a proj1.pmh which #define's TEST to 1. Proj2 has proj2.pmh which #defines TEST to 2. Now you can open each project and download them to the PMAC with no problems at all. Atul, you're right and I hadn't notice that the download log will show that both .ppproj files are downloaded, but even this doesn't cause a problem. The problem occurs is when you open Proj1 and then open proj2.pmh in the edit window. The download will then fail with a duplicate #define. Proj.zip

Yes, I've seen this issue as well from time-to-time. We had a theory that the IDE was attempting to do web access which was failing causing the hang. It does largely seem to recover although sometimes after several minutes.

I've attached a zipfile that shows the problem. down1.bmp shows a screen-shot of my project that downloads correctly. down1.log is a copy from the output of the download log. I then open sim.pmc which is not part of the project and contains subprogs that have duplicate names in the project. You can see this in down2.bmp. This time the download fails. Again down2.log is a copy of the download. down1.zip

I have noticed, what looks to me, a bug. I have two projects that have some files in common and some files different. The different ones contain duplicate definitions. For instance they have the scaling factor from motor to user units of a motor. So in one project, proj1 say I have a proj1.pmh that contains #define Z_SCALE 100000 and in proj2 I have a proj2.pmh that contains #define Z_SCALE 200000 If I open up proj2.pmh in an edit window while in the proj1 project, then I notice that proj2.pmh is downloaded into the PowerPMAC when I do a download and I will get a series of "duplicate definitions" for things like the Z_SCALE #define.

Thank you for your reply. There are a few issues with it however: 1) You can't do "pshm->Motor[6].CompPos.a" from a background C program. This would imply that CompPos was a structure with a field named "a", but it's a double. This syntax only works in plc/pmc programs. 2) I did try setting Target[] to &(pshm->Motor[6].CompPos) but after setting it, if I printed its contents it was set to 0 afterwards. It looks as if the Target array is pointing at an area that I can't write to. 3) Since posting this thread, I've also had problems accessing pshm->CompTable[x].Data. This also appears to fail and indeed crash the system. I've since found another forum thread here http://forums.deltatau.com/showthread.php?tid=107 in which Brad mentions that although its possible to Read the Data[] field from the background C program, it should not be used to set up the Data this way. For this GetResponse should be used, and that is what I've done. As you requested it, here is a fragment of the C program that I've cut from an old version of my program: pCompTable = &(pSHM->CompTable[index1]); pCompTable->Source[0] = motorNum; pCompTable->Nx[0] = numElements; pCompTable->X0[0] = start; pCompTable->Dx[0] = span; pCompTable->Ctrl = control; pCompTable->OutCtrl = 0; pCompTable->Target[0] == &(pSHM->Motor[motorNum].CompPos); pCompTable->Sf[0] = 1; I've now replaced this with something similar that performs a series of GetResponse calls to perform the same function. The GetResponse method appears to work fine. Again, what I was looking for was a definitive answer as to whether the CompTable structure should or should not be accessed from the pshm pointer. If the answer is no, and it would be good to have some background as to the reason why not, it raises a more general question as to what structures are available for access from a background C program via pshm and which should be avoided.