KEJR

This is just my opinion but I agree. The IDE is doing alot of funky stuff behind the scenes (autocomplete and syntax checking of C programs messes up my machine still), please leave our files alone. I would suggest a prompt saying that the project folder needs read/write permissions, but the source files should be under our control and obey the readonly attributes, especially since many VC systems use readonly as the check out mechanism. KEJR

Dave, I understand that it is frustrating that some things in the PPMAC work one way and others in another. If you know a little about the underlying RTOS technologies (you might read up on xenomai RTOS) it makes sense, and it was good to see the responses from the folks at Delta tau explaining this. I am going to offer to answer your question in a different way and that is that you really don't ever need to use CPLCs or the script PLCs in my opinion. I've found I can do everything from a C app. If your preference is C (as mine is) then do everything in a C app with multiple threads and call motion programs when you need to do your motion. The reason for this is that in what DT calls the "Background C applications" (poor terminology... sorry guys) is really a full linux application, at least in the sense of console application that has access to the xenomai pthreads interface. I forget the terminology but basically you can spawn new threads that can then be scheduled by the realtime kernel xenomai. This is different than kernel RTOS threads, but I have found it to be very successful. You can configure them to use a FIFO scheduler that will wake up in 1ms time ticks just like the DT provided CPLCs are. The real benefit here is that your code can be compiled in one application object file that you have almost complete control over the execution of the threads. If you want to you can split your code into different files using the IDE and in that sense it is programmed like a traditional C application. I wrote some functions for creating new xenomai realtime threads in the "Background C applications" and have tested several threads running at 1ms intervals. I also have libraries that call motion programs (and deal with errors of said motion programs if they occurr), delays, digital IO functions, functions to interface to an HMI, etc. Currently my library is being compiled in every time using a #include, but I will be transitioning to the library interface they provide as soon as I install the new software. One other good thing about the background C apps is that you can access the filesystem if you need to. Sometimes I'll do this when an error occurs to write to a log file, etc. What happens is that when you call a "linux" type of command like file open or read, write, it kicks you back into being scheduled by the Linux kernel until you execute a real time command such as pthread_wait_np(NULL) or something like that. While this is all scary sounding, it just works. I have a main() function in my app that consists of calls to create threads and then a call to run. It is so clean looking you wouldn't think you are running an RTOS because the uglies get hidden by my library functions. If you want I can help you out in more detail. I took the time to write this because you sound like you want to program this like a "real" C program with libraries and I think this is the way to go for that. Try it as a test! I spent alot of time up front structuring my system and now it is the most integrated controller I've used especially since I can now write my applications with C instead of some modified proprietary garbage language based on VB, pascal, or worse. KEJR

I definitely know what *not* to do now. I had used the memcpy() routine in my program to do a P var backup, so I wanted to test that it was not behaving differently than, say, a "for" loop copy of "double" datatypes (I suspected it might). Well, to sum it up, it seems that the memcpy() function reads in 16 bit words based off of a quick experiment. See the complete code here: Background C program, capp1.c: //-------------------------------------------------------------------------------- #include #include // Global Rt/Gp Shared memory pointers //------------------------------------------------------------- // The following is a projpp created file from the User defines //------------------------------------------------------------- #include "../../Include/pp_proj.h" int main(void) { char buf[255]; double SaveDouble; InitLibrary(); Send(1,"Capp Starting to monitor...."); while(1) { //SaveDouble=pshm->P[0]; //Capture value for later processing, keeping it synchronous. memcpy(&SaveDouble, &pshm->P[0], sizeof(double)); //Now try it with memcpy which may acess the vars differently. if(!((SaveDouble == 8888.0) || (SaveDouble == 9999.0))) { snprintf(buf, sizeof(buf), "Caught You. SaveDouble: %0.0f", SaveDouble); Send(1, buf); } } //Put your code here CloseLibrary(); return 0; } Background "c" PLC: #include #include #include void user_plcc() { struct timespec SleepTime={0}; // Initialize time structure SleepTime.tv_nsec=1000000; // 1000000 nanoseconds, which equals 1 msec pshm->P[0]=9999.0; nanosleep(&SleepTime,NULL); pshm->P[0]=8888.0; nanosleep(&SleepTime,NULL); } Note that when I use the commented out line: SaveDouble=pshm->P[0] the code produces no output at the Send() buffer. When using memcpy() it continuously barfs out the wrong values: Port 1: Caught You. SaveDouble: 9998 Port 1: Caught You. SaveDouble: 8889 Port 1: Caught You. SaveDouble: 9912 Looking at the Hex values for the numbers you can see why: 40C15C0000000000 Decimal 8888.000000 40C3878000000000 Decimal 9999.000000 40C1878000000000 Decimal 8975.000000 40C35C0000000000 Decimal 9912.000000 40C3870000000000 Decimal 9998.000000 It would appear that they are being overwritten in 16 bit chunks. To make a long story short[er] I will be writing a function to do memcpy64bit() or insert a for() loop into my code. I just wanted others to be aware of this so that proper care is taken in handling shared memory. I hope gcc continues to behave this way, although I have no reason to expect it to change. Thank you, KEJR

