KEJR

I didn't know you could do that with M vars? Where in pshm-> are the M vars called out? At any rate using the ptrM convention for M vars does allow you to have separation from P and M vars in your function calls. KEJR

I wanted to follow up that the #define macros in the pp_proj.h file were added as a method of adding more convenience and type safety to the original way to access P and M vars while still allowing legacy applications to run without change. I recommend using the Delta Tau automatic assign variables where you can. Sometimes you need to explicity access a block of M or P vars and here is what I do: I recommend trying the mode PPScriptMode in your project. This will impart type safety on your variable access. It also makes P variables much more convenient to access because they show up as just double typed global variables. Place a "#define _PPScriptMode_" in your code before including pp_proj.h #define _PPScriptMode_ #include "../Include/pp_proj.h" //Define our M variables starting at M4000. //We use (ptrM) to case the numbers for type safety //(not to confuse them with P vars) #define MyHardCodedMVar00 (ptrM)4000 #define MyHardCodedMVar01 (ptrM)4001 #define MyHardCodedMVar02 (ptrM)4002 //Do similar for PVar absolute access #define MyHardCodedPVar00 pshm->P[4000] #define MyHardCodedPVar01 pshm->P[4001] #define MyHardCodedPVar02 pshm->P[4002] void SomeFunction() { SetPtrVar(MyHardCodedMVar00, 3.14159265); SetPtrVar(MyHardCodedMVar01, 1.234); SetPtrVar(MyHardCodedMVar02, 2.345); MyHardCodedPVar00++; MyHardCodedPVar01 = 1.234 + 2.345; //The following errors out at compile time. //cannot convert type double to ptrM //SetPtrVar(MyHardCodedPVar00, 1.23456) //<---Compile Error //The following errors out at compile time. //ptrM not a storage type //MyHardCodedMVar00 = 1 + 2; //<---Compile Error } I hope that this helps. Again, I recommend using the auto-assign variables if you can. The above programs will work if you define the P and M vars in one of the pmh files in the IDE and include pp_proj.h in your C code. You still get the type safety and ability to use meaningful names, its just that the IDE compile process assigned the M and P var numbers for you automatically and burys that in the pp_proj.h generated header file so you don't have to think about it. KEJR

I am late to this reply but I wanted to say in reply to Dzrong that much of this code was taken from one of my system libraries that I used to query a panel meter device. For this application we only needed to query the device every half second or so and not with any great determinism. I made it into a more general purpose library call that can handle talking to different ASCII-like devices with a well defined character terminator (Some panel Meters, Turbo PMAC, Copley Amplifiers, etc). The ReadResponse() is a packaged routine to read a single character delimited response and put it into a char buffer with null termination (C string). It allows you to specify a single character message terminator and a timeout so that your code doesn't hang forever if the device goes out to lunch. This is similar to the .NET SerialPort.ReadLine() method with the SerialPort timeout enabled. If your response does not lend itself to having a single character message terminator (CR or LF are typical, but it could be any single byte) then you may consider writing your own byte by byte routine to read your responses. Some systems have binary fixed length message protocols for instance and this is something you would have to read, parse, and check for validity yourself after knowing the format. You can use glibc read() and write() commands to access the port directly once the serial port has been opened. I packaged up the serial port open into a library call because it is quite ugly just to open a port and configure it not to act like a tty terminal. I had to do some digging to try and understand what the different options were and set the parameters for what worked for me. Feel free to modify this to your application So in short using read() and write() you can do all sorts of protocol programming with the serial port but YMMV. To answer the original author's question, you can get converters to go from 232 to 422/485 hardware line levels. They might even have something akin to a USB->RS422 device now that uses the prolific or FTDI chips with RS422 or RS485 signal levels. I've found that the PPMAC assigns my USB devices consistently which makes it nice to address if you have multiple USB devices. KEJR

