Clopedandle

Remember also to use a nonzero (and usually quite small depending on the system, ~0.001 for example) Motor[x].Servo.Ki to ensure 0 following error at steady-state.

Try using Iterative Learning Control, a feature in the Tune tool. Also, introducing a small deadband with positive deadband gain can help with that "last bit" sometimes. That would be a Motor[x].Servo.Kbreak > 1.0 and 1.0 > Motor[x].Servo.BreakPosError > 0.0. Careful not to use too big of a Kbreak or too big of a BreakPosError as this can introduce chatter, which would actually worsen your performance.

"User too stupid error" THAT made me chuckle

All Gate I/O pointers must explicitly be defined as volatile. Digital I/O data (including GPIO) must be referenced as unsigned int only. You should only use masks on unsigned data.

Yep it connects as an I/O device. Believe it or not I actually wrote an app note on that already. I think it's here: http://forums.deltatau.com/filedepot/download.php?f=Power%20PMAC/Application%20Notes/EtherCAT/Using%20Micro-Epsilon%27s%20IFC2451%20with%20Power%20PMAC.pdf [FILE REMOVED]

Hey Michael, It was a 460 Power UMAC CPU if I recall correctly, so I think the older EtherCAT stack (I forget the name, whether Etherlabs or Acontis).

This is a helpful list. Thank you. I just want to add that Micro-Epsilon's Confocal DT also works with Power PMAC on EtherCAT.

Make a thread in your host program to poll variables/structures (whatever you are trying to gather) at a set period. That is as close to real-time data gathering that you can achieve without purchasing the PDK, which has built-in real-time gathering tools. Remember to poll something in gpascii -2 mode, all you have to do is query (i.e. send down the variable/structure name to PPMAC) (e.g. send down Motor[1].Servo.Kp and PPMAC responds with the current value). To change the way PPMAC replies, you can set the "echo" parameter. echo 7 makes PPMAC respond with just the value, omitting the structure name, in the current communication thread.

Talking to PPMAC through Linux with your own driver should not be too bad. For example, if you want to go with Python on Linux, you can use Paramiko, which is a native SSH implementation: http://www.paramiko.org/ Or others: https://wiki.python.org/moin/SecureShell Connect to your PPMAC IP Address (default 192.168.0.200), port 22 It will request a username, which is "root". Password is "deltatau" After that, issue "gpascii -2" Then, you can issue commands as though you are talking through the IDE. This naturally will not be as fancy or nice as the PDK, but you can do virtually anything you need still.

The data gathering functions in the PDK are really nice. I suggest you check them out. You can even generate live plots.

Davis, Do you mean save the values of certain variables? Check out fsave/fload on page 1055 / 1489 of the PPMAC SRM or FastSave() if you want to do it through C. Reckon you can check FastSave() through the F1 Help menu in the IDE. I also posted a totally custom fsave function a couple years ago on the Forum, but it's better to go with the "factory-approved" method now that it exists.

I seem to remember needing to set PhaseTableBias to -512 for certain DC brush motors to get a better-looking current loop response.

For background C applications, there is no "easy" way to know. You can technically issue the "top" command to the system shell: system "top" and then parse the response to see if your program is listed (e.g. capp1.out). Top is a Linux command that shows running processes: http://www.tecmint.com/12-top-command-examples-in-linux/ There might be a cuter Linux command out there, but I am not an expert on it. It is much easier, though, to put a global variable that increments as the program runs, for example, and then just check if that variable is incrementing to verify that the program is running.

Replying to myself, after speaking to a Cognex rep., they do not support EtherCAT. Never mind then!

Has anyone here tried to use Cognex In-Sight cameras over EtherCAT by chance? If so, is it pretty much plug-and-play, or is a lot of painful XML hacking required in order to map the PDOs?

If you have two separate motors using the same physical flag for homing, you have to point Motor[x].pLimits of both motors to the same hardware channel (e.g. PowerBrick[0].Chan[0].Status.a for both if using channel 0) into which the home flag is wired. Otherwise by default, your Xb will probably be looking at a channel that has nothing wired into it.

Do PREAD and DREAD execute synchronously (i.e. their calculations complete before the calling PLC advances)? Or do they require some delay after being issued before reading the positions in D-Variables? Thank you.

Feedback resolution acts as a servo loop gain, so yes, you have to compensate for it when changing feedback source. I wrote an example of this a while back here: http://forums.deltatau.com/showthread.php?tid=1903&highlight=change+encoder I believe changing the position loop scale factor was sufficient since it scales the servo loop gains.

I suggest that when you send down your command to start running the motion program, you write the system time to a P-Variable in the same transmission. As an example, supposing you are using motion program 1 in coordinate system 1, send down this: P1 = Sys.Time &1 b1 r Then, in your motion program, let the first line store the system time like this: open prog 1 P2 = Sys.Time // put other motion program code here close Then compute P3 = P2 - P1 and that should be a pretty good estimation of the time difference (in units of seconds).

If you know PID and programming, you will likely do very well in the training. You can download the whole slides from FileDepot and read through them in advance. If you have some of your own hardware, you can probably do all the exercises. Just email support to ask for a virtual motor file if you do not have real motors or do not want to move the ones you have.

Does this have to be generated through user-written servo code? It would be easier and have less jitter to use a PWM channel on an ACC-24E3 or similar Gate3-style axis interface. There are built-in structures for PWM signal generation -- see the Power SRM under Gate3. You can also do this through the EQU output on a Gate1 or Gate3 chip using a virtual motor, in case your PWM channels are consumed, that would be more precise than servo code -- I believe there are some application notes on that in FileDepot showing how to do this.

Can you clarify a bit regarding what you mean by "rate loop"? If I am not mistaken, if you do not want servo effort contributions from the velocity loop, you can set Motor[x].Servo.Kvfb = 0 and Motor[x].Servo.Kvifb = 0. Generally here you would also set Motor[x].Servo.Kvff = 0 and Motor[x].Servo.Kviff = 0 at the time time. You can also choose to use position command output only -- see page 298 of the PPMAC User's manual. It lists various different servo algorithms you can use.

J0hann, Yep I sure did, but they are not on the forums. Check the ACC-72EX manual starting on page 85 for the set/get functions: http://www.deltatau.com/manuals/pdfs/ACC-72EX.pdf?id=635787783278301396

If I recall correctly, just put an ampersand on the desired argument. I'll modify your example below: // generic actuator function: open subprog extend(&solenoid, limitswitch) solenoid = 1; while (limitswitch == 0) {} close Code: // component that uses it: ptr GripperOpenSolenoid -> ECAT[0].IO[15].data ptr GripperOpenLimitSwitch -> ECAT[0].IO[16].data open subprog OpenGripper(void) call extend(&GripperOpenSolenoid, GripperOpenLimitSwitch); close

The examples you seek are in the Application Note titled "Saving Files on Power PMAC or External Media". It's available under FileDepot-->Power PMAC-->Application Notes. I strongly suggest you use KEJR's approach of limiting how often you write to the device in order to limit wear.