shansen

Why doesn't zeromq work with the IDE? What errors are you getting? I think you should be able to get this to work, but it may require manually editing the Makefile and adding a line to link your Capp against the compiled zeromq library. Another option is copying your Capp code to the Power PMAC and compiling it locally.

piefum: If you only need C applications, I would recommend Delta Tau's IDE. It is already set up with this capability, and it is much easier to use. That being said, my company has been using Eclipse instead of Delta Tau's IDE for several years now. Like anything, there are benefits and drawbacks to either method. Using Eclipse is not "easy" or "out-of-the-box" like Delta Tau's IDE. But, it does give us much more flexibility for organizing our projects, and allows us to compile any C or C++ code that can run on the Power PMAC.

piefum: I don't know why it isn't working with the IDE, but I suspect there is a way to get it to work. I'm not much help in that department as I haven't used the IDE for several years. Maybe someone else can chime in about how to add a 3rd party library within the IDE. Regarding your second question, I know it is possible to use Mono to run C# apps on the Power PMAC, but I haven't done so myself.

I haven't tested it, but a quick search shows that Qt4 should run on the version of Debian that the Power PMAC is using.

It looks like your install is failing because the file system is still mounted read-only. To mount it read/write, use: mount -o remount,rw / Then, install the library. When you're done, mount the file system as read-only again: mount -o remount,ro /

