KEJR

Hi Sina, Does the etherCat setup wizard allow you to see what the config is such that you can copy the text to a setup file? We prefer to have setup in text files if at all possible. Can we map pointer variables (Mvars) to the ethercat data structures for IO? We have been waiting for fast networked servo and compact IO in a unified environment for quite some time, this is great news. Just as an aside, have you guys done any testing on the Beckhoff IO over ethercat with regards to turnaround time for a loaded module? We found in the past that the Wago modules *seemed* to be limited by their internal bus that connects the IO "slices" together, or by electrical time constants of the IO modules. We were driving something like 128 bits of IO over 12mbit profibus and found it hard to have a 1ms update rate. Keep in mind this was approximately 10-11 years ago, the technology may have gotten better. This was based off of a Profibus card driving something like 128 digital IO lines. KEJR

Thanks Adrian, I'll take a look at what you said and see if disabling intellisense helps. Maybe this is a good excuse to get a fast laptop for the manufacturing floor. KEJR

Hi Davis, I'll give this a try. I have not intentionally installed MySql, but it may have been included in some program. KEJR

Just for reference, I went back to my office PC which is a Pentium 4 D CPU at 2.8GHz, also with XP SP3 and plenty of memory. The editor lag is not hardly noticeable. The other difference is that my office PC is hard wired ethernet, where as the PC on the floor is currently wireless. My project is located on a network drive in both cases. I'll try moving the project to the local drive on the slow PC as a test. KEJR

Hello, Has anyone else experienced latency problems with the Feb 2011 release of the IDE? It is very often taking me several seconds before a typed character is displayed in an editor window. It appears to be intellisense related in the background C programs editor window. My computer is a Athlon 64 2.2GHz running on XP with plenty of unused physical memory. I know the computer is dated, but we usually get "hand me downs" for the manufacturing floor. Is there a way to turn off intellisense in the IDE, this is not tolerable. I'm considering running my emacs editor, which kind of defeats the purpose of using the DT IDE! :o) Thanks, KEJR

+1 The only down side is that every value is a double, but I've found this to be insignificant for my work. YMMV. KEJR

Hello, I am also interested in EtherCat. I've seen pictures of the trade show demonstration which looks like the PowerPMAC is talking to a Beckhoff "slice IO" rack as well as various drives. Are these EtherCAT devices configurable through simple text file setup, and can we map M vars to the IO bits and analog IO registers on something like the Beckhoff IO? We have been developing alot of software routines that access IO through the Ptr var constructs and would love if that worked for third party EtherCAT IO. Thanks, KEJR

Check out this thread on the subject: http://forums.deltatau.com/showthread.php?tid=159&pid=329&mode=threaded

Just an update for anyone reading this, the macro I vars above i999 are now accessable. Feb 2011 release worked. Thanks!

I also saw the vipre message, but my IDE appeared to have installed correctly. Just a note.

Just a note: If you are using a Xenomai scheduled periodic thread (I belive C PLCs are such) you can use the following: pthread_wait_np(NULL); Which is a call to the scheduler to essentially skip this thread until next period. Note that if you know something about RTOS systems you can create your own periodic threads, which is helpful if you want to control their execution. I like to define a helper function that makes it less ugly though: void Yield(void) { pthread_wait_np(NULL); } So in your user code you just have: while(SomeExpression) Yield(); or: while(SomeExpression) { DoSomething(); Yield(); } I think its cleaner, but everyone has their own preference for such things. KEJR

