shansen

mshaver: Delta Tau can probably provide more accurate information, but if I had to guess I would say that registry access privileges at a minimum are required. I am pretty sure that the cross-compile toolchain reads registry keys to set up the path and other variables for compilation.

mshaver: I had a problem a couple of years ago with missing menu items in the IDE, and it turned out to be a problem with administrator privileges. Specifically, I had to re-enable UAC in Windows 7 (it is normally on by default) and then run the Power PMAC IDE with admin privileges. For some reason, menu items would disappear when UAC was disabled. Also, this problem only happened on one machine, so I never took the time to figure out what was wrong .

mshaver: Could you provide the details of the exception(s) that are getting thrown by the .NET program? This info would probably be very helpful in figuring out what the problem is. Also, if the connection to the Power PMAC cannot be reestablished until it has been rebooted, this suggests that something on the Power PMAC might be crashing. Has anyone logged in to the Power PMAC with a terminal and verified that the Delta Tau processes are still running (gppmac, ppmacserver) after the comms stop working? Even if the .NET program is leaving the TCP connection open, the Power PMAC should automatically shut it down after a timeout. But even so, I don't think this wouldn't prevent re-connections as the default settings allow many simultaneous connections.

Firmware v1.5.8.0 has Debian 5.0.10 (Lenny) and Mono 2.6.1. I think Debian has been upgraded to Wheezy in the new v1.6.0.30 firmware, but I haven't had a chance to test it out yet.

I would bet that this is an optimization issue. If you look at the definition of sqrt() in rtpmaclib.h, it accepts double arguments (not float). When you compile and link in debug, an optimization flag might be getting set, the end result being that the compiler automatically casts from float to double for you. Then, if that same flag doesn't get set when you compile and link in release, the compiler won't auto-cast. When it goes to link it tries to find a sqrt() function that accepts float and when it can't find one it fails. That is my guess at least. Try switching from float to double and see what happens.

I don't know if there is a way to do this through the DT IDE as of yet, but you can open a bash shell in Cygwin and browse to the appropriate directory and issue 'make'. You will (of course) first have to manually edit the makefile to include the appropriate flags. I have been using custom makefiles for a while (albeit through Eclipse, not the DT IDE) and it works just fine.

daves: I don't know if the Power PMAC IDE has a similar feature, but in Eclipse I can hover over any function and it will show me if the function has been declared in the right scope. For example, if I write some user phase code and type fabs() and hover over it, it shows me nothing (not defined). If I do the same thing for FABS(), I get the prototype and it has been bolded (see attached image). Maybe the Power PMAC IDE has a similar way of checking functions exist before compiling? At the very least, the compiler did give a decent error message relating to fabs(). Either way, it's probably a good bet that most functions you will be using for user phase or user servo code come from RtGpShm.h or rtpmacapi.h, so if the function doesn't exist within these header files it probably isn't available.

daves: I don't think fabs() is defined in the kernel (it's usually in math.h, which is for user-mode only). You could try including RtGpShm.h and using FABS() instead. In test.h: #include ... double DoTest(double arg1) { return FABS(arg1); } If you'd rather define it yourself, here's the macro: #define FABS(x) \ ({ double result, argx = (x); \ asm volatile ("fabs %0, %1" : "=f"(result) : "f"(argx)); \ result; })

mshaver: In Capps, you can do something like: double *RampRate = &pshm->P[8101]; I hardly ever use script or motion programs, so I don't know if they have an equivalent syntax. If they do, I would guess they would use the ".a" operator? Maybe someone who is more familiar with script can comment here. Also, check out page 365 of the Power PMAC User's Manual for comments about PVARSTART in pp_proj.ini which lets you specify which Pvar the first 'global' starts at.

Jeff, FWIW, using a custom driver I usually transfer 65536 bytes (equivalent to 8192 Pvars) every 5 ms without issue.

