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?