michaelthompson

Most or all of the internal Power PMAC data structures are accessible via gpascii. For example, Motor[3].JogSpeed will be correctly reported when running gpascii -2 or within the IDE terminal window. Likewise (with the side effect of polluting the global name space) we are able to create global P and M variables that gpascii can translate correctly. However, what would really be nice would be to have the same gpascii translation capability with our user-defined structures that we have with the Delta Tau defined internal structures. Example: typedef struct { int PLCIndex; double defaultSpeed; int param1; } MY_AXIS_DATA; typedef struct { int nAxes; MY_AXIS_DATA[5]; int param1; int param2; int param3; void* pPointer1; char* pLastError; } MY_APPLICATION_DATA; For this example, what I would like to make global is only a single name: MY_APPLICATION_DATA myApp; Then, within gpascii, I would like to be able to interrogate and modify my structure much like I can interrogate Delta Tau's structures. And it would be even nicer if the intellisense in the IDE supported this. myApp.myAxis[3].defaultSpeed=27 // set a variable within my structure myApp.pLastError // dump last error message text And even better would be if the BACKUP command would let me dump my entire structure or arrays the way that I can backup Delta Tau structures. BACKUP myApp. And getting even more ambitious, it would be nice to call properly initialized and exposed C subroutines by name from gpascii (much like the CFromScript allows C functions to be called from script language). For example: reportMotorDiagnostics(3,verbose) // user defined reporting Are any of these things already supported and I simply don't know about them? If not, how important is this to the general Power PMAC community. If most Power PMAC users are writing small applications, then populating and polluting the global name space with a few variables may not be a problem. Likewise, those users probably do not have a need for gpascii command language extension. However, for those of us with larger applications and the desire to organize our data in data structures (and someday classes with methods), this capability within gpascii would be a huge benefit. There are a few different common C/C++ scripting platforms that could be used as models (or even incorporated into a C app), but I figured that I would first check what Delta Tau (and its user base) has already done (or envisions doing). http://www.debian-administration.org/articles/264 http://csl.sourceforge.net/csl.html Of course, other tools like Ruby and Python could give access to the C data structures as well, but my real interest is for everything to be contained within gpascii.

Curt, Not as I see it. The C programmer simply builds up a linked list structure using a Delta Tau API so that it looks like an encoded motion program (not the trajectories) and then tells it to run. It's just a different (and potentially more flexible and powerful) way of creating the motion program, not an elimination or replacement for them. Delta Tau still maintains and controls all of the motion program logic (both create and execute). I'm not sure if you are familiar with C++, but I'm going to give this example in C++ because it reads nicer (and more closely to the motion program syntax). Just keep in mind that all of this can be done in C (just with lots of pointer passing). One really nice thing about C++ is that I can have my methods return a reference to the object (i.e. return *this). This sort of coding style allows you to concatenate successive calls to the same object which is nice in a situation like this where you are appending statements to a motion program. int cs=3; // coordinate system MotionProgram myProgram(cs); myProgram .linear() .abs() .F(20) .TA(100) .X(50).Y(80).Z(30).endl() .run(); In the above example, endl() is the statement end (like the newline character in your motion program). I didn't put it on each of the earlier lines so the above program is actually a one-line motion program. However, there is no reason why I couldn't do the following: myProgram .N(100).linear().endl() .N(110).abs().endl() .N(120).F(20).endl() .N(130).TA(100).endl() .N(140).X(50).Y(80).Z(30).endl() .N(150).X(20).endl() .N(160).F(10).Y(20).endl() .run(); Now, my motion program has statement numbers and some more variety. And I could even do neat things like this: printf("%s",myProgram.toASCII()); // write out as ASCII string or int cs=3; // coordinate system MotionProgram p1(cs); p1.import("xyz.pmc").run(); The above snippet would allow me to load a motion program from a file and then run it. I can think of lots of other powerful ways to utilize a MotionProgram class in C++ or data structure in C. This would be useful in some situations, but could possibly be accomplished with the motion program model described above. int cs=3; // coordinate system MotionProgram trajectory(cs); trajectory.P0(3).V0(2).A0(9).J(6).T(4).run(); That is of course a valid question, particularly with the work load your developers are already under. Perhaps it is not worth reconsidering your decision, and that is OK. We certainly require no new functionality. But again I am only trying to bring different perspectives into your thought process. The Power PMAC hardware, firmware, and software are already pretty darn powerful, but there is nothing wrong with making the environment even more powerful should the opportunity or motivation arise.