I am having difficulties after installing the Feb 2011 IDE and 1.3.0.0 firmware. I get a ton of warnings from the header files included from usrcode.h I'm not even using this feature, it just won't let me delete it from the project. the code is stock, I haven't modified it to the best of my knowledge. Please wait while uploading Libraries from Power Pmac.Libraries Uploaded successfullyPlease wait while mapping Power PMAC variables.End of syncing the database.PMAC variables are mapped successfully. Build Process For XYOilerMain.out has started. Build Process For XYOilerMain.out has ended. Build Process For usralgo.ko has started. Build Process For usralgo.ko has ended. Build Process For XYOilerMain.out has started. Build Process For XYOilerMain.out has ended. Build Process For librtiplcc.so has started. Build Process For librtiplcc.so has ended. Build Process For libplcc.so has started. Build Process For libplcc.so has ended. Build Process For usralgo.so has started.H:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.h(16,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.h(9,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.h(1,0): Warning : in file included from usrcode.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.c(20,0): Warning : in file included from usrcode.cH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/signal.h(2,0): Warning : #warning "You should include . This time I will do it for you."H:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.h(79,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.h(9,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.h(1,0): Warning : in file included from usrcode.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.c(20,0): Warning : in file included from usrcode.cH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/resource.h(2,0): Warning : #warning "You should include . This time I will do it for you."H:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.h(10,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.h(9,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.h(1,0): Warning : in file included from usrcode.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.c(20,0): Warning : in file included from usrcode.cH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/rbtree.h(128,0): Error : expected ',' or '...' before 'new'H:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.h(1,0): Warning : in file included from usrcode.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.c(20,0): Warning : in file included from usrcode.cH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.h(41,0): Error : field 'attr' has incomplete typeH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/module.h(49,0): Error : field 'kobj' has incomplete typeH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/sched.h(32,0): Warning : in file included from /usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/sched.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/opt/eldk-4.2/debian_rootfs/usr/local/xenomai/include/posix/sched.h(58,0): Warning : in file included from /opt/eldk-4.2/debian_rootfs/usr/local/xenomai/include/posix/sched.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/opt/eldk-4.2/debian_rootfs/usr/local/xenomai/include/posix/pthread.h(147,0): Warning : in file included from /opt/eldk-4.2/debian_rootfs/usr/local/xenomai/include/posix/pthread.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/RtGpShm.h(21,0): Warning : in file included from /opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/RtGpShm.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.h(2,0): Warning : in file included from usrcode.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.c(20,0): Warning : in file included from usrcode.cH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/bits/sched.h(62,0): Error : redefinition of 'struct sched_param'H:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/linux/sched.h(109,0): Error : previous definition of 'struct sched_param'H:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/ecrt.h(95,0): Warning : in file included from /opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/ecrt.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/ethercat.h(2,0): Warning : in file included from /opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/ethercat.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/RtGpShm.h(23,0): Warning : in file included from /opt/eldk-4.2/debian_rootfs/opt/ppmac/rtpmac/RtGpShm.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.h(2,0): Warning : in file included from usrcode.hH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\usrcode.c(20,0): Warning : in file included from usrcode.cH:\Shared\Machines\Probe Products\XYOiler2 (101)\XYOilerCode\XYOilerCode\C Language\Realtime Routines\/usr/local/bin/../lib/gcc/powerpc-405-linux-gnu/4.2.2/../../../../powerpc-405-linux-gnu/sys-include/stdlib.h(536,0): Error : declaration does not declare anything Build Process For usralgo.so has ended.Done building project "XYOilerCode.ppproj" -- FAILED.Build FAILED. And here is my contents of usrcode.c/h //---------------------------------------------------------------------------// Project PowerPMAC Firmware// Delta Tau Data Systems, Inc.// Copyright 2007. All Rights Reserved.//// SUBSYSTEM: User Servo Driver// FILE: usrcode.c// TEMPLATE AUTHOR: Henry Bausley//// OVERVIEW// ~~~~~~~~// This file is where exportable user code can be placed.// To make a function callable as a user servo do three steps//// 1.) Prototye the function user_func(void ,void );// 2.) Export the function EXPORT_SYMBOL(user_func);// 3.) Make sure useralgo.ko has been loaded with projpp.ini////--------------------------------------------------------------------------------#include "usrcode.h"#include "../Include/pp_proj.h"extern struct SHM *pshm; // Pointer to shared memoryextern volatile unsigned *piom; // Pointer to I/O memoryextern void *pushm; // Pointer to user memoryvoid user_phase(struct MotorData *Mptr){}double user_pid_ctrl(struct MotorData *Mptr){ return 0;} #include #include // Global Rt/Gp Externals and structures#include double user_pid_ctrl(struct MotorData *Mptr);EXPORT_SYMBOL(user_pid_ctrl);void user_phase(struct MotorData *Mptr);EXPORT_SYMBOL(user_phase); Any ideas?