Thanks Atul, I will be looking forward to that release. It will help us to keep from making mistakes communicating to the wrong equipment, or forget an IP address and have to go look it up. KEJR

I was pretty sure there *had* to be something like this, but it is good to make sure. Thank you, KEJR

If I were you I would wrap the sleep stuff into nicer looking functions as the POSIX sleep calls are ugly when you use them all over the place. I would also write functions called something like "EnablePlc(unsigned PlcNumber)" and "DisablePlc(unsigned PlcNumber)" so that you don't have to remember what those PLC commands mean. Comments are nice, but it is better not to have them and have a clean API. This is just an idea, but I would consider looking at programming the Power PMAC alot differently than the turbo pmac. There is so much more flexibility with it that you might find you don't have to do alot with the PLCs. I use the Background C programs with multiple threads instead (disclaimer: You do have to know a bit about the realtime for this...). It is much like using the C language PLCs but organized the way I want them to be. Even having the ability to call C functions can get you around doing alot of PLC enable/disable like you had to do in the old days. I don't know what you are doing exactly but thought I'd mention this. Your mileage may vary as they say... :o) KEJR

Hello, I need to be able to read P variables from a "Background C application" with guaranteed Atomicity in the event that a higher priority thread (like a motion program) preempts me and writes to the same P variable halfway through the read. The C application is listed as a 32 bit Elf executable so it will read the 64 bit words as two 32 bit words and herein lies the problem. Right now I'm using the shared memory pointer (pshm->) to access the P variables from my C application. Any thoughts? KEJR

Hello, I've asked our network admin to add our ppmac IPs to the DNS with human readable text names. This works for ping and ssh (PuTTY), but not from the PPMAC IDE. Am I doing something wrong, or is this really not possible yet? Thanks, ~Ken

Dave, I, like you, did not want to have global variables used as constants. In a previous posting on this list I was told how to accomplish it. Create a dedicated *.pmh file ... I call mine constants.pmh. *Only* put your #define statements in there and you can use them from the script environment automatically. To get them in your C environment you have to include the file exclusively. Unfortunately the paths are weird and have spaces in them, but it works: #include "../../../PMAC Script Language/Global Includes/constants.pmh" :) Some side effects are that some things you can't declare as constants, such as motion program names. I think the IDE keeps track of the motion program names internally on the script side, so if you try to define them with a #define the IDE gets confused. I resigned myself to just using the string name when I'm dealing with motion programs in the C environment and it works well. KEJR

This will be a welcomed addition. Are there any problems having the library object file live on a network drive map (i.e. separate from the project folder)? I say this because some IDE programs copy the library object file to the project folder, which is another (albeit different) way of doing it. thanks, KEJR

I've not done it yet myself, so take this with a grain of salt. Keep in mind that the root filesystem is mounted as readonly, so in general anything you do to change the system needs to go through a procedure where you copy files from a readonly "ramdrive" mirror folder to the real folder after you make the flash drive writeable. There are topics on this forum for how to do that, so I would look into that first. Then you find out what files get changed in linux when the passwd command is issued. - issue change password command. - mount drive as read/write - copy appropriate password file from /.readonly/etc-tmpfs-mirror/whatever to /.readonly/etc/whatever KEJR P.S. If you haven't done so yet, make a filesystem backup of your PowerPMAC using the WinImage program (also documented in the forum). This has bailed me out several times in mucking with core system changes. It also lets you maintain a "company" standard image(s) when you get the PPMAC sorted the way you like it.

I didn't know the IDE supported libraries now. We worked in a hack whereby we include our library source and header file located on a network share. This works, but it is not the preferred way, obviously. I would be interested in seeing library support if it is not available. It allows us to encapsulate common functionality across different applications. KEJR

Is there anything else I can try to get our PPMAC boards to boot properly? I have two CPUs that are doing the same thing in different card cages. The problem is very intermittent and can go for a week or two between failures. It has never failed once it has started booting from flash. I'm going to need some resolution on this soon as our machine is on the manufacturing floor and is an annoyance to the operators.

Hello, I am having a difficult problem because we have a power PMAC system using Macro that does not appear to reset amp faults correctly. I have worked with a support engineer at our distributor and he is saying that the command works well with the *Turbo* PMAC for resetting errors on the copley amps over MACRO. The setup is a Macro master in the PowerPMAC rack that is hooked up to a Copley Controls Accelnet amplifier and a Sanyo Denki motor. The encoder is a single turn absolute, with a battery backed turns counter. At startup the amp issues a fault for the encoder battery that needs to be cleared when you are using the motor in a non battery application. In other words we are using this motor as a non absolute application and we just want to tell the amplifier that "OK, we know the battery is not there, don't worry about it". Is there any way to tell if this is a PPMAC problem vs. a Copley problem? Its definitely one of those tricky ones where I am stuck between two vendors! Any troubleshooting ideas would be appreciated. The command I am issuing is from the terminal and is as such: MacroSlaveCLRF1 I've tried many nodes and none of my slaves appear to be cleared as a result. If I open the copley software I can hit their version of Clear faults button and it is OK. Of course this is not OK for deployment. KEJR