Curt, I believe that Delta Tau looked seriously at the possibility of building the C API interface for its motion programs. However, I have a difficult time accepting that what I specify via a motion program is really that much harder to do in C. Perhaps I've just been programming for too long (going on about 32 years now). At some level, the processing you describe all eventually has to be done. The real question then is about the data structures used to direct/control that processing and what sorts of interfaces you allow to manipulate those data structures. Even if you were to tell me that the internal data structures are ASCII streams and you interpret them on the fly, there are still ways that you can improve the way that a C programmer interfaces to the motion programs. I would assume that (somewhere internally) each motion program eventually becomes a linked list (or stream/array) of motion statements. And each motion statement is a linked list (or stream/array) of motion parameters (where TA, TS, F, X, Y, Z, etc. are parameters where some, like TA, TS, and F modify states). Running a motion program then is simply a matter of executing those linked lists, and creating a motion program should simply be a matter of building them. With the motion programs architected as linked lists of linked lists of linked lists (or even streams/arrays), it should be possible to do some interesting things like on-the-fly replacement of a program, statement, or parameter with another one (obviously, with proper controls to avoid collisions with the motion program executor). In any case, we can work with the existing architecture and interface. My post was really meant to probe the design space and get you guys thinking about different perspectives that different customers might have. I appreciate you taking time to entertain the discussion.

When we create a C function in the library (which is apparently dynamically rather than statically linked) and call it from a C application, the dynamic linking seems to be automatically resolved without any additional work on our part. We simply call the C library function like any other. However, when we try to do the same thing from a background C PLC, the dynamic linking no longer resolves automatically. If we want to access the function, we are forced to use the dlopen(), dlsym(), and dlclose() functions to access the dynamic library functions. Why is this the case, and is there anything that we can do to get the library functions to resolve automatically when called from background C PLCs? Mike

Brad, Thanks. That works. We also found the SetCSGlobalVar and GetCSGlobalVar macros. Curt, We are not interested in using the sprintf and command functions to fire off a one line motion program. We are already doing that to fire off the full motion program using a B{constant}R command and it works fine, but we would prefer to avoid the motion program altogether and simply build up the motion commands directly from within our C PLC (with no conversions to/from ASCII and no need to invoke anything but C API calls/macros provided by Delta Tau or encoded by us). Although there are no real problems with the motion program approach, it seems to me to be unnecessary to have to interface through a motion program when the motion program must eventually call some (probably hidden) API to build up the queue of motion commands to execute. If hidden, why can't that API be exposed? If not hidden, all we need is someone to point us to it with an example. What you describe in your final example is basically what we are doing (sometimes with multiple moves). However, as presented above, we would have no need for the Q variables or the motion program if we instead had C calls that allowed us to perform the same functions. Using your example, a simplistic C version might look something like this: int cs=3; CS_setLinear(cs); CS_setAbs(cs); CS_setF(cs,20); CS_setTA(cs,100); CS_moveX(cs,15); // builds up the move and adds it to the move buffer If (or when) DeltaTau supports C++ in its CPLCs, that same example might look something like this: CoordData* cs=&pshm->Coord[3]; cs->setLinear(); cs->setAbs(); cs->setF(20); cs->setTA(100); cs->moveX(15); In either case, there would be no need to invoke either Q variables or a motion program. We are finding that we can code virtually everything in CPLCs and C applications (and we are really liking that approach). The only things we use that are still not possible to encode in C are: -- global variable definitions (which is OK, the approach taken seems to work fine) -- motion programs (unless someone tells us how to interface to the motion buffers) -- any run-time / ad-hoc commands/settings/requests that we might encode in script language and/or import from an ASCII file (i.e. patches, overrides, etc.) For the last item, we have found some pretty powerful ways to use the toolsets provided. For example, suppose I want to load machine-specific settings, tuning parameters, etc. from a patch file that is executed at run-time. We simply have our startup PLC execute: system("gpascii -2 < mypatches.plc 1>mypatches.out 2>mypatches.err"); The system command runs the gpascii command which reads and interprets our patches. The stdout (1) stream is redirected to mypatches.out and stderr (2) stream is redirected to mypatches.err. Those files can then be read or tested to determine if any errors occurred while loading the patches. This is all really powerful stuff and is exactly why we want to do the bulk of our coding in C (or C++ if Delta Tau someday makes that option available to us).