Yeah, it must have been the cache. I hit refresh and it came up. Anyhow, I'll be using the FTP client from now on! Thanks, KEJR

Just to confirm, Feb2011 folder still not visible in FTP in internet explorer 8. It is visible from my FTP client built into windows file manager, so I am not sure what is going on there. Just wanted to mention it in case others have the same issue. At least I know I'm not crazy now... well... in that regard at least. KEJR

I am at home now and can see the Feb 2011 folder. I'm 99% positive that the folder was not there this morning from my work computer. Not sure if permissions apply or if the folder went missing for a while, or I am crazy.. maybe all of the above. Thanks, KEJR

Hello, Where is the Feb release? I went to the link in the "latest versions" thread and the latest version I can see is July 2010. Are you saying that the "Background programs" are now compiled with g++ instead of gcc? I've been wanting OOP on this thing since I've started with it but couldn't justify ditching the IDE to get it. If so I am pretty happy!!!!! Thanks, KEJR

I'm not from DT, but here is some advice. How are your motors/drives configured? Are you doing torque command from a axis card and/or Macro, or are you having the PMAC close the current loop and commutate the motor? I don't know as if this is documented, but motor[].iq seems to be the torque command (going from memory) when in torque mode. If you're commanding torque and there isn't an amp error this should be fairly accurate representation. If the brake is on a PPMAC address you should be able to assign a ptr var to it to set it to 1 or 0. I am not sure but I would think that the PMAC software would override this every RTI (or servo cycle?) while brake address is assigned. You might have to assign the pointer to zero if you want to take control of your brake. Of course, why would you do this? If you want to enable an individual motor/amp do "#1 j/" and "#1 k" commands. If you want to enable or disable the whole C.S. do "&1 enable" and "&1 disable" (for C.S. 1 that is). I believe the bias voltages you are referring to are just to adjust the DAQ such that the motor sees zero torque, its a calibration thing, don't worry about it if its set properly. "#1 out 0" will enable the amp but request zero torque from the motor and leave the motor in open loop mode. I wouldn't rely on this software if safety is a concern, always use interlocks for this. I too wouldn't mind seeing better documentation on the data structures. Personally I would prefer the saved data structures to be in the same document as the "non saved" ones, but having a complete list somewhere would help me out alot. BTW, the help files in the IDE are pretty handy for the things that are in there. I find myself using the popup help alot, but it isn't always available or complete. KEJR

[quote='DavisG' pid='1322' dateline='1297297347'] KEJR - what firmware and IDE rev are you using? In the past I have used IDEs/firmwares ranging from the July release on up with MACRO. [/quote] I am using: IDE 1.1.2.45 (9/28/2010) Firmware: 1.2.1.5 Note: I can access macro ivars, just not anything after i999. Unfortunately the Copley amp parameters for macro start at i1024. Thanks, KEJR

Hello, I am new to Macro, so please excuse my terminology. I need to set a parameter on a macro servo drive, which, from what I understand is done with MacroSlave0,i1024 type commands. It seems that anything above i999 gives me an error on the terminal of: MacroSlave0,i1000 stdin:28:1: error #21: ILLEGAL PARAMETER: MacroSlave0,i1000 So is this an error of the command processor, or are these parameters not accessable? Our variables on our drives start at i1024. Also, am I able to access these from C calls? the routine I'm using is programmed in C so I could use this as a workaround if it is possible. Is there an example of this available? Thanks, KEJR

I understand your logic about the sense of the limit switch, but it gets muddy with the MACRO setup since the drive is reporting the limits. After talking with our copley distributor it seems that we can possibly do something in the drive, so that is possibly a different way around this. Thanks, KEJR

