KEJR

One thing I recommend doing is to get a PPMAC that has a virgin image and back up your image using WinImage (see other posts). I've had a couple cases where I screwed something up and had to go back to stock to try and see where things went wrong. It would be good to know if this also failed the same on the stock image after running the config. I think that I did do an update on all my packages at one point, but its been a while (obviously don't update the kernel). KEJR

Ouch. I definitely did not get that problem. Is your distribution based on Debian Lenny? I only ask because the power PMAC I based my standard image off of is at least 2.5 years old by now and I don't know if they have upgraded to newer distro yet. Another difference might be because I have the video chip on board with the 4GB flash which I believe has more debian packages installed than the regular distro (i.e. desktop stuff). Now this shouldn't make any difference, but I thought I'd throw it out there as to a potential difference. I wish I had a better answer, but I'm not an expert with linux mail.

I got the mail system to work and I'm sending mail with the command line. Your setup will vary depending on your network setup, but I ended up having to run the following debian config: dpkg-reconfigure exim4-config and choose "mail sent by smarthost" as the option for sending mail. Then later in the setup it will ask you for the mail server, which in my case auto detected somehow as our company mail server. This is all that was needed. Keep in mind that you will probably want to do a fresh reboot, unlock the filesystem, run the config, etc etc very similar to what you do when installing debian packages (I haven't done this, I'm just testing before committing my system). I can't speak to attachments, I haven't done anything with that. KEJR

I've thought of using an external IDE or standalone make system but I've been struggling to keep everything in the IDE to get the shared global variable labels and have the motion prog editing be under one roof. Have you found any ways around these issues? Thanks, KEJR

Like I said, I do hope they make the IDE less picky about these things. There are limitations to the PPMAC as compared to out of the box Linux systems such as the read only filesystem and needing root access but they are a necessary evil to make things run reliably. I've decided to use the PPMAC as an appliance in some ways, and use the underlying OS where it makes sense (I've been using an embedded windows touch HMI attached to it over ethernet). At some point getting it into a general purpose computer has diminishing returns, but that is probably a debate for a different thread. KEJR

Background C programs are regular linux programs so you can check for them in the output of "task manager" like programs. From the command line type in "ps -e" and it will spit out all processes running. Also the program "pidof" will return the process ID of the program that you specify, for instance, try this: pidof getty it will return several numbers since getty runs as many processes. There are probably several dozen other ways to do this and the approach will depend on whether you call this from a shell script or another C program (some manager application, or HMI program that starts the C code, etc). KEJR

Hi Mike, I do prefer to work mainly outside of the PLC scripts and "C language" PLCs. I think there is more power in using the xenomai threading and keeping most of your machine logic in one process. I don't know if that helps with watchdogging, but I suppose it is likely. Its too bad the IDE won't let us do C++ because the pass by reference feature would eliminate most of the pointer usage (at least for me) and make for a safer experience. I think that your external watchdog relay is probably going to be the most reliable. I'm curious as to how you are shutting down your drives safely and gracefully from this device? Does it pull an enable line on the drives and some number of ms later it kills your mains contactors to the drives? I am working on the mail thing on the PPMAC now. It looks like both mail and sendmail programs are installed. I'm going to do some testing because I see that as something that I would like to use in the future. I'll let you know if I get anywhere. KEJR

Lets be nice. Delta Tau could take the standpoint of most manufacturers and not let us have any customizations under the hood (It would save them money in support I am sure). I like the open nature of the power pmac quite a bit. I would hope that the longer term solution is that the IDE code could be changed to be less sensitive to these things. I haven't picked any battles with them over this because it is not something I really need. They have come through for me on things I needed or were very helpful and I feel that is more important.

I've never tripped the watchdog, do the linux apps continue to run after it trips? If you are familiar with Sendmail then I would think to use that. From what I've read you can open /bin/mail or /usr/bin/mail with a call to popen() then use fwrite() to send the message and attachment data. See the following: http://www.unixguide.net/unix/programming/5.2.1.shtml I think that you will need to specify the correct MIME type for the binary data or convert all of your data to ASCII before sending it. I found some discussions on attachments here: http://lists.freebsd.org/pipermail/freebsd-questions/2005-April/083518.html If you want ultimate control you could roll the following C code into your app. I'm not sure if it is any good or not, but you can check it out: http://libsmtp.berlios.de/ The latter is probably overkill. Let me know if you get something working, I'm curious for my own work. KEJR

