rvanderbijl

Thanks Steve! With the Command() function, when it returns, can I assume the command processor has completed the command? Or should I use GetResponse() for that? In my case I'm not interested in the response to the commands, just that they have been executed.

Curt, Following up on this question -- I have gotten it to work fine, however, the speed at which the (even plc0) script executes is a bit too slow for what I'm trying to do. The problem is mostly in moving data around. So I'm porting my code to C. I wasn't able to find anything on this in the documentation -- but is there any way to send a string to the PMAC parser from C? (like the "cmd" command from script) Thanks!

We're using a Power PMAC 465 CPU with the Etherlab EtherCAT stack. The system wasn't running much last night (aside from EtherCAT with one device), and when I looked at the system this morning, it was frozen and the IDE (4, latest) had lost connection to the PMAC. The serial console showed the following: ecm0: BUG! Tx Ring full when queue awake! ecm0: BUG! Tx Ring full when queue awake! ecm0: BUG! Tx Ring full when queue awake! ecm0: BUG! Tx Ring full when queue awake! ecm0: BUG! Tx Ring full wh And yes, the last line was literally cut off like that (guess that's when it crashed). Firmware 2.4.0.180. Any suggestions?

When I went to look for that folder, the entire scripts folder does not exist. I guess that explains the issue I'm having. I did a full uninstall / reinstall of the compiler and now the folder is there. And of course now it builds. I guess the original repair install I did for the compiler did not work.. Thanks for your help!

Eric, The 465 is running 2.4.0.180, I believe the latest that I can download for that CPU. I am running useralgo, and background C. Not sure which one isn't working, the compiler doesn't say. As for the EtherCAT stack, can that be switched to Acontis on the 465 so IDE 4 can be used? Oddly enough, I have another PC with IDE3 on it, and that one had no problem converting the IDE2 project and compiling / downloading it. I'm using that one for now. The PC that is having trouble has a brand new install of the latest IDE4 (and also IDE3) on it. Both IDE3 and 4 can't seem to handle the project. This is a Windows 10 machine. The IDE3 machine that IS working is a Windows 7 machine. Not sure if that makes a difference...

And... I just realized that 4.x doesn't support our EtherLab stack, which is a problem.. I know there is a new Acontis stack out, is there an upgrade path (software) to go from Etherlab to Acontis? (This is on a PPMAC 465)

Hi, We have been happily working with IDE2 for the last couple of years, and since we're about to make some major updates to our project, I figured it was time to check out IDE4. Unfortunately, when opening our IDE2 project and running through an upgrade process (which it claims was concluded successfully), I get this error when building some C code: error : Makefile:327: /opt/powerpc-465-rootfs/usr/src/linux-3.2.21-serengeti-smp/scripts/Kbuild.include: No such file or directory error : /bin/sh: /opt/powerpc-465-rootfs/usr/src/linux-3.2.21-serengeti-smp/scripts/gcc-goto.sh: No such file or directory error : make: *** empty variable name. Stop. I did a little searching in the forum, and noticed this had happened to someone else with IDE3, but the solution to manually install the PP465 compiler did not make a difference for me. Any suggestions on how to resolve this?

Thanks for your reply Curt. I was hoping there was some way to point cmd "%s",x directly to ECAT[0].IOBuffer[x], or a way to use memcpy/strcpy but I guess there is not. Thanks for confirming that, and yes, this will be wrapped into a script with monitoring whether or not the command executed and if there were errors. Incidentally, we're going to be using an EL6695 Master-Master module from Beckhoff to talk to the PMAC in this way (from our other EtherCAT master), rather than using TCP/IP (and gpascii). We have a few variables that need to be transferred in more of a real-time fashion. But for the occasional oddball command, this string buffer seemed like a possible way to tackle that without having to create a custom command structure.

Hi all, I am trying to get some, perhaps odd, functionality implemented on the PMAC. I have a string that is received through EtherCAT, and deposited in ECAT[0].IOBuffer[] at a certain offset. I would like to be able to copy that string and somehow pass it to the cmd command. I'm sure I can do this through some C++ code, but I'm trying to avoid that. It looks like any string manipulation (strcpy/etc) is only using the Sys.CData[] region of memory. I haven't been able to specify the source to be in the ECAT[0].IOBuffer region. I can certainly write a loop that transfers the bytes from the IOBuffer to CData one by one, but that seems rather inefficient... Any suggestions?

Our problems were solely due to a bad board from Delta Tau. Once that was remedied, the principal behind it -- RT C++ task in Xenomai communicating with the PPMAC shared memory and its own shared memory buffer for communications to a UI, and a second comms task (TCP/IP) running in secondary mode Linux, talking just to that shared memory buffer, but NOT using events, just bits in shared memory for synchronization works perfectly and has been 100% stable. There are no issues with RT Tasks accessing the shared memory between primary and secondary mode. As long as you guard it properly using bits in that shared memory, not semaphores or events. Multiple RT tasks running asynchronously should be no issue either (as long as you don't step on data another task is working on, of course...) I think it's a decent architecture for our purposes, and with exchange times across the wire from non-RT linux of around 50ms, not too bad. That is with changed-data checking as well. Not atomic (tag/variable), but block-based. We still use around 25% CPU with our task, and I would love to run it on the other core, but we haven't been able to get that to run properly. It runs, but then crashes after 30 mins to an hour.

JeffLowe, I understand how to do it in THAT direction. I.e. the PC is the server and the PPMAC the client. What I'm looking to do is the reverse. As I cannot count on the PC always being up and running for logging purposes. Therefore the PPMAC writes these log files locally to a USB drive, but I would like to be able to get easy access to them and be able to tail them from a PC (yes, I know, I can tail -f in a putty window, but it's not ideal as I'd like to combine it with other logs being generated on other parts of our equipment). I realize I can install a Samba server on the PPMAC, but before I do that, would like to know if anyone has done that and if there are any gotchas..

I'm wondering if anyone has tried to create a network share on their Power PMAC, accessible from Windows. We have a USB flash key plugged into the Power PMAC that is used to save data that is being generated by our application. Ideally, I would prefer not to have to start winscp or similar to pull data from it, but instead, use a share to access it. Does anyone have any suggestions on what to use?

Actually -- Crashes were still there. But when I was tracing them using the serial port, I noticed the crashes were happening in sshd and Delta Tau EtherCAT code. Not our code.. Some back & forth, and it looks like the memory on our Power PMAC is bad. Waiting for an RMA, and in the meantime we're on our backup board. With no crashes at all..... Happy that our code is running well, but not so happy that I was chasing a bad memory module for over a month. :-/

shansen, I swapped things around as discussed, and my TCP/IP task is now running in user space only. Events and mutexes are all going through shared memory, and I'm no longer seeing any mode switches increase on the RT Task(s) or the TCP/IP tasks after first startup. Hoping that was the main cause of the crashes on the Delta Tau... :) Thanks again!

shansen, thanks for your reply. I completely understand being busy, I'm there right now, and under the gun. Hence my slight impatience. My apologies! That said, I am NOT in the DT-IDE environment for my C++ code (it's C++, I took the DT makefile and hacked it up to work with G++ to build my code). There are plenty of --wrap commands in there. Interesting.. Now I know what these are for! But most importantly, if I do an rt_create_task, I'm definitely in "primary" mode without having to create a kernel module. That's good.. I'll continue down the path of splitting off the comms and RT tasks (as right now the comms are created from the RT task using a pthread_create, which is likely wrapped). As I'm still using mutexes, I assume I shouldn't use the rt_mutex_* function calls either, as they would cause a switch to primary mode on my comms thread. Is using pthread_mutex_* ok to use from within the RT task (assuming it's not wrapped of course)? Or would that cause a switch back to secondary mode? If that's the case, I guess I'm stuck putting a few bits in my shared memory map to handle these instead. That said, is memory allocated using either rt_heap_* from within the RT task ok to use as shared memory between the RT and comms tasks? Or should I still create a kernel module as you mentioned before to create this shared memory? Thanks!!