In my ongoing quest to properly deal with limits using Macro and Copley drives on PPMAC I have discovered that the copley amp is halting my motor on its own when I hit the limit switch. Limits in the amp are configured and properly relayed to the PPMAC using the default macro register and bit location. To make the copley *not* react to the limits I have to tell it to treat the limits as a general purpose input which gets passed to Macro[n][1] register in bits 17&18 (this took me a while to figure out since the monitor screen seemingly shifts the register 8 bits from what Motor[n].LimitBits expects). So now I have the PPMAC recognizing the limits, but the polarity is inverted. Is there a register to reverse this polarity of the limit bits? While we are at it why is the bit position different in the monitor screen vs the motor setup data structures? Is this some attempt to make it like the old PMACs? If so it just makes things worse IMHO. If this doesn't work I'm going to switch to motor index channel homing and hope that that works with the copley/macro setup. Thanks, KEJR

FYI, I seem to have gotten this working but with one modification that I thought others might want to note. You need to consider RtIntPeriod in the WaitNServoCounts() function. Here is the whole code to start a motion prog and wait for its completion. I haven't added error checking yet. The Yield() function is just a call to pthread_wait_np(NULL). PmacCmd() is an error checked call to the command interpreter call "Command()" with a formatted message display to our HMI if the command failed. [code] int PmacCallMotionProgAndWait(unsigned CoordSys, const char * Prog) { char buf[CMD_MAX]; //Build command, e.g. "&2b4r" snprintf(buf, CMD_MAX, "&%d b %s r",CoordSys, Prog); if(!PmacCmd(buf)) { WaitNServoCounts(pshm->RtIntPeriod + 1); //Coord[].TimerEnabled gets set one RTI after prog start command issued. //Should be set if our prog is running .. Also check for in position. while((pshm->Coord[CoordSys].TimerEnabled != 0) || (pshm->Coord[CoordSys].InPos != 1)) { //Add code for error checking... Yield(); } return 0; } else { return -1; } } [/code]

Hello, I think I have found the culprit. I am embarrassed to say that it appears to be a couple basic things on my end: 1) I am testing using a remote X server and not a "real" display plugged in. 2) I forgot that the X server PC was running wireless. I did do some profiling of the C#/mono Hmi application and these stats might be of some use to others: - Updating 5 display items in C# with a "foreach" loop acting on an arraylist took about 1.6ms. In there also was the conversion of double to string that gets copied to the label text used in my Hmi screen. The raw read using GetPMACVar(char *) took an average of 3us from the C#/mono program, which is pretty good considering my 25% loaded processor. I am surprised [a little] that the C#/mono performance is so bad. Since we might have a couple dozen display items on the screen (on some menus, for instance) and polling interval is 100ms I have some work ahead of me to optimize the code a bit. Still, it is always good to know the numbers so you know what you are dealing with. KEJR

[quote='bradp' pid='1243' dateline='1296507663'] Where does this C# HMI execute, on the PPmac CPU with mono or on another PC connected via telnet or SSH? [/quote] I am executing it on the PPMAC using Mono. My calls to read variables are through DllImport direct to the native C library. I am only executing TWM window manager and an xterm as my other applications in addition to PowerPMAC IDE.

Hello, I'm experiencing a very noticeable performance hit in my C# HMI after configuring my servos from the default phase clock/ servo clock to 15Khz phase and 7.5Khz servo clocks. To give an idea of what my HMI is doing, I have a few buttons and 4-5 P variables that get polled every 100ms using the GetPmacVar(char *) function in the C library. Normally without motors enabled it screams and I don't notice any lags at all. After I updated the frequencies it started giving me random 0.5-1.5 second lags and delays which are a bit problematic. My machine has two servos over Macro with the above stated frequencies. Task manager reports the following: Phase Interrupt 15.083 Khz 1.944 usec 5.996 usec 2.932 % Servo Interrupt 7.508 Khz 8.626 usec 21.981 usec 6.476 % Real Time Interrupt 7.482 Khz 23.140 usec 81.181 usec 17.313 % Background Tasks 0.986 Khz 8.666 usec 8,724.090 usec 0.855 % Should I expect poor performance at these rates? given these numbers I would tend to expect at lest 70% of my original processor speed. Thank you, KEJR