I noticed that this was an old thread but has there been any progress on this? I am having some intermittent non responsiveness in an application I am testing. It would lock up after an hour or two. I've traced it down to a very simple dummy function that got called within a thread that basically just slept for 300ms and then wrote a debug message out to a socket (which generates a switch to xenomai secondary mode...). I used the delta tau supplied "send" function for tracing where it hung and it pointed toward the above mentioned function never returning. I started suspecting the socket write immediately after that. I commented out the socket write and the application ran continuously for about 24 hours. Unfortunately I put the write to the socket back in the program and recompiled and now it doesn't seem to be hanging up after several hours! I'll let it run through the night. I'm afraid that some other slight code change (additional debug code, etc) may be allowing the thread not to hang. I've seen this sort of thing before. I have always wanted to delegate the Ethernet messages out to a non-realtime task and use a RTOS FIFO (Like back in the days of RTAI and RTLinux FIFOs ...) but I have had to put this on the back burner because... well... mode switching was easier when I first wrote the code and it just seemed to work. Now I am growing weary that these mode switches in my code could result in very intermittent instability such as I am seeing now. Have you had any luck creating realtime FIFOs to do clean streaming between primary and secondary threads? I feel like I'm going to be digging into this soon and any groundwork would help. Thanks, KEJR

I did something similar to the last post and now my startup is working well. What I did was put a line in /etc/rc.local which executes after all of the init scripts for any particular runlevel. touch /var/log/runlevelcomplete Then I am using the test and echo command to inspect for this file through my telnet connection: while (!str.Contains("0\r\n")) { TelnetCmd.WriteLine("test -f /var/log/runlevelcomplete; echo $?"); Thread.Sleep(1000); str = TelnetCmd.Read(); if (retry > 20) throw new Exception("There was a timeout waiting for the PPMAC system to start. Response:\n" + str); retry++; } This seems to work well and I am having success starting my program and connecting to everything after this. Thanks for the help. KEJR

I'm still having issues. I am waiting for the following grep command, which corresponds to the last dmesg line I see after a PPMAC has been fully functional: dmesg | grep -i "initsharedmemory(1):" This seems to wait properly and detect this message but I'm still having issues with my program starting up. My program is crashing immediately with errors related to shared memory. I've put a 5 second sleep before my program start and it helps but I just hate to rely on time delays if I can avoid it. I think I'm heading in the right direction, which is good. Anyone have any other ideas? Thanks, Ken

I've had pretty good luck using command() for many basic things in PPMAC like jogging, enable/disable in background C apps. So far I've not had any issues with multithreading and using command() (although I admit I've not done much multithreading with the command interpreter). One thing I will say is that I would not be doing anything in the rtiCPLC that uses command interpreters and such. I've not used this facility yet but it is my understanding that the rticplc is meant for quick hard realtime tasks (data gathering and processing at hard realtime interrupt speeds). I'd highly recommend using background C apps or CPLC's if you want to take full control from a C environment such as starting a jog or enabling a motor. Leaving your realtime interrupt tasks operating purely on native C calls and memory access will make your life much simpler in the end. KEJR

That makes a lot of sense. I'm already doing the ping check and then giving excessive retries on the telnet connection. It would seem that on my system the telnet daemon takes some number of seconds to init after ping is established (I think I give telnet 30-60 seconds worth of retry and sleep iterations on failed connections before issuing an exception). So it would seem that if I waited for the dmesg output that this would provide another layer of startup sanity check. I'll play around with a manual telnet connection to see what grep command works best and then code that into my startup code in the HMI/GUI (C#.NET) As always you have good ideas, thanks! KEJR

Hello, I have a machine that uses a PPMAC and a windows based computer for HMI/GUI (custom program I wrote). My software connects to the PPMAC through telnet and starts GPASCII. It also connects to another telnet instance and starts a background C application through the telnet/bash shell. Finally once my C program is started it connects to a socket (port 3000 in my case). I'm having issues determining when the PPMAC system is fully up and running. Some of my connections are failing to connect even after the network and telnet server are running (Sometimes GPASCII fails to start, other times my program won't start correctly). If I connect to an already booted system there are no problems. So my question is, what is the best way to determine that all PPMAC services are fully operational before I attempt to start up my C program and GPASCII connections? (Preferably through a shell interface like telnet)? I will add that there is a reason I'm starting up my C app remotely and have chosen not to use the "auto start" feature of the PPMAC IDE. Thanks KEJR

I realize that I am late to this thread, but wanted to comment that I am saving data to the SDcard [nearly] every second. I have a thread that scans the memory that I want to persist (non volatile P vars in my case) and if there is a difference from the last time I saved it dumps the data to disk. I have some number of P vars that get saved (I believe 1000 p vars). I wrote all of this code in a C thread doing the file access directly through C api's. I bought the biggest SDcard I could at the time and made sure it had wear leveling. With my "only write on change of state" algorithm and the wear leveling I figure I have a liftetime capacity on this flash. The algorithm works nice because if someone stops the machine and goes to lunch (or leaves it on for the weekend) the thing isn't sitting there churning out data continuously to the disk. I save my data in two files in case one gets corrupted and keep a 32 bit CRC in them that I compare at startup. Oh the lengths we go to to abuse new technology (in the past we used a 4K or so battery backed SRAM chip!!) :o)