klauer: The variables you need to access are read-only in the terminal (gpascii), so you need to write a C program to load your module function. Here are some modified functions that I wrote for this purpose. If you have the address and want to load it, use load_isr_function_from_addr(). Alternatively, you can use load_isr_function() which will find the address for you (based on the function name you supply) and then load it. After your code is loaded, use enable_isr() to start executing your code! unsigned int find_isr_function( const char *functionName ) { FILE *fp; char *tail; char cmd[64]; char result[128]; unsigned long addr = 0x00; if( !functionName ) return -1; if( !pshm ) return -1; strcpy(cmd, "cat /proc/kallsyms | grep "); strcat(cmd, functionName); fp = popen(cmd, "r"); if( !fp ) return -1; while( fgets(result, 127, fp) ) { } pclose(fp); // if result == cmd, we didn't get a response if( strcmp(result, cmd) == 0 ) return -1; tail = strchr(result, ' '); addr = strtoul(&result[0], &tail, 16); return addr; return 0; } int disable_isr( unsigned char isr ) { struct timespec time = { .tv_sec = 0, .tv_nsec = 10000000 }; if( !pshm ) return -1; pshm->Motor[isr].PhaseCtrl = 0; // stop executing user phase interrupt nanosleep(&time, NULL); // wait 10ms (arbitrary) for ISR to stop executing return 0; } int enable_isr( unsigned char isr ) { if( !pshm ) return -1; pshm->Motor[isr].PhaseCtrl = 1; // start executing phase code return 0; } int load_isr_function_from_addr( unsigned int addr, unsigned char isr ) { // no need to validate ISR because maximum value of unsigned char is 255 if( disable_isr(isr) < 0 ) return -1; pshm->Motor[isr].UserPhase = (PUserCtrl) addr; pshm->UserAlgo.PhaseAddr[isr] = addr; return 0; } int load_isr_function( const char *functionName, unsigned char isr ) { if( !functionName || functionName[0] == '\0' ) return -1; unsigned int addr = find_isr_function(functionName); if( addr == 0x00 ) return -1; return load_isr_function_from_addr(addr, isr); }

symetrie, I have not used RTnet, but through Linux you can easily use Eth0 and Eth1 separately or together. For example, I have a custom Ethernet driver that uses Eth0 for a control port and Eth1 for a maintenance port. Also, I typically see less than 1 ms of latency for all Ethernet transfers less than 16384 bytes. But again, this is using the standard Ethernet through Linux, not using RTnet.

symetrie: This is correct behavior. When your mask is 255.255.255.0, octets 1-3 are fully masked (equal to 255). This means that any IP addresses where octets 1-3 are different from yours will be ignored. The PPMAC is on 172.23.1.169, so the 3rd octet is different from your PC (PPMAC octet 3 = '1', PC octet 3 = '0'). Therefore, the Power PMAC IP address is ignored. When your mask is 255.255.0.0, only octets 1-2 are fully masked. This means that any IP address that doesn't match octets 1-2 will be ignored. Because the Power PMAC is on 172.23.1.169, the first two octets match yours, so it will not be ignored. Short version: if the subnet mask specifies '255' in octet X, the IP address you are connecting to will be ignored unless octet X matches your PC's octet X.

Sina, Do you have a similar spreadsheet for the DSPGATE3s? If I'm understanding you correctly, we can have 2 ACC5E3s in a single UMAC rack, as long as the phase clocks are integer multiples. Here is what we are trying to do specifically: DSPGATE3 #1 and #2 - 27 kHz Phase clock (for MACRO ring #1) 9 kHz PWM DSPGATE3 #3 and #4 - 54 kHz Phase clock (for MACRO ring #2) 9 kHz PWM Power PMAC - 27 kHz phase interrupt Is this possible using ACC5E3s? It is very important that we can keep the Power PMAC phase interrupt at 27 kHz even though the max DSPGATE3 freq. is 54 kHz.

Is it possible to use 2 ACC5Es in a single UMAC rack (or 2 ACC5E3s) in order to get 2 MACRO rings that are running at different phase clock rates? I believe the answer is yes, but I just wanted to double check. Each 5E would be connected to a separate MACRO ring of course. We would like to run the first ring at 18-27 kHz and the second ring at 40-50 kHz.

Hello fellow Power PMAC users! Not too long ago, I wrote a simple library that lets you communicate between a Power PMAC and one or more Turbo PMACs over Ethernet. I figured I would upload it here so other people can use it too! (see attached Turboeth Project.zip) This library can be used to: Connect to one or more Turbo PMACs over Ethernet Read variables from a Turbo PMAC into Power PMAC variables Send variables from a Power PMAC to Turbo PMAC variables Automatically reconnect if the connection is lost Perform asynchronous GetResponse commands in addition to background polling As shown in the example, connections to Turbo PMACs can be created by any background Capp. The Capp can setup which variables should be polled (read from Turbo), which variables should be cmds (sent to Turbo), and how often this happens (poll rate). You can also monitor the status of the connection, and then take action if something bad happens. A cool consequence of the way this library is setup is that it can be used to mirror variables. For example, you can set it up so P100 in the Power PMAC is updated with the value of P100 in the Turbo. Then, all of your script and motion programs on the Power PMAC can read from P100, but the value is really coming from the Turbo! Feel free to modify or use this as you please, but as with any free software use at your own discretion. Good luck! Turboeth Project.zip

tweek: I wrote a simple program that printf's Motor[x].pDac, and I get a segfault when it executes. Examining the memory more closely, it looks like pDac is a pointer allocated in Delta Tau's program space. Therefore, this memory is not mapped into the process of our test program, which means a test program cannot access that memory. When I type Motor[x].pDac in gpascii, I get a human-readable return value: Ex: Motor[0].pDac --> responds with "Sys.pushm'. So, you should figure out where pDac is pointing for your system (probably to DSPGATE memory), and then map your pointer to that memory (e.g, Gate3[0].Chan[0].Dac[0]). TLDR; Cannot access pDac pointer directly, go to the source instead.

I did a simple C function a while ago based off of that block diagram just for fun. I haven't used it for anything, so it may have bugs. As a disclaimer, I don't work for Delta Tau so the way they do it and the way I did it may be completely different. I do remember having to guess at some of the variables, but I think I used most of them correctly. Hope it helps! ppmacservo.c

For anyone else having trouble, I found that both interfaces will not work unless the first octet of eth0 is different from the first octet of eth1.

Curt, I just ran into the same issue, but was able to fix it using Cid[4].dir=1 as suggested above. Will this fix be in the next firmware release? Any idea when the next firmware release will be?

Yes, I have restored factory (vanilla) images and custom images to Etherlite Power PMACs and everything works correctly. I have not used the Ethercat Power PMAC, but I have noticed that Ethercat firmware is present in the factory image. Extrapolating from the fact that the Power PMAC firmware can detect MACRO hardware and initialize it appropriately, I would assume that the same holds true for Ethercat (e.g. if you buy a PPMAC with Ethercat, the factory firmware will recognize this and initialize the Ethercat firmware). From what I understand, the same firmware works on all flavors of Power PMAC.

I have used several Etherlites over the past few months, and the software is identical to a UMAC-style PPMAC (the only difference in hardware is the possible Ethercat add-on). The firmware seems to figure out what hardware platform it is on and adapt (e.g. MACRO vs no-MACRO, Ethercat vs no-Ethercat).

Alan: EDIT: I just realized that your program must be linked correctly, or you wouldn't be able to run the program at all, much less get a segfault. If you are still having trouble, check out this tutorial on GDB to help you debug the issue: http://beej.us/guide/bggdb/ I attached a sample makefile and a test program that might help. Just copy it to the Power PMAC (I like to use WinSCP for that purpose) and then run 'make'. After it compiles, run test.out to see P0 increment by 1. test program.zip

KEJR, I can verify that read/write calls result in a primary to secondary mode switch for Xenomai threads. Whether or not that will cause a problem for your thread depends on your determinism requirements. If you require low jitter, try mmap'ing /dev/ttyS* and then use memory operations instead of read/write. This would only result in one mode switch (the initial mmap).

jhendges: The Power PMAC uses glibc, which includes the POSIX regex library. See: http://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html