Sina, Joe's particular question might be better stated this way: Most of our application is being written using CPLCs. We have found that we can avoid all Script PLCs. However, in order to execute motions, we are still assuming that the recommended method is to start up a motion program to perform the motion. If that is the case, then we need to communicate with the motion program through its coordinate system variables. It would be preferred to do that without having to form a string which represents the Q variable of interest only to have the Power PMAC library functions undo the format to obtain the Q variable index. So, the question can be broken down into two parts: 1. Is there a C library function that can be used to build a motion trajectory in a given coordinate system and execute it without requiring the use of a motion program? If so, can you point us to an example? For example, our motion program will perform an F(velocity) along with TA(acceleration) and then an X(position). Can we do this all from C? 2. If not and motion programs are still required, how can we communicate with the motion program without building up Q variable strings?

Thanks Sina. I spoke with Greg yesterday. When we spoke, I had just discovered the fundamental problem with the posted example. It was that the Gate[0].Chan[0].PackOutData value was not set to zero. The posted example does not set PackOutData to zero and assumes its default value. In my case, it had a value of 2. This apparently caused the servo command to not be converted properly to the pulse frequency. None of the documentation that I referenced while debugging had indicated that the PackOutData parameter needed to be set for pulse/direction applications. It turns out that it is critical. The following is my revised code which I am using to drive an Applied Motion HT13 stepper motor. I am microstepping 25,000 steps/rev and at a rate of 500,000 steps per second (20 rev/sec). Note also the use of deadband (KBreak and BreakPosError) to allow the stepper driver (Parker E-AC) to enter standby (low power) mode. If you don't apply a deadband, the PMAC will dither counts out to the drive. This constant dithering wakes it up so that it never goes into standby. Stepper motors run much cooler if you use standby power to hold position when no motion is requested. Deadband of at least one half step should probably be used in most stepper applications. Mike /****************************************/ // Power PMAC Script PLC Program Template. // The following Sample PLC PROGRAM is the standard template for creating Script PLC Programs. // Sample PLC PROGRAM // to test do: // 1) download the file // 2) type enable plc 3 // 3) type #1 out 10 and monitor the motor 1 status (should enable in open loop and send pulses.. // 3) type #1 k and follow with #1j/ and jog j+ to close the loop, move /****************************************/ close open plc 1 // --------------------User Code Goes Here------------------------ Sys.WpKey=$AAAAAAAA; Gate3[0].Chan[0].EncCtrl=8; Gate3[0].Chan[0].TimerMode=3; Gate3[0].Chan[0].PackInData=0; Gate3[0].Chan[0].PackOutData=0; // this is critical!!!! otherwise, pulse stream is not generated properly Gate3[0].Chan[0].OutFlagD=1; // enable pulse and direction outputs - phase D Gate3[0].PfmClockDiv=0; // control the Frequency division 100MHz/2^0 Gate3[0].EncClockDiv=0; // this value must be less than or equal to PfmClockDiv per documentation Gate3[0].Chan[0].PfmWidth=128; // controls the Width $f is default Gate3[0].Chan[0].OutputPol=2; // controls the Polarity - 0 default Gate3[0].Chan[0].PfmDirPol=0; // controls the Polarity of the Dir - 0 default Gate3[0].Chan[0].OutputMode=8; // PFM on Output Format (1) Sys.WpKey=0; //Motor 1 Setup Motor[1].ServoCtrl=1; Motor[1].PhaseCtrl=0; Motor[1].pDac=Acc24E3[0].Chan[0].Pfm.a; EncTable[1].Type=3; EncTable[1].pEnc=Gate3[0].Chan[0].ServoCapt.a; EncTable[1].pEnc1=Gate3[0].Chan[0].TimerA.a; EncTable[1].index1=0; EncTable[1].index2=0; EncTable[1].index3=0; EncTable[1].MaxDelta=0; EncTable[1].ScaleFactor=1/256; // setting motor Motor[1].pEnc= EncTable[1].a; // Position address Motor[1].pEnc2= EncTable[1].a; // Velocity address Motor[1].Servo.Kp=1; Motor[1].Servo.Kd1=0; Motor[1].Servo.Kd2=0; Motor[1].Servo.Kd3=0; Motor[1].Servo.Kd4=0; Motor[1].Servo.Kd5=0; Motor[1].Servo.Kd6=0; Motor[1].Servo.Kd7=0; Motor[1].Servo.Kvfb=0; Motor[1].Servo.Kvff=1.5; Motor[1].Servo.Kaff=0; Motor[1].Servo.Ki=0; Motor[1].Servo.Kbreak=0; // zero gain in deadband area Motor[1].Servo.BreakPosErr=1; // deadband of 1 count should keep stepper driver from coming out of standby power mode Motor[1].AmpFaultLevel=0; Motor[1].pLimits=0; Motor[1].pAmpEnable=0; Motor[1].pAmpFault=0; Motor[1].WarnFeLimit=0; // disable following warning (for testing only) Motor[1].FatalFeLimit=0; // disable followeing error (for testing only) Motor[1].MaxDac=32767; Motor[1].MaxSpeed=500; // 500 cts/msec = 500,000 cts/sec = 20 revs/sec @ 25,000 steps/rev Motor[1].JogSpeed=50; // 50 cts/msec = 50,000 cts/sec = 2 revs/sec @ 25,000 steps/rev Disable PLC 1 close /****************************************/