Sometimes its the simple things that get you. The new IDE installation didn't have the send buffers enabled that I was using (Buffers #1 and #2). I don't recall if prior versions had 0-4 as a default or if that's what I had set up originally. I was about to run sendgetsends over SSH when it occurred to me that all buffers weren't enabled. Thanks, KEJR

Hello, I recently upgraded to the latest IDE and firmware (IDE 2.0 with Firmware 1.6.1.1). My application was hanging and seg-faulting and I was not getting any Send() messages (These may not be related). I like to use the unsolicited messages as a debugging tool when things go south. I created a simple C application in the IDE which initialized the library and sent some messages through printf() and Send(). I was not able to get the Send() function to work properly. I did verify that the unsolicited messages window in the application was started and online (several times!). I've attached the test code I'm using: #include // Global Gp Shared memory pointer //------------------------------------------------------------- // The following is a projpp created file from the User defines //------------------------------------------------------------- #include "../../Include/pp_proj.h" //Main entry point to program that also sets up threads and inits libraries. int main(void) { printf("\nAt Very Beginning\n"); /* Avoids memory swapping for this program */ mlockall(MCL_CURRENT|MCL_FUTURE); InitLibrary(); //Init DT library. printf("PPMAC is initialized.\n"); Send(1,"This is a test."); CloseLibrary(); } Please let me know if there are any ideas to try. Thanks, KEJR