smr99: The PPMAC has 2 partitions, one formatted with ext2 (Linux) format, and another using FAT32 format. Windows cannot read ext2, so it will only mount the FAT32 partition. This is the E:\ drive DavisG was talking about. The Power PMAC project is stored on the FAT32 partition. The Power PMAC firmware and operating system files are stored on the ext2 partition. If you have problems identifying the partitions, the FAT32 partition is usually smaller than the ext2 (on a test PPMAC here I'm showing 6.5 GB for ext2 partition and 948 MB for FAT32 partition). But this might depend on which PPMAC you are working on.

piefum: I just downloaded zmq and compiled it on the Power PMAC without issue. Also, the test examples seemed to be running correctly. However, I am not sure if it is supported through the IDE.

MClement: I couldn't get it to work without some step requiring root access. Perhaps this is a silly question, but do you need to have users on the Power PMAC other than root? I only ask because our products support multiple user accounts, but it is done entirely via our code on the Power PMAC and the communications interface. By doing it this way, we can control exactly who gets to do what.

MClement, have you seen this link? http://forums.deltatau.com/archive/index.php?thread-466.html Not to get this discussion too far off track, but I'll add my two cents. I understand that Delta Tau has to put limits on the Power PMAC because in the end they have to support the product. There are many individuals out there who would take a fully unlocked Power PMAC and install tons of third party software, ruin the system's determinism, and then demand that DT fix the errors that they themselves caused. As DT only has a fixed number of resources for customer support (as do all companies), they tend to lock products down so uninformed users can't get themselves into to much trouble. That being said, my experiences with the Power PMAC have proven to me that there are work-arounds for almost every issue. The freedom to write custom code down to the kernel level has allowed my company to: 1) create a custom Ethernet protocol specifically to suit our needs 2) develop a new gpascii-like program that can parse custom commands 3) eschew the DT IDE altogether in favor of third party IDEs 4) interface to many fieldbus protocols without having to drag Delta Tau through the muck (because we can write the code ourselves!) Using MClement's car analogy, sometimes you just have to remove the rev limiter!

OK, I did end up finding a solution, although I'd still like to hear if anyone has a better way of doing this. To check if an Mvar is defined, I defined a 2nd Mvar that points to the first Mvars' pointer location (see Turbo software reference manual, memory map section). The Turbo PMAC2 Mvars pointers are located at L:$4000-L:$5FFF. M101->X:$4064,24 ;(point to M100 pointer location) IF(M101>0) P100=1 ELSE P100=0 ENDIF ;(check if M100 is defined or not)

Is there anyway to check if an Mvar isn't defined within a PLC? Something like: IF(M100-> = *) P100=1 ELSE P100=0 ENDIF

Many cheap SD cards use notoriously poor quality flash. If you buy a high quality SD card, then you are probably correct that there isn't any difference.

How about one of these? http://www.amazon.com/SanDisk-Cruzer-Low-Profile-Drive--SDCZ33-016G-B35/dp/B005FYNSZA/ref=sr_1_1?ie=UTF8&qid=1404414404&sr=8-1&keywords=small+usb+drive It is very small and fits right in the front of a Power PMAC without sticking out too far. They will also last longer than an SD card (but that depends on how often you write to it).

Is there any particular reason you don't want to use an SD card or a USB stick? That seems like it may solve both issues (limited writes + file system corruption).

Here is a bash script that shows how to sync the 3 main non-persistent mount points (/var, /etc, and /root): #!/bin/bash # Synchronizes /var, /etc, and /root echo "Starting sync." echo "Mounting file system as read/write" mount -o remount,rw / # # Copy /var to persistent memory # cd /.readonly/var-tmpfs-mirror/ echo "Copying new files from /var." cp -a * ../var &> /dev/null # # Copy /root to persistent memory # cd /.readonly/root-tmpfs-mirror/ echo "Copying new files from /root." cp -a * ../root &> /dev/null # # Copy /etc to persistent memory # cd /.readonly/etc-tmpfs-mirror/ echo "Copying new files from /etc." cp -a * ../etc &> /dev/null # # Sync to disk # echo "Syncing file system." sync echo "Mounting file system as read only." mount -o remount,ro / echo "Sync completed." This script should be placed in /bin so it is persistent. Also make sure the script has full permissions (chmod 777 /bin/). From what you have described, it sounds like the best procedure is for your background thread to write constantly to . Then every (10 seconds, 1 minute, 10 minutes?) issue this bash script to save all of the written data to disk. If you use the script above, you probably should remove the copy logic for the locations you aren't using (if your folder is in /var/, there is no need to copy files and sync from the other locations). One problem you are going to run into is that the Power PMAC has a default setting that prompts you to check the filesystem after the drive has been mounted/umounted a certain number of times. You will start getting an "unchecked filesystem" message every time you mount/unmount. To disable this message, issue the following command from a Linux terminal: tune2fs -c 0 /dev/ To find , you can check the startup log: dmesg | grep root=/dev Kernel command line: root=/dev/sda2 ro rootdelay=8 rootfstype=ext2 console=ttyS0,115200 In the above case, my drive was /dev/sda2. The only thing I'm not sure about here is the viability of constantly mounting/unmounting. It may be better to leave the folder mounted as read/write, but this could cause disk corruption issues if the Power PMAC looses power while you are writing to disk. Also, flash memory has a limited lifetime in terms of write cycles, so doing continuous writes may not be the best solution. Perhaps someone from DT could weigh in on these issues?

MClement: We have traditionally kept our persistent data in a folder under /var (/opt works too, but the Power PMAC data is stored there by default). The only caveat is that /var is not persistent, so we have to sync the filesystem whenever a change is made. You can create a folder in a persistent location (say /bin or /opt), but if the Power PMAC crashes while that location is being written to it can cause disk corruption. The sync method I described previously gets around that issue. How frequently do you need to make changes? Could you buffer the changes and write to disk in a slower background thread? If you buffer the changes, you could mount /.readonly/ as read/write and copy the data directly to persistent memory every time you need to make a change.

OK scratch that last, the IPC functions might NOT be there in 2.5.6. I'm going to try to compile the IPC functionality from 2.6.3 into a module that will work under 2.5.6. Not sure if that will be too much work or not, but I'd also like to have some form of real-time IPC for Power PMAC projects.

smr99: I just saw your post on the Xenomai mailing list. Have you checked out RTDM IPC like Philippe suggested? It looks like it fits your requirements pretty well. Although the 2.5.3 API docs don't list any IPC functions for some reason, it looks like they are all there. If you installed the DT IDE, the source code can be found at: C:\Program Files (x86)\Delta Tau Data Systems Inc\2.0\Power PMAC Suite\powerpc-460-linux-gnu\opt\eldk-4.2\debian_rootfs\usr\src\xenomai-2.5.6\ksrc\drivers\ipc Also, here is the 2.6 API for IPC (which includes all the relevant functions): http://www.xenomai.org/documentation/trunk/html/api/group__rtipc.html

Jeff, this thread may help you out: http://forums.deltatau.com/showthread.php?tid=1081

For what it's worth, my company is currently doing something very similar (e.g. logging data in a Xenomai thread and then using a background thread to process the data). We ended up mmap'ing a block of memory and sharing it between the two threads, and using this method we do not incur any mode switches except for the first mmap() on powerup. If you want a more out-of-the-box solution (a la Delta Tau), you could use pushm memory as a shared buffer. However, you do still have to come up with a scheme for how data is written to memory and then interpreted on the other end, but that could be simple depending on your implementation.

daves: I'm not sure what software you're using here, but the error is just saying that you are trying to connect to an IP address that has a different RSA key from the last time you connected to that IP address. Everytime I connect WinSCP to a new Power PMAC (which of course has a new RSA key) I get this message until I permanently accept the new key.

OK smr99, I just re-read my previous comments and I typed it backwards! If you link liba with --wrap=open, calls to open() via the library will be wrapped regardless of whether or not the program was linked with --wrap. BUT, if the same program calls open() directly (e.g. not through the library) and the program was compiled without --wrap, open() will not be wrapped. So, the --wrap argument goes with whatever is actually calling the function (be it library or program). If you are directly calling the function from BOTH library and program and want it to be wrapped in all cases, both need to have the --wrap argument. So back to your original point: if you want your libraries to call the Xenomai wrapped POSIX functions, make sure your Makefiles for the libraries include the --wrap argument.

If you can log in and execute gpascii with PuTTy, then the problem is probably in your application. A few years back, I wrote an app in C# that connected to a PPMAC via SSH and then used gpascii for sending commands. I ended up not using that app, but I don't think there's any inherent reason the same technique wouldn't work with python. SSH is SSH, so it should be the same. Just to mix things up, you could try passing an argument to gpascii: gpascii -2

smr99: EDIT: My comment was backwards! It depends on how the LIBRARY was linked, not how the program was linked. If you call pselect(), your code will momentarily be switched from primary mode to secondary mode. If that is not desired behavior, then you should use select() and wrap it in your library's linker flags.

smr99: The wrap statements force the linker to use the Xenomai functions instead of the standard posix functions. See http://www.xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Under_the_hood:_the_--wrap_flag. To figure out what is causing the hard watchdog, plug a serial cable into the serial port and you should get a debug output when the processor crashes. This can help you troubleshoot what the problem is and where it is occurring. I can't say more without seeing your code. Regarding pselect(), off the top of my head I don't think Xenomai has a wrapper for that function (which explains why it isn't wrapped).