Has anyone figured out whether the Acc24E3 stepper example provided by laaguirre was correct? I am trying to set up a stepper with the Acc24E3 using his example (the IDE approach that I tried was not successful). What I am seeing is this: 1. Following error is counting up indefiinitely (fatal following error is disabled). 2. Motor position sometimes counts a few pulses at the start of a jog but will not count continuously. 3. I usually feel the stepper motor microstep whenever encoder counts up a pulse or two. 4. Tried lots of different divisors on both the PfmClock and EncClock. Can't seem to find any that work. What (if anything) is wrong with the example presented by laaguirre?

[quote='Sina' pid='1278' dateline='1296761066'] Jeff, You can use the Plot program under Tools menu to plot the Lissajous for ACC-51E encoder feedback. Just set it up based upon the following image: [/quote] Sina, We have a pretty nice Lissajous scope-mode program that we wrote ourselves and that we use with the Turbo PMAC and ACC-51E boards. See attached image. We have not yet modified the program to work with the Power PMAC. It is written in VB6 and my programmer has not been successful at interfacing from VB6 to the PMAC Comm Library. All that he needs is a GPASCII session, but he wasn't able to get it to work from VB6. I have the following suggestions as you develop the Lissajous support within the IDE: 1. Default to dot mode instead of line mode. When in line mode, if you move the axis fast, the lines zig-zag across the display. 2. Keep a buffer of N points to give the display persistence. Each refresh should hide the points which fell out of the buffer while showing the new points added to the buffer (or you can do a full refresh with bitmap paints if you prefer). With this sort of mode, as you move the encoder or jog the axis, you will get a nice circle of dots instead of zig-zag lines. When you stop moving, the dots will fade away until you are left with the dither of the encoder around the current position. 3. Display max and min signal strength values and allow them to be reset. 4. Scale the graph and signal level values in volts (or at least allow the option to switch between volts and A/D counts). E-mail me if you'd like more information. I can also have my programmer send you the source code and/or executable for your evaluation. Mike [attachment=261]

