Clopedandle

If you have the EtherCAT slaves's ESI file, or the device has its own file contained on itself, the setup software automatically maps/sets up basically everything for you.

Set up reporting by setting Coord[x].TPCoords to specify which axes to report and Coord[x].TPSize to the number of moves ahead you need to report. Then just use "t" to show the current target position. If you want the next target position, just query Coord[x].TPData[1].Pos[j]. Per the software reference manual, page 819, i = 0 is always the currently executing move, so i = 1 will always be the next move (i.e. while the moves are executing). Querying them after all the moves are done will not produce meaningful information.

Do you by chance have a USB drive inserted into the PPMAC? If so, make sure it does not have any of the folders with names listed in this post: http://forums.deltatau.com/showthread.php?tid=572 Especially make sure you do not have a folder named "PowerPmacFactoryReset" in the USB drive.

Can you explain why you would need to do that? Like Steve said, you can just use modulo to calculate the angle within 360 degrees. If you mean you need a hardware output pulse every 360 degrees, you could set up position compare and use the EQU pins.

You're welcome. 1. To start the program (assuming it's capp1.out) from a PLC, you can issue system "/var/ftp/usrflash/Project/C\ Language/Background\ Programs/capp1.out"; from another C program, use popen() or fork() and the path: /var/ftp/usrflash/Project/C\ Language/Background\ Programs/capp1.out 2. pshm->P[] and Set/GetGlobalVar are fundamentally the same. I prefer the syntax of the former. 3. I think you could safely push it to 0.001, although it may be pointless if your serial device is not providing data that fast. You can always try setting it that low and checking Task Manager to see if your CPU usage is going too high. 4. I believe it is atomic, but cannot remember completely. Perhaps a member of the ODT staff could answer? Curt?

You can do this. Just make sure to put nanosleep() in your infinite loop, or you'll watchdog the PPMAC. You should also create a break condition variable so you can stop the program when you want. You can write your message to a global variable for convenience. First, assign these globals in your global definitions.pmh file; something like: global MySerialPortMessage, MyBreakConditionVariable = 0.0; Then, in your C program, you can make a loop like so: while(pshm->P[MyBreakConditionVariable] < 1.0) { //Write out the command to read display on meter... ret = write(SerialPort, SampleCommand, strlen(SampleCommand)); //If write() does not return the requested number of bytes to write, we have a problem. //Pass return code on to the calling routine. if(ret != strlen(SampleCommand)) { Send(1, "Problem writing to port!"); // Send to PPMAC's Send1 port return ret; } //Read back the string into the "msg" buffer... ret = ReadSerialLine(msg, EXAMPLE_CODE_RESPONSE_MAX, '\n', SerialPort, 10.000); if(ret) { Send(1, "Did not get a response from port!"); // Send to PPMAC's Send1 port return ret; } pshm->P[MySerialPortMessage] = atof(msg); MySleepSec(0.1); // sec } Where void MySleepSec(double SleepTimeSeconds) { struct timespec Timer; Timer = Sec2TimeSpec(SleepTimeSeconds); nanosleep(&Timer,NULL); } and struct timespec Sec2TimeSpec(double TimeSec) { struct timespec Timer; Timer.tv_sec = (long int)TimeSec; Timer.tv_nsec = (long int)((TimeSec-(double)Timer.tv_sec)*1000000000.0); return Timer; } To break your loop, just write MyBreakConditionVariable=1 from any program or the Terminal window.

If you are not already, I suggest setting your drive to torque mode and letting the CK3E govern the control loop. It will likely be much easier to troubleshoot that way as you would then not have any of the drive's gains polluting your servo effort. I also remember in the past that there was a way to check if the distributed clocks were working by monitoring ECAT[n].DCClockDiff - see attached from the IDE manual, page 67. I am not sure if this still applies, however.

I suggest you run the System Setup utility and set the system up from scratch. Assuming everything is wired correctly, you should be able to finish the setup and jog your motor within 30 minutes. For detailed instructions on using the System Setup utility (in the IDE, click Delta Tau-->Tools-->System Setup), download the Power PMAC IDE manual from FileDepot: http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Manuals/Power%20PMAC%20IDE.pdf [FILE REMOVED] System Setup starts on page 22. This is likely a much faster approach than watching the online tutorials. It would also be smart to get the Power Brick LV manual. If you want to set up the motor manually, start on page 110 and follow the instructions until page 154.

The Position Compare feature would be more reliable for this, although its output comes from a dedicated connector, not from GPIO. See "Hardware Position-Compare Functions" starting on page 789 of the PPMAC User's Manual. It allows for digital outputs to be toggled at the exact programmed encoder count and will not miss any as the comparison is performed in hardware, not software. You just have to program your on/off positions (CompareA/CompareB) before you move to the "on" position. If you have uneven spacing, you have to set each one up beforehand. A common practice is to precompute all of the on/off positions, load them into Sys.IData[] elements beforehand and load them in to the CompareA/CompareB registers as you reach each position. This can be done in a simple subprogram call or you can use the capture-compare interrupt service routine (ISR) to do this. If you have even spacing, you can set up auto-increment, and PMAC automatically toggles the output as your motor counts pass through the preset spacing.

Try using Motor[x].SlewMasterPosSf.

Jack, Motor[x].SlewMasterPosSf limits the rate that the command is injected to the follower motor upon enabling the following feature. It basically ramps up to the ratio between master and follower specified by Motor[x].MasterPosSf.

If you poll the velocity in a background script PLC, PMAC will guarantee that the polling will not affect servo/phase/RTI performance. It literally only polls "in the background" (i.e. when the CPU has completed all performance-critical tasks and has time to do other things). This will not be quite as accurate as polling at a set frequency, but for the purposes of tracking lifetime distance traveled (we're talking big numbers probably), it should be OK. Make sense?

Yes, like Dave said, use a background PLC to integrate the absolute velocity value, write it to a global variable, and use the Fsave feature to write the value to memory periodically so that it persists across power cycles. See page 1090 for the fsave entry in the PPMAC SRM.

I noticed this happened a ton when I had a large number of "send" commands in Script PLCs. You could try commenting those out if you have any to see if it helps. I never did get a solution from Tech Support on that, come to think of it.

Unless I am mistaken, PMAC will automatically convert your M-Variable to a double equivalent when passing it to CfromScript, so you should have nothing about which to worry. As for using "null" as a return value, that looks wrong, but maybe it is something new with which I am not familiar. If I were you, I would just create a local variable named "dummy" or something to catch the CfromScript output as I have the feeling null might be reserved.