smr99

On the topic of replacing the battery: I looked at the Turbo PMAC User, Hardware, and Software Reference Manuals for information on the type of battery and how to replace it. All I could find is: "The battery is located at component BT1." Are more details available somewhere? I am not physically on-site, so I can't check: If we open the computer is it easy enough to find the battery? Does the battery have sufficient markings to find its part number for replacement?

Thanks, Charles. I didn't try exactly your test, but what we did is overwrite the problematic P-variables with valid data. The system began to function normally again, so I believe that reading does work. At least most of the time. What I was really trying to ask is whether we can rely on this or whether it may flake out occasionally. I am going to recommend replacing the battery to avoid future problems, but was just worried about the interim.

I inherited a system based on Turbo PMAC2 PCI Ultralite that has been running with little trouble for years. Unbeknownst to me, the system has the battery-backed RAM option (16B, I believe) and we use I46=1 to keep the P-variables in BBRAM. The system has been operational for well over 5 years and to my knowledge the battery has never been changed so I expect it is dead. And therefore the contents of the P-variables will be garbage at boot-up. What I'm wondering is: can this possibly cause corruption after writing good data to a P-variable? For example, suppose I say P101 = 33; is it possible that a later read from P101 will be corrupted due to the dead battery? Thanks, -Steve

Hi, Trig functions like sin() also have this behaviour under optimization, FWIW. I also discovered the "define it yourself" workaround. The biggest issue for me is that the build & download process does not report this and the only indication you have is that something fails at runtime and you're left guessing. See http://forums.deltatau.com/bugzilla/show_bug.cgi?id=1082

Hmm. The empty example project failed to build with IDE 1.7, too; c.f. http://forums.deltatau.com/bugzilla/show_bug.cgi?id=1111. I'm a little troubled by this, for surely building the example project should be part of the Q/A before releasing an IDE. Is this kind of Q/A being done and not catching these failures, or the Q/A is not being done?

I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC? OK, so a simple experiment shows that 1.7 / firmware 1.6.1.1 is still affected by this bug. I compute the time taken by our RTI CPLC by subtracting the values of GetCPUClock() at the end and beginning of realtimeinterrupt_plcc() and put it into a P-variable. In the watch window I can see that this value greatly exceeds Sys.RtIntTime. Next question: is this bug fixed in the upcoming 2.0 release?

I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC? OK, so a simple experiment shows that 1.7 / firmware 1.6.1.1 is still affected by this bug. I compute the time taken by our RTI CPLC by subtracting the values of GetCPUClock() at the end and beginning of realtimeinterrupt_plcc() and put it into a P-variable. In the watch window I can see that this value greatly exceeds Sys.RtIntTime. Next question: is this bug fixed in the upcoming 2.0 release?

Given that this comment was made in April 2014: I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC?

Given that this comment was made in April 2014: I want to ask whether the IDE 1.7 (from June 2014) suffers from this bug? Or does Sys.RtIntTime include the RTI CPLC?

This is the symptom of this bug: http://forums.deltatau.com/bugzilla/show_bug.cgi?id=698 Note that there is a crude work-around: build once, let it fail, manually copy bin\Debug\usralgo.ko to bin\Release, then build a second time (should succeed). ... and this is the symptom of a different bug (which I'm sure I reported but I can't find just now): compiling C Language usrcode creates two outputs: usralgo.ko and usralgo.so. Unfortunately, both build processes use the same msg.log and err.log files so diagnostics in the first build are overwritten during the second build. The second build can sometime succeed while the first failed, so you end up losing information. My present work-around is to run the makefiles by hand, one-by-one so that I can examine the logs.

This is the symptom of this bug: http://forums.deltatau.com/bugzilla/show_bug.cgi?id=698 Note that there is a crude work-around: build once, let it fail, manually copy bin\Debug\usralgo.ko to bin\Release, then build a second time (should succeed). ... and this is the symptom of a different bug (which I'm sure I reported but I can't find just now): compiling C Language usrcode creates two outputs: usralgo.ko and usralgo.so. Unfortunately, both build processes use the same msg.log and err.log files so diagnostics in the first build are overwritten during the second build. The second build can sometime succeed while the first failed, so you end up losing information. My present work-around is to run the makefiles by hand, one-by-one so that I can examine the logs.

This is expected behaviour: /etc/profile is for login shells only. Assuming that the "system" command is executed by a shell, you should be able to use the syntax "VAR=value command" to do what you want. Note that there is space (not semicolon or anything else) between the variable assignment and the command. So in your case the plc should contain: "LD_LIBRARY_PATH=/path1:/path2:... nohup /usr/local/bin/ads/capp1.out &> /var/log/ADS.txt &". If that doesn't work, the other way to do it is: create a small shell script that sets the variable then runs your capp1.out. Then invoke this script from the startup plc.

This is expected behaviour: /etc/profile is for login shells only. Assuming that the "system" command is executed by a shell, you should be able to use the syntax "VAR=value command" to do what you want. Note that there is space (not semicolon or anything else) between the variable assignment and the command. So in your case the plc should contain: "LD_LIBRARY_PATH=/path1:/path2:... nohup /usr/local/bin/ads/capp1.out &> /var/log/ADS.txt &". If that doesn't work, the other way to do it is: create a small shell script that sets the variable then runs your capp1.out. Then invoke this script from the startup plc.