Is your RTI code doing alot of servo stuff, or are you using it to just get fast updates (monitoring, etc)? The reason I mention is that you can do some pretty fast processing using the background C threads and you can have it all in one protected memory space. I wonder if Xenomai needs to schedule the threads simply because they are using the shared memory and/or FIFO facilities. This might explain your entry in the xenomai scheduler. I can't comment about the makefile --wrap. I can only assume that they are needed on some files but not others due to the include files and libraries linked in. I trust Shansen's replies in the other thread, he is definitely one of the more knowledgable members here regarding the make process on the PPMAC as he has done his own make process in Eclipse. (I'm tempted to go there, but cling to the support of the PPMAC IDE.... :o) Yeah, you found the atomicity thread. I never knew CS410 would be so useful at the time I took the course! Knowing your thread synchronization and potential dead lock conditions are crucial in these applications. :o) I'd encourage you to hook up a scope and start pulsing some outputs at different places in your threads (preferably different outputs per thread, etc). A multichannel scope or logic analyzer can be helpful to see if your code is really jittery or if is executing at times when you don't expect it to. Do you have a sleep call in your threads, or do they block on a FIFO read or something like that? Try to look in your code to see if somehow you might be starving something in a busy loop. I know these are basic things, but I can't think of anything else to try. Have you thought about using GPASCII for much of your HMI updates? I have found that I can poll GPASII for a few dozen things and the update rate is really good. I tend to only update numbers in my HMI that are on the active page so it limits the traffic vs. sending all the data back and forth for the application (whether it is shown or not). It sounds like you have a ton of code existing so I know it might be difficult to look at different alternatives but sometimes you have to weigh the redesign vs. fix-existing dilemma. How is your code reading and writing? If it is going in and out of realtime that much I would suspect that it is reading one value from FIFO/SHM and then writing it out to Socket/File IO in a loop or something like that. I'd try reading in all data to a memory buffer and then spitting it out to the IO resource after it is all captured. In this way if it is in fact going in and out of realtime at least its once per update cycle. I'm not sure if this would apply to shared memory, but maybe I'm sure the FIFO has some synchronization that needs the xenomai scheduler. I'm kind of grasping at straws, but this is the kind of thing I would start to look given the info you gave me. Good luck. Ken

The FIFO scheduler is just a function of the Xenomai RTOS scheduling method. The first thread to be available at the current priority level will get run in the order that they became ready to run (as they come out of sleep or mutex, etc). It is hard to say for sure without knowing your application, but you probably don't have to worry about the RTOS functionality from what I'm hearing. If all you are doing is IO calls (file, socket) then you will be getting kicked out of the RTOS (Xenomai) scheduler while those calls are made (That is if you set up the thread to run as hard realtime). By default the background C programs run with the Linux scheduler which is ideal for logging and socket IO. As with any multiprocess/multithreaded system, however, remember that you will have all of the issues with thread syncronization (or lack of). Particularly be wary of the classical "Read-Modify-Write" Scenario if both a realtime/PMAC thread and your background linux thread are modifying the same shared memory. In PPMAC terms you would not want a C PLC incrementing a global "P" variable and a background C program incrementing the same variable because they will trample on each other if no care is taken to safeguard this. You probably don't have this situation, but I wanted to mention it. The fortunate thing is that the PPMAC will read an entire 64 bit memory location in one clock cycle, so there is not a problem with mixing up bytes in your words because the CPU has to fetch it in two instructions (Potentially getting interrupted between instruction cycles and having that data word get updated by the higher priority thread). Because of this, make sure that any array indexing you do on shared memory is done with 'double' types instead of 8/16/32 bit char/int/float types. I had a problem where I was having a non realtime background thread periodically backing up blocks or shared memory to disk and I started out with storing it as bytes and I was getting corrupted data. I went to fetching as 64 bit words and the problem went away. If you want to learn more about that I think this is in another thread on this site. The thread library I developed was because I prefer to have precise control over my scheduling and it allows me to interact with all of my threads in one process space with access to mutex, sockets, file IO, etc. (For my applications accessing IO can be dropped down to lower priority as it is mostly error handling when things have stopped). I can do things like have one piece of code run multiple identical pieces of hardware, and do almost all of my code without writing a single script or C PLC. For me this is cleaner but YMMV. KEJR

We never did resolve the issue. To my knowledge the production operators are having to cycle power occassionally. Can you relate your failure CPUs to certain revs or date of manufacture? KEJR

This sounds good. I will be finding out shortly if there are any issues. Have you tried restoring software to the Etherlite [from a vanilla UMAC product], and do you have both Macro and EtherCat options on your etherlite? Thank you, KEJR

Hello, We will be receiving our first Etherlite PPMAC shortly and I'm wondering if there are any software changes to the debian linux filesystem/distribution (other than the linux kernel and PPMAC libraries[aka firmware]). From what I understand the boards in the Etherlite are the same as what is available for the UMAC CPU with the builtin EtherCAT/MACRO so this discussion should apply to that product as well. We have a company standard disk image that we maintain for our vanilla (non-ethercat) UMAC PPMAC CPU. If possible I would like to update this image to also run the etherlite so that we get all of our linux customizations for both the Etherlite and the UMAC systems (With and without MACRO/EtherCAT). Is it possible to take the Etherlite (with MACRO and Ethercat) and: - Save the factory image (for backup purposes) - Restore our company standard image to the Etherlite. - Upgrade both the linux kernel and the PowerPMAC "firmware". - Backup this new disk image for use on all PPMAC systems? This would be ideal since we can maintain one disk image and run on all systems. Thanks, KEJR

I don't work for Delta Tau so I can't speak for them, but if it were me I would put a default accel of zero just because it would be dangerous for them to assume a "safe" accelleration for your system. I can imagine some bad scenarios. I believe its good practice to assign your accel and velocity on every prog or at least at startup of the system. KEJR

Is there a MR-J3 drive from Mitsubishi available with ethercat built in, or is it the "saddlebag" option module similar to how Yaskawa does it? KEJR

I just looked at my notes and I had to install the "ntpdate" debian package. Its been a while since I did this, but I seem to recall it being a very simple install and it just worked. Keep in mind that with any debian package install you need to deal with the read only filesystem as described in many other posts on this forum. Its probably been over a year since I've installed any deb packages, I hope that debian is still maintaining this version on their servers. For me, I have made all the changes and imaged the flash on the PPMAC so I haven't had to go through this process recently, I just keep restoring the image on new PPMACs that we get. Let me know if you need any more help. KEJR

I did get the USB serial port working and am using it on a machine in production. I think at the time I ended up talking to someone at Delta Tau and ultimately Henry Bausley built a special kernel for me that included the common USB-RS232 drivers into the kernel. I would think that by now the latest kernel would have this by default. I like the FTDI based USB-232 converters but at the time I bought a TrendNet TU-S9 adapter which uses one of the prolific chips and have not had any issues. I can certainly post some code. It took me a little time to piece it together into something that would be a nice library function. I can't guarantee its perfect, but it worked for me. I have a function to open a serial port connection, and another to read in a terminated line (with timeout). I use the readline function alot for industrial devices since it is common to write a command to the serial port and then wait for a response from a device. As far as the RTOS part of it, I didn't have any speed issues or any surprises in my application. It just worked surprisingly well. Frankly I wouldn't advise trying to do anything that needed to be deterministic with the serial ports. Charles: I'm going to send you an email off list to talk about the code I have and what to do with it. KEJR

+1 Please implement (or reimplement?) this feature. It is EXTREMELY powerful to plot your IO bits on the machine instead of dragging out a scope or logic analyser! If I were to try and sell people on this system that would be one feature I would push on customers because not alot of controllers have sub millisecond plotting of any signal on the machine. Mixing plots of servo commands/feedback to solenoid valves turning on and prox signal inputs is very helpful and gives much insight into how the machine is behaving. I might have been the one to bugzilla that one, its been a while. I was hoping they fixed it by now. KEJR

I agree that the IDE IP address setup could be better (At least on the IDE versions I've used, I am not running the latest). I prefer to do all of my IP address work on the command line over the serial port terminal (it always works). To do this you will need a decent editor. The PPMAC comes with VI which alienates most non unix people fairly heavily. I have installed emacs since I know all the basic commands and it is a more natural editor for me. Henry Bausley had a writeup on which file to edit and some example settings: http://forums.deltatau.com/showthread.php?tid=199&highlight=IP+address You should be able to edit this file with telnet, SSH, or using the front panel serial port (my favorite as it always works). For me I set up one PPMAC and set the networking for DHCP (also installing all the programs I require, etc). Then I just copy this image to new PPMAC machines and ask our IT guy to put the MAC address of the new PPMAC into the reserved IP list on the DHCP server. It saves a ton of headaches. Will this scheme work for you, or do you require a true static IP? KEJR

I was reading some older posts on EtherCat drive testing and Sina had mentioned that one of the OMRON R88D-KN[]-ECT drives (G5 series motors) had been tested at Delta Tau. It has been a long time wish of mine to have the compact japanese AC servo motor vendors plug directly into a PMAC (without an add-on module for cost and space reasons). It looks like on the datasheet that these drives support the following modes: • Cyclic synchronous position mode • Cyclic synchronous velocity mode • Cyclic synchronous torque mode They also state that the distributed clock goes down to 250us. Does this imply that this drive can run a torque loop at 4KHz over Ethercat? That would be great for all of our compact servo motor applications. We are also looking at EtherCat with regard to using the Beckhoff IO system, so this might be a good option for us. Thank you, KEJR

I haven't used eth1 yet, but I'm using eth0 with our company DHCP server and it sets up all of the network parameters correctly. If you are hooking up devices to eth1 statically this of course won't work for you. I'm curious why you need to use the second port, is there a peripheral that needs direct connection? I always thought it would be a good setup to put a panel PC on eth1 and hook up eth0 to communicate to the company LAN. But then the PC needs to route through the power pmac to get to the outside world and it just gets a bit messy. I'm finding that with a good switch that everything can be put on eth0, but I like having the option of a second port and will probably reserve the use for more "device" kinds of things that don't need access to the LAN.