I think that I finally found out what was going on with this but forgot that I did not post this to the discussion on the forum. I had a few incremental backups of the PPMAC disk image which helped me piece together where things where broken. To make a long story short, the IDE would not work if I added color to the command line. (Its been a while, but I believe it was an alias to the "ls" commmand to be "ls --color" that killed it). I suspect that the IDE code does some tests on the connection and whatever control codes that are used in the "ls --color" command are what killed it. Did you do any customizations to your user login scripts for root or anything like that? KEJR

That is very encouraging. Can I ask how you are measuring this, and how much jitter you have on this 2ms update rate? Also, is the Linux PC the modbus master (i.e. doing the polling) and roughly how big is the data? The application that we are seeing the 50-70-ms latency on is on an "industrial" switch (AutomationDirect) in a cabinet with only the PMAC and a single modbus slave that is reading/writing 16 words and 16 bits. I need to get an old school 100mbit *hub* and run wireshark on it to find out what is really going on. In similar issue I'm testing the amount of time it takes to send ethernet data from a mitsubishi PLC over a switch to my PC and am seeing 200ms latency between the send and the ACK packet sent back. Beautiful! Thanks for the tip Dan! KEJR

Thank you Henry. As a side note, we are experiencing many tens of milliseconds delay when using the modbus option (50-70ms, somewhat random). We tried a crossover cable and it still had issues. We haven't pinpointed it to the PLC controller or the PMAC yet (i.e. I haven't sent wireshark loose on it yet) but now that I hear this response it points more toward the PMAC. We still might be able to do something with the modbus and have our Host PLC send the ASCII strings to our server. We do have a serial port, but the data takes too long to shift out of the serial port before we get to our next machine cycle. I'll talk to my colleague to see if he might be able to trim the amount of data sent out, or if we can just keep statistics instead of raw cycle by cycle data. Thanks, KEJR

Hello, We have a Turbo Brick that we want to attach to devices that can accept "raw" TCP streaming data. In our case the Turbo PMAC would send simple ASCII commands similar to what you would see on a serial port. I have read in the manual that you can send data from the Turbo PMAC with a version of "send" command and it will go over TCP to another device, but that there is yet another packet/driver level (By Delta Tau) on top of the TCP layer. Is there really no way to create a *unfiltered* TCP Server listening on a port that when connected will allow us to send data with our PMAC PLCs or PROGs? In other words, is there a way to connect with a standard TCP client (such as PuTTY, or .NET TcpClient) and get an exact copy of the ASCII streaming data sent from the Turbo PMAC? BTW, I'm wishing we did this project with a UMAC based Turbo so we could upgrade to a Power PMAC :o) It was just a year or two too early at the time we developed it! Thanks, KEJR

[quote='BoneSkier' pid='3394' dateline='1335287938'] I am using a MONO program, and I just compiled with .NET 4.0. [/quote] Do a version on the MONO system, I'm pretty sure the mono that shipped with PPMAC only supports .NET 2.0 which is what I did for my project that targeted mono on the PPMAC. .NET 2.0 includes windows forms so unless you are doing something complex it should be OK for a machine HMI. You should be able to change your Visual Studio settings to compile for .NET 2.0 runtime. In the end we ended up doing a connection to a panel PC over TCP/IP and the GPASCII program (Its quite fast for our needs). KEJR

I would not try to access shared memory in mono directly. It may be able to be done and someone can correct me, but dealing with pointers in c# doesn't exist (by design) so I don't know where you would go with this. Personally, I do everything from P vars as they are really just double floating point arrays in shared memory. All environments can get at them on the PPMAC. Since a Double is the largest data type on the system you can use them for passing everything except strings (I suppose you could, but really??). I use sockets to pass strings back and forth to my C applications, its kind of a pain at first but it works well once you get the hang of it. May I ask why you need to read shared memory *directly* in the HMI? I haven't done this, but I'm pretty sure the "GetResponse" command lets you get at all the servo data structures it can parse, so this handles alot of functionality. KEJR

[quote='HRS' pid='2989' dateline='1326402492'] This is a great thread for those of us with limited knowledge of MONO. I've tried your examples ...thanks works great! I am interested in accessing the P-Variables across the Mono interface. Seems straight forward to import the GetSharedMemPtr() function. Also to include the 'rtpmacapi.h' into the C# solution. Can't seem to make it work though... any suggestions?...you seem to have a bit more depth with this mono stuff. however, the typedef for "pshm" is SHM [/quote]