shansen (and group): Can someone confirm that when you create an RtTask using RtTaskCreate from a .out (user mode, not kernel mode) program, you do not actually have task running in real-time under Xenomai (as mentioned in my post above)? I tried changing all the rt_ calls in my code to standard linux calls (pthread_*), but I still see mode switches (and weird crashes, which I'm still trying to figure out).

Ok.. I think I just realized something fundamental here after doing more digging.. Apparently the assumption that I call an rt_create_task from my user space code (.out) does not make it a Xenomai RT task. Even though it looks like it does, but I guess it runs in non realtime user space? Then I guess I have the reverse problem with my mode switches -- I call rt_ functions in my code, which I guess switches it to primary mode, and subsequently back to secondary. And on top of that, where I thought I had a RT task, I don't?? Gotta say the performance of my non RT task is pretty impressive ;)

Hmm.. I'm guessing that I missed some steps then. I figured if I did a rt_heap_create & alloc from my RT Task that I would get memory I could use between RT and non RT threads, owned by RT.. Is it necessary to make a kernel module? And if so (fairly new to Linux here.. bear with me.. most of my background is on the MS side), do I need to do something special to load/use that?

shansen: Thanks for your reply. I was trying to change the affinity as to not step too much on the DT native processes for servo control that, on my system, run on core 0. Core 1 is mostly idle, and since our task uses about 20-30% CPU, I figured that having it run on the other core should be helpful. But that causes a constant mode switch every time I touch pshm->.... In any case, I'll try to change from events & mutexes across shared memory to a few status bits and see if that makes a difference. That said, I also ran into something else weird, which I posted on the xenomai mailing list. When I try to access malloc'ed memory (or rt_heap_create/alloc) in a RT thread, I see it switch to secondary mode when I do a memset or memcpy on a block larger than 32 bytes (trying to do it on 320k of memory). If I do a loop of 10k iterations of 32 bytes, it works just fine without mode switches. Not cool... I did get a reply, and apparently this can happen when the hardware TLB misses a memory access due to moving too much memory around. I have a layer of shared memory that I exchange with our user interface. To limit TCP/IP traffic, I only send changes which means I need to move around 300-400k around to do comparisons and set up blocks to be transferred. Perhaps with these limitations we need to re-think our architecture....

Update -- I implemented a new task with the code that shansen suggested. I'm still seeing a ton of mode switches, but I think I may have an idea where they're coming from -- As part of accessing the shared memory, I have events and mutexes between the realtime and the TCP/IP task to synchronize the two of them. I suspect the rt_mutex_acquire calls are forcing it back into real-time mode and then the subsequent socket write back out. shansen, how did you solve the mutex issue in your application (assuming you use them)? I googled it a bit, but haven't found any hints yet..

Thanks for your detailed response! I did not know about the dump data when the Delta Tau crashes. Unfortunately I don't have a PC nearby, but I will set one up to capture any crashes (of course, when I was there with my laptop for 4+ hours, it never crashed.. :) ). I have also witnessed at least 2 crashes while my C++ code was NOT running. Just the Delta Tau PLC and Motion code. There is a small chunk of C code in there, but I can't imagine it is responsible for a crash (custom user phase routine, nothing exciting in there). Also, it appears when this happens, the entire system becomes non-responsive (no response on terminal sessions or pings), but after 2-3 minutes, it's rebooted itself. Looks like the watchdog must have kicked in at that point... Curious -- Can you have a thread inside a real-time task run in primary mode? Or does it need to be a separate task? I currently have a thread dedicated to communication over TCP/IP that already uses my own chunk of shared memory to talk to the other threads responsible for controlling the system. Also -- Have you had any experience with the dual core PPMAC? I tried to change the CPU affinity to run the task on the other (much less busy) CPU, but then I incur mode switches for every access into pshm-> memory... That caused a consistent crash after 30 mins or so.

I am wondering if anyone constructed an application like ours on the Power PMAC successfully. We have a fairly complex system with many axes that are being controlled from within the Power PMAC environment. However, we also have a large number of EtherCAT IO points handled by the Delta Tau. Most of these are used for more generic machine control tasks such as valves and other process control items. At this point, we wrote a separate C++ task in Xenomai that handles these IO points by directly interfacing to them through the PMAC shared memory pshm->Ecat[0].Io[n].etc. That seems to work very well, and besides the IO interface, this C++ code acts as the "master" in all higher level motion control-related tasks. The difficulty seems to come into play when this code, which directly talks to our UI over TCP/IP, rapidly sends data back & forth. This causes Mode Switches in Xenomai, which, in turn, seem to lead to instability of the entire PMAC. We have had scenarios where the PMAC becomes unresponsive after a half hour or so and needs to be power cycled. Not acceptable in our system. From what I read about these Mode Switches (MSW; cat /proc/xenomai/stat), they're hard to avoid if you are doing realtime stuff (reading & writing to the pshm-> structure) and also doing TCP/IP or file tasks that involve the generic Linux OS. At this point, I'm looking for suggestions on solving the source of this issue. I can move my C++ code to another system (i.e. not running on the Xenomai kernel on the PPMAC), but then I need fairly rapid (1 ms) access to the entire pshm-> structure somehow from outside the PMAC. Or.. I need another way to shuttle data from one side of the fence -- Xenomai -- to Linux (and back) so it can be sent over TCP/IP without incurring a mode switch. Any and all suggestions are welcome!

That's great news Steve! Any thoughts on timing of that release? Thanks, Robbert

Steve, I have not yet. Mainly because I haven't been able to figure out how to get it to back up.. Reading the IDE manual, it looks like you can either do this through a shared drive or a USB stick on the PMAC itself. I'm using the USB port on the PMAC to mount an external stick for the C/C++ development, logfiles, etc. I'm guessing it doesn't like the fact that there is already a mount point in use as no USB stick target shows up. And I haven't been able to figure out the shared drive option yet. I'll dig into that a bit more. But more importantly, do things such as packages installed, mount configuration, etc. also transfer over in an image backup? And if I restore the image to another PMAC, will I have the same issues I have with the eth0/1 ports as I did with WinImage? (Incidentally, I was able to resolve the issue with WinImage and eth0/1 by using a serial cable and fixing the 70-rules ... file manually. Not ideal, but it appears that's all that's needed to get it to work if I need to clone to a new/different PMAC). Thanks, Robbert

Steve, I completely understand the mechanism here, but unfortunately it's a bunch of extra steps you have to take every time you make a change and you commit to source control. Easy to forget if you didn't remember changing something in the setup. And if someone else in the team modifies something, and you're not paying close enough attention when you clone or update your repo from the server, you may not know you have to import... So if in a future version of the IDE, this behavior could be different (and instead of using a database, use a set of XML files to store this information in the project folder), that would make it much more compatible with source control. And much more intuitive for us developers who have to scratch our heads as to why part of the project didn't transfer with all the project files... Thanks, Robbert