[quote='Sina' pid='1278' dateline='1296761066'] Jeff, You can use the Plot program under Tools menu to plot the Lissajous for ACC-51E encoder feedback. Just set it up based upon the following image: [/quote] Sina, We have a pretty nice Lissajous scope-mode program that we wrote ourselves and that we use with the Turbo PMAC and ACC-51E boards. See attached image. We have not yet modified the program to work with the Power PMAC. It is written in VB6 and my programmer has not been successful at interfacing from VB6 to the Power PMAC Comm Library. All that he needs is a GPASCII session, but he wasn't able to get it to work from VB6. I have the following suggestions as you develop the Lissajous support within the IDE: 1. Default to dot mode instead of line mode. When in line mode, if you move the axis fast, the lines zig-zag across the display. 2. Keep a buffer of N points to give the display persistence. Each refresh should hide the points which fell out of the buffer while showing the new points added to the buffer (or you can do a full refresh with bitmap paints if you prefer). With this sort of mode, as you move the encoder or jog the axis, you will get a nice circle of dots instead of zig-zag lines. When you stop moving, the dots will fade away until you are left with the dither of the encoder around the current position. 3. Display max and min signal strength values and allow them to be reset. 4. Scale the graph and signal level values in volts (or at least allow the option to switch between volts and A/D counts). E-mail me if you'd like more information. I can also have my programmer send you the source code and/or executable for your evaluation. Mike [attachment=261]

[quote='DavisG' pid='1216' dateline='1296135589'] Check and see that mysql is running. I have had the same problem when mysql was not properly set up during the install - it may be related to other instances of mysql running for other programs. [/quote] I think you may be correct that this problem is related to MySQL. The machine where I had this problem had MySQL installed before I installed the IDE. It also gets a bunch of database errors within the IDE.

Can we expect host names to be supported in the IDE at some point?

shansen, [quote]2) I am using the July 2010 release of Power PMAC Suite and I cannot get it to work properly in offline mode. Every time I attempt to type several letters in the editor, it freezes up for 30+ seconds. However, I do not experience this problem when I am connected to a Power PMAC.[/quote] For what it's worth, I have encountered this same problem (version 9/28/2010 1.1.2.45). I installed the IDE on another PC and did not have the problem. I have not yet tried uninstalling and reinstalling the IDE. I'm waiting for the next release of the IDE.