I have read that at least one other group has moved away from the Delta Tau IDE: in http://forums.deltatau.com/showthread.php?tid=910&pid=3516#pid3516 shansen reports using Eclipse for development. In our case, we have hand-written makefiles because the DT IDE provides no support for changing options. For example, I need to link against the Xenomai "native" library for the RTI CPLC build. I'm looking for some tips specifically related to conveniently deploying the build objects to the Delta Tau. My current procedure is to use the DT IDE to "Build and Download", then I rebuild the RTI CPLC by hand and overwrite the IDE-downloaded file. I would like to automate this. Preferably without involving the IDE. I have learned the hard way that just putting build products in the right place is not enough. One also has to log into the Delta Tau and run "projpp". To shansen: in the quoted post, you made reference to rough notes on using Eclipse. Are you willing to share these? Is the deployment simply arranging the files properly in "/var/ftp" and running "projpp" or am I missing a step?

I have read that at least one other group has moved away from the Delta Tau IDE: in http://forums.deltatau.com/showthread.php?tid=910&pid=3516#pid3516 shansen reports using Eclipse for development. In our case, we have hand-written makefiles because the DT IDE provides no support for changing options. For example, I need to link against the Xenomai "native" library for the RTI CPLC build. I'm looking for some tips specifically related to conveniently deploying the build objects to the Delta Tau. My current procedure is to use the DT IDE to "Build and Download", then I rebuild the RTI CPLC by hand and overwrite the IDE-downloaded file. I would like to automate this. Preferably without involving the IDE. I have learned the hard way that just putting build products in the right place is not enough. One also has to log into the Delta Tau and run "projpp". To shansen: in the quoted post, you made reference to rough notes on using Eclipse. Are you willing to share these? Is the deployment simply arranging the files properly in "/var/ftp" and running "projpp" or am I missing a step?

We are presently using IDE 1.5 with firmware 1.5.8. I would like to use a newer IDE, but found that our C Language RTI code doesn't run. Unfortunately, there are no diagnostics so I'm not sure why. The code does run with firmware 1.6.1.1. Is there a coupling between the IDE and firmware versions?

An update to previous post: after changing my password, I was successful in performing a backup to the network drive. But the restore fails. As noted before, the disk is about 7.5GB, so the "fullImage.bin" file is also around that size: [code] # ls -l /media/shared/PowerPmacDiskImage/ total 7835521 -rwxrwSrwx 1 root root 8019509248 2014-09-25 09:41 fullImage.bin -rwxrwSrwx 1 root root 4063232 2014-09-25 09:29 uImage.bin -rwxrwSrwx 1 root root 63 2014-09-25 09:29 VersionInfo.txt [/code] The restore process attempts a sanity check that appears to fail because the file is larger than 32 bits: [quote] Stage 1 of 7: Sanity check (for space) before we do the actual disk image 8019509248 Error occured during host file size calculation with error message: Value was either too large or too small for an Int32. [/quote] Has anyone successfully done a Disk Image backup / restore ?

Has anyone had success creating a disk image with the "Backup" tool of recent IDEs? I just tried the IDE version 1.7.0.53, unsuccessfully. I want a complete disk image including the kernel, so I selected "Disk Image" tab. The first thing I tried was backing up to a local SD drive. It started off promsing: the kernel was written there and then "dd if=/dev/sda ..." started. The sda drive has two partitions of 6.5 GB and 1 GB, while the SD card partition is 30GB, so there was plenty of space. Things went fine until the output file hit the 4GB mark, when "dd" failed complaining "file too big". I presume this requires either a different file system (the SD card is vfat) or maybe the system is just missing large file support. Anyway, there is also an option to back up to network, so I tried that. From my windows machine, I created a shared drive and successfully mounted it on the delta tau by hand (using smbmount). I was able to write files there. But the Backup tool in the IDE is apparently unable to mount it (I double-checked the user name and password several times). This turns out to be due to my password containing some characters that make the shell unhappy. I'll change the password and try this again. Has anyone succeeded in obtaining a Disk Image to SD card? I'd appreciate some hints! My next idea is to try reformatting the SD card with an ext4 filesystem and see if I can write it there.

I presume you are referring to the post by "DavisG". Is there no documentation more official than this? My immediate problem is that restore instructions in this post suggest that there is a single partition on the drive (he talks about "drive E" only). However, WinImage indicates the .vhd file for 1.5.8 has 2 partitions. I'm not sure how to reconcile the two. Anyone?