I know this thread is getting old, but I had one follow up question. Does the development environment you are using support a WYSIWYG type editor, or is it all in code? I know the benefits and downfalls of the two strategies, its just our machine/automation programmers can't be too bogged down in coding the HMI for each of our many machines we build at my company. The hardware and software support is what keeps me thinking of IOS and android. Thanks! KEJR

I highly recommend C# over VC++6.0 unless you need blazingly fast performance (Most basic HMIs running on a modern windows PC shouldn't have issues). You can download the Visual Studio "express" for free for basic use. I was skeptical of the .NET stuff a few years ago but the architects of the system did a lot of things right and you can just code faster.

It sounds like you have some custom C code that reads/writes shared memory in a certain way and you wan to use this in a user phase algorithm? If all you want to do is access shared memory could you write a user algorithm that gets switched on and off via some PVar or other shared memory drivers using a simple IF statement. This gives you control from a user mode C application. if (GetMySharedMem(MyVar)) DoMyUserAlgorithm(); I have not tried this but then you could do a #include on your C source and header file to get your custom C code "into" the user algo file. I haven't tried it for the user algorithm, but it should work, there is no magic to the C preprocessor it'll include C code as well as header files. I *think* this accomplished most of what you want but I don't know the gory details of your shared memory code. KEJR

I just wanted to give other users a heads-up that the stack size change was failing in my code. For some reason even though we were using the POSIX macro for the min stack size it was failing to set the stack properly and going back to the 8mb stack size default. I tried modifying the code to use a 1mb stack size and it worked see below: size_t stacksize = PTHREAD_STACK_MIN + 1048576;//1meg for now... //Set Stack size to something reasonable SysAdv("set stack size returned: %d", pthread_attr_setstacksize(&attr, stacksize)); of course, in the end it should be set to something like this: if(pthread_attr_setstacksize(&attr, stacksize)) SysError("Problem setting stack size for thread: %s", ThreadName); I was OK with the 1mb stack but it is overkill for most apps. If anyone wants to try setting the stack size down until it stops working then it woudl be good to know where the real min value is. I'm not sure why PTHREAD_STACK_MIN is not giving us an acceptable value. KEJR

Hello Shansen, Unfortunately I did not get the time to try this. We ended up concentrating our efforts to do all HMI/database related stuff on a separate panel PC running embedded windows communicating through telnet to GPASCII. So having the latest touchscreen and GUI software kind of just went out the window on my priority list. Is there a certain package you need, or are you just trying to keep up to date? KEJR

You can also use unused P vars. I do this for a non volatile memory interface I wrote. Its a bit safer than shared memory in that there are no pointers involved (so to speak). In other words, P variables are a general purpose double floating point array that you can tap into. Just don't use the upper region set up in your IDE for auto assigned vars, which defaults to P8192. example to fill P0-P999 with constant: #define MY_CONST 1234.56789 int i; for(i=0; i++, i<1000) { pshm->P[i]=MY_CONST; } If you want to get tricky you can get a pointer to any P var as well, just do this: &pshm->P[0] Frankly, working with array indeces is ALOT safer! YMMV... KEJR

Sweet, glad you could use the library. I am not going to speak for DT, but I know on other linux based RTOS I've worked on (RTAI and RTLinux) that you had to compile code with some special makefules and/or flags and then insert them into the kernel with the insmod program. I don't know if the IDE will support this other than the built in hooks now for the user algorithms and things like that. I have to ask though, do you really want to do this? You need to have pretty low jitter requirements to need to do this. Maybe this is where your IRQ comes in? I'm now curious what you are trying to do.

Do you know which versions of their firmware, and what drives (Accelnet or Xenus?). I am using a newer firmware than what shipped with our drives and haven't experienced any problems, but I am by no means a macro expert. We only have Copley drives on the ring.

You are welcome Charles, it was good working with you on this. I just wanted to add that in addition to being able to schedule different thread periods this code has the following advantages: - It cleans up the complex pthread functions. - Foundation of your own company code library. - All your threads can run in the same code base/memory space. - You can organize your thread files how you want in the IDE. -----> i.e. one mega code file or individual broken up files. - You can easily use global C variables across your app. - Your multithreaded RTOS app can be one executable. ----->Easy to copy, download, backup, etc. Note: Please read up on mutex locks when using global vars across different threads (especially writes)! With great power comes great responsibility! Thanks to Delta Tau for allowing us the keys to this race car. I think this has allowed us to do some cool things that you usually have to resort to using an embedded RTOS for and the fact that you get a world class motion controller included is a real perk. ;o) KEJR