I figured it out. It compiles and links properly with the following command: [color=#000080]g++ -I /opt/ppmac/libppmac -I /opt/ppmac/rtpmac -L /opt/ppmac/libppmac -l ppmac -l rt [b]-Wl,-R/opt/ppmac/libppmac[/b] hello.cpp -o hello[/color][b][/b]

What about compiling C++ outside of the PMAC IDE system (i.e. at the Linux command prompt)? For example, I created the following file (hello.cpp) as an experiment: [code] #include #include "gplib.h" #include "RtGpShm.h" using namespace std; int main() { cout

Thanks Brad. I think that is exactly the information we needed. We have traditionally used the Ix08 and Ix09 values to scale units to work well with fixed point scaling in earlier PMAC versions while the coordinate system was used to translate to engineering units. However, we have always wanted to work in engineering units at the motor level (including servo tuning). The motor position and velocity scale factors should allow us to do that for position and velocity. However, although we can scale velocity units by 1000 to make them in terms of seconds, I think the accelerations and jerks would still have millisecond scalars in the units. Do you agree? What we really want to scale at the motor level is the position and time base units (i.e. each differentiation applies the time scalar).

Incidentally, do you know if it is possible to set the encoder scale factor such that 1 cnt = 1 engineering unit (i.e. 1 degree or 1 millimeter)? This, of course, would require very high gains and a coordinate system definition of 1, but it would allow many of the parameters to be specified in more convenient units (particularly if the velocity and acceleration calculations were based on seconds instead of milliseconds).

Yes. We figured out the WpKey issue today and now understand the commutation settings and various scale factors. We're now jogging our commutated motor and are in the process of tweaking the tuning and other parameters to our liking. One of the things we ran into during our PLC scripting was that we had to specify the AmpEnableBit and AmpFaultBit values at the end of the script, otherwise, the values we specified were changed (like some other assignment was resetting them). We haven't yet tried to figure out which assignment was responsible.

[quote='bradp' pid='1133' dateline='1295479088'] It is not released yet. When it is there will be a post on the forum and the link to the IDE will go to the new release. It is probably 2 weeks away. Do you need this specific feature or just want the newest? [/quote] Thanks Brad, We just want the newest IDE. We are having a lot of problems with the Motor Setup feature changing settings, forgetting settings, etc. It has frustrated us to the point where we avoid using the Motor Setup page at all costs. We did use it successfully for setting up an ACC-24E2A brush motor (one of your old blue demo boxes that we still have here). Incidentally, can you point us to a script example of a motor, encoder, and coordinate system setup for a commutated motor with sinusoidal feedback on the ACC-24E3. We have gotten various pieces of that working but can't seem to put it all together. Part of the problems we have been having are related to the fact that the Motor Setup screens were changing variables we had already set. And just yesterday, we discovered that there is apparently an order in which some of the variables must be assigned. For example, our latest discovery is that we can no longer set the AtanEna=1 (we had that working on Monday but not yesterday). When we change it in the terminal window, it accepts the command, but the value stays at zero.

[quote='bradp' pid='1121' dateline='1295374124'] This is fixed in the Jan 2011 IDE release. The problem was having the # character in the cmd string triggered some parsing logic in the build cycle that it should not have. [/quote] Brad, Is the Jan 2011 IDE released to everyone yet? If so, where do we find it?

The solution to changing the timezone under Debian Linux is to install the tzdata using: env http_proxy=http://user:pass@server:port apt-get update env http_proxy=http://user:pass@server:port apt-get install tzdata where user=username, pass=password, server=proxy server, and port=proxy port. Then run: dpkg-reconfigure tzdata and select your geographical region and timezone. Be sure to use a terminal session that supports escape sequences. When you are done, the only files that are changed/created in /etc are: /etc/timezone /etc/localtime These need to be copied to your /.readonly directory. I also used rsync to sync up the /var directory with /.readonly/var, but it is probably not necessary. There were some apt lists that were new after the install. You will also have the necessary files installed in /usr/share/zoneinfo. Reference the following websites for more information: http://forums.debian.net/viewtopic.php?f=6&t=15348 http://www.pc-freak.net/blog/how-to-change-timezone-in-debian-linux/

[quote='KEJR' pid='1117' dateline='1295367567']That is crap that they don't create a folder in code.[/quote] Agreed. And because it's the log directory, there isn't any log of the failure. I can't remember how I figured it out. I think I started the daemons manually and saw the message about not being able to open the log file spit out to the console. [quote='KEJR' pid='1117' dateline='1295367567']So in theory creating the log directory in /.readonly/var in addition to the instructions in my previous post would do it.[/quote] The directory was /var/log/samba. [quote='KEJR' pid='1117' dateline='1295367567']I'd be hesitant to copy all files in the /var folder to the read only equivalent only because you don't want to save every log file generated since startup to your flash drive.[/quote] I was hesitant for that very reason and rebooted right before my install. I also did a diff before syncing. [quote='KEJR' pid='1117' dateline='1295367567']While this is a pain in the butt I really have to hand it to Delta Tau for giving us a read only filesystem. I really like how we can just pull the plug on the PPMAC and not worry about "shutting it down".[/quote] It is a little extra burden during installs, but the benefits (known image plus fewer writes against the flash memory) are worth it. We just received our Power PMAC in Dec. 2010 and we really only started working with it after the new year. So we are still very early in the ramp-up. However, we've done some pretty neat stuff with it already and can already see what a powerful platform this is going to be for us.

Samba created a directory where its log files go. The directory is apparently not created by Samba processes if it does not exist. Moreover, as I recall, the daemons didn't start up because of the fact that the logging directory didn't exist. So far, I think it is the only package that had this problem, but it made me aware of the concern. As of now, I have only installed a few packages: CIFS Samba RSync NTP

KEJR, Thanks for the post. I have found that some packages touch /var in addition to /etc so it too needs to be copied in some cases. After the install, I use diff to compare /var to /.readonly/var and likewise with /etc. Regarding your example, what is the difference (if any) between copying from the /.readonly/etc-tempfs-mirror or simply copying from /etc. Aren't they by definition guaranteed to be the same?

I think we did that already, but I'll try again and let you know. I think the errors that are reported by tzselect are important. From other web queries about Debian Linux, there are files missing that should be there.