I verified Brad and Henry's posts with my PPMAC and it worked fine. The following command works from Telnet/SSH/serial: mount -t vfat /dev/sdb1 /mnt/ Can you post the results of the following command: ls /dev/sd* I believe this will tell if your kernel is properly recognizing the storage devices. I get the following on my machine: ls /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sdb /dev/sdb1 Depending on how you want to use the SD card you will want to mount it at startup through a script or mtab/fstab, or just when you need to access it. We are planning on using the SD card for logging and as such will probably always have it plugged in and mounted at bootup. KEJR

+1 Although I don't have a *big* problem with this, it would be slick if we could do that at some time in the future. We will be using only a small subset of the project tree for any given machine. KEJR

I appreciate all of the good work you folks at Delta Tau have done with the software and controller. I just have to comment that using "My Documents" for anything is very annoying and problematic. Unfortunately it seems to be very prolific in the industry. Is this going to be going away in future releases? Also for some reason I get "PowerPmacSuite" and "Power PMAC Suite" installed in "My Documents". I also use three different machines throughout the day, so I have to maintain all the PCs and change all of the addins multiple times for each release. I don't mean to hijack the thread, just that this is somewhat related. Thanks, KEJR

I'm using the USB<->RS-232 adapter by prolific with success. Delta Tau supplied me with a modified linux kernel that has these drivers prebuilt into it. Keep in mind that it is not "hard Realtime" since using the linux kernel's USB driver is not part of the realtime kernel, but rather xenomai dropping back into linux scheduler to do the serial port read. In that sense I'm not sure it is much better than using straight ethernet communication in linux mode and then switching back to hard realtime. Keep in mind that Delta Tau lets you do C language "Background Programs" which have access to the xenomai Posix threading skin. This means you can create your own posix realtime threads to do whatever you want. I use this approach myself and created my own library to simplify thread creation for our types of applications. I'm glad to hear you guys are looking into a RTNET driver for PPMAC! I would hope that this would work on one or more of the built-in ethernet devices. KEJR

[quote='DavisG' pid='1885' dateline='1306251265'] I have one customer doing the same thing - we ended up writing zeroes into motor[x].Pos and motor[x].HomePos - that seemed to handle everything - #xp comes back as 0, and motor[x].ActPos = 0. [/quote] Can you zero these out with the motor enabled? I like this approach because you can then treat ActPos are a referenced value. KEJR

For now in C program you can call the OpenMacro() function call in a C program and the script and C API functions will work after this. I've been told future releases will fix this. Not a problem for me now that I know. Thanks, KEJR

I was doing some work with the MacroSlave command in the terminal to find out what worked. I then copied this into my C program as a Pmac command and it worked initially. When I powered down my machine and ran the program again I got an error on the first calls to MacroSlave commands. The error returned was: "MACRO PORT NOT OPEN" After issuing some MacroSlave commands in the IDE terminal I was able to send MacroSlave commands from C. Is there something additional I need in the C environment for the Macro commands that I don't need at the terminal? Here is my code: Command("MacroSlave0,i1145=0"); Command("MacroSlave1,i1146=0"); As a test I re-powered the machine, issued some MacroSlave query from terminal, and then continued my C program with no faults. Doing this same procedure without the MacroSlave query in the terminal prior causes the fault. KEJR

*** Problem Solved *** I put this in another similar post I had, but the solution was to map an M-var to the raw IO bits sent back over Macro that belong to my EOT limit in need of monitoring. I then disable the special function for that input pin in the drive register using a MacroSlave command (Handy little command). This effectively cancels the PPMAC limit as well since the drive doesn't send out the limit status when a hardware limit is not defined on any of its inputs. So then I jog to the hardware limit, stop, knock down my MaxCmd, open up following error and following warn to considerably larger number. Then I issue my slow homing command to the hard stop using the builtin homing facilities and the Following Warning capture as described previously. This works well. I'm having one issue with the MacroSlave command working at bootup, but that is for another post as the topic is different. Thanks, KEJR

*** Solved*** While I haven't proved this, the problem was most definitely that the copley drive was decellerating on its own when EOT limits are applied, and it seems to mess with the trajectory commands being sent over the MACRO bus. Since I am not planning on running into the EOT limits alot this is OK with me now that I know what is happening.

*** This problem is finally solved.*** While homing I disable the copley drive limits over the Macro link using a MacroSlave command to modify the Copley drive's input parameters. Once homing is done I re-assign the drive limit inputs to function as limit inputs once again and all is well.

[quote='curtwilson' pid='1773' dateline='1303408319'] These elements are "function" elements, computed only on request from several status bits, and so are not directly accessible from C programs. [/quote] Is it possible to create C API calls for these types of things? Alternatively if it is documented we can create our own C calls from the data structure access. KEJR