Our system consists of several C-language servos, a C-language RTI plc, and one multithreaded “Background” C program that functions as a bridge to our HMI running on a different machine. This bridge program does logging to disk and communicates over a socket to our HMI to receive commands and send status. The bridge communicates with the RTI code using pushm shared memory and two FIFOs. The two FIFOs are used for the RTI to send data streams that are logged to disk: they are written in the RTI (non-blocking, discarding a write if the FIFO is full) and read in the bridge. The two FIFOs contain information to be logged for troubleshooting; one contains motor and servo values at each RTI cycle, the other contains other asynchronous "events" such as detected faults. The IDE-generated makefile wraps many of the posix calls to call xenomai-provided functions. Since pthread_create() is wrapped, all the threads in the bridge end up as xenomai threads. In order to mediate access to shared data, semaphores and mutexes are used; these are also wrapped so we end up using xenomai ("primary mode") calls for these. On the other hand, the I/O is done on standard Linux file descriptors (socket, disk files, and the FIFOs) and handled in the linux ("secondary mode"). As a consequence, I can see each of these threads making 100-200 mode switches per second, correlated with the job each is doing. For example, one thread reads a FIFO that is written at 250 Hz by the RTI and does 250 mode switches / second. Ocasionally, the bridge program will lock up. This was ultimately traced to these mode switches: the process was stuck in a call to xnshadow_harden(). The current Delta Tau build uses xenomai 2.5.6 and indications are that there are a lot of mode-switching bugs in this version: http://www.xenomai.org/pipermail/xenomai/2014-June/031120.html Thus it seems prudent to reduce the mode switches. For the background program, we can arrange to avoid the wrapping and this indeed avoids creating xenomai threads and avoids all mode switching. However, we are still faced with mode switches in the RTI itself. The RTI is by necessity a xenomai thread and, due to calling write() on the FIFO, suffers a mode switch each time it runs. So we are now considering how to replace the use of FIFO with something that incurs no mode switching. In short: we want to write in the xenomai thread and read in a linux thread with no mode switching on either end. Is there an out-of-the-box solution I've overlooked? Since we have a shared memory I can imagine using a lock-free queue, though I haven't yet looked around for an implementation. Ideas? I'd like to hear how others have solved a similar problem of getting log data from the real time to a background process. Incidentally, sometimes the system will incur a hard watchdog. My hypothesis at this point is that the same bug that bites us in mode switching the background process may be biting during an RTI mode switch causing the RTI to hang, not be able to update the hardware watchdog counter, and boom! Anyone have thoughts on this?

OK. I think we agree now. Thanks! -Steve

OK. So to understand better, I tried replicating this in a simple test case where I have code that uses open() both in the main program and in a shared library (liba), linked together with a second library (libb) that provides __wrap_open(). I built both with/without --wrap and what I observe is that only the main program call is wrapped. The shared library function myopen() does NOT call the wrapped open(). Perhaps I've missed something subtle. The attached tarball shows my experiment. ld-wrap.tar.gz

The application in question is basically a bridge to our HMI running on a different machine -- thus the socket -- and yes, it is mainly doing logging and socket I/O. We use the pushm to send commands down to the RTI and servo routines (all written in C) and read back status. Additionally, we have a pair of FIFOs sending data streams from RTI to the bridge process. Apart from pushm and a couple other calls to start/stop the RTI, the code looks like a standard POSIX program. Given that, I was quite surprised that its threads show up in /proc/xenomai/sched at all. As a guess: I suspect the main thread is registered due to something in InitLibrary(), while the other three are due to wrapping of pthread_create(). They all appear as PRI=1, which intrigues me because "gpascii" instances have PRI=0. The reason I was asking about threads is that our bridge suffers from lockups, sometimes followed by a hard watchdog. During one lockup, with the help of /proc/PID/status and /proc/PID/wchan, I was able to determine that the process was stuck in the system call "xnshadow_harden" (a Xenomai call). As I say, I was quite surprised that these threads had anything to do with Xenomai. But /proc/xenomai/stat shows that 3 of the 4 threads are performing a huge number of mode switches -- almost the same number as the context switches -- which probably explains the call to xnshadow_harden(). Since it was stuck in the syscall, I wasn't able to get gdb to tell me anything useful (it didn't succeed to break into the program). In another thread (http://forums.deltatau.com/showthread.php?tid=1654) I posted about the fact that calls in the bridge itself are wrapped but calls in a shared library are not. In particular, the bridge main thread uses pselect() on the FIFO and socket file descriptors. The FIFO read() calls are done in the bridge (hence wrapped) but the socket send/recv are done in the library and are not wrapped. For that matter, the FIFO write() calls in the RTI CPLC are not wrapped either. Have you any thoughts on whether this is a problem? Are you referring to http://forums.deltatau.com/showthread.php?tid=652 ? That was an informative thread, thanks!

That is the root of the inconsistency: if I were to directly call socket() in my background program, it would use the wrapped function; but within the library, it uses the unwrapped socket(). Thus the behaviour is different. Why? Correct. But select() and pselect() are basically identical in function if you don't use signal masking (as we don't). So again there's a change in behaviour if I choose pselect() over select(). It seems to me if Xenomai needs to wrap one, there's some chance that using the unwrapped alternative may confuse Xenomai.

How is that possible? From C, the P-vars are just an array of doubles within "struct SHM". Is the difference between "pushm + index" and "pshm->P[index]" significant in your application?