ibisjoe

under Delta Tau, there used to be a "Serial Number - Part Number - Rev Info" link, "http://www.deltatau.com/sn/" - where is it now?

The linux headers are supplied with the IDE. They are located C:\DeltaTau\PoewrPMAC\Compilers\opt\powerpc-405-rootfs\usr\src\linux-2.6.30.3-xenomai-2.5.6. these are the headers the IDE compiles with to build kernel modules for usralgos. Thanks. I was looking on the PowerPMAC itself since that is where I was attempting to compile device drivers.

does anone know how to obtain the linux headers for the version of Jessie running on the PowerPMAC (linux-headers-2.6.30.3)? "apt-get install linux-headers-$(uname -r)" returns: "Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package linux-headers-2.6.30.3"

We have seen similar failures on Acc-24E3 boards: on the amplifier mezzanine card, the 'Clare LBA716 Dual Single-Pole OptoMOS® Relays Normally Open & Normally Closed' relays have failed. Most of the systems have been running for years without problems.

We have a PPMAC system here in a lab that is used to control a rotary table and read encoder position along with some A/D input values. The symptom of this PPMAC is that too appears to "go to sleep" in that network communications are lost; it will no longer even respond to a ping request. It is however running its PLCs, etc. and maintaining the rotary table rotation and position. It is currently configured with a STATIC IP address. Two things that we have found: 1.) the serial port is still available and accepts GPASCII commands; 2.) you can use "ifdown eth0" followed by "ifup eth0" to cause it to reconnect onto the network (for a while). We have never actually tracked down what is happening (we've tried a few Linux TCP programs) but recently I moved the ethernet connection to a router in the lab that is active with a number of other devices and Windows machines - it has never disconnected since. There is a suspicion that the original network drop is configured with/for VOIP phones on it. Any further ideas/suggestions are welcome. - Joe

the Sys.Time is in seconds, so it would be 1.79769 * 10^308 / 86400 seconds per day / 365 days per year ~= 5.7 * 10^300 years.

this was previously posted on the Bugzilla site: Joe 2013-01-21 13:20:56 PST When attempting to add a Q-Variable reference to a Detailed Plot by selecting, for instance, CSGlobal.qBusy (which IS defined) for C.S. #n, it will add the requested reference but always returns a value of 0(zero) when it is gathered/plotted.

This was posted on the Bugzilla site but the response was that the feature IS NOT supported (uh, but it USED TO BE): Joe 2013-01-21 13:07:11 PST A feature that used to work in the v1.4.0.27 firmware is now broken. Specifically, if you had an M-Variable defined such as: CycleStopPBOff->Acc65E[0].DataReg[0].2.1; // (CYCLE STOP Pushbutton OFF) and you attempt to add it to a gather by selecting under a Detailed Plot via the defined User Globals, you now get the message: "Acc65E[0].DataReg[0].2.a is not a valid command." That used to work. Also, if you attempt to use a previously setup Gather using the same variable, you will receive the message: "/var/ftp/gather/GatherSetting.txt:22:17 error #31: invalid function in equation: gather.addr[15]=Acc65E[0].DataReg[0].2.a UnlinkGatherThread: root@147.185.x.xxx:/opt/ppmac#" [reply] [-] Comment 1 Henry Bausley 2013-01-22 08:27:10 PST (In reply to comment #0) > A feature that used to work in the v1.4.0.27 firmware is now broken. > Specifically, if you had an M-Variable defined such as: > CycleStopPBOff->Acc65E[0].DataReg[0].2.1; // (CYCLE STOP Pushbutton OFF) > and you attempt to add it to a gather by selecting under a Detailed Plot via > the defined User Globals, you now get the message: > "Acc65E[0].DataReg[0].2.a is not a valid command." > That used to work. > > Also, if you attempt to use a previously setup Gather using the same variable, > you will receive the message: > "/var/ftp/gather/GatherSetting.txt:22:17 error #31: invalid function in > equation: gather.addr[15]=Acc65E[0].DataReg[0].2.a UnlinkGatherThread: > root@147.185.x.xxx:/opt/ppmac#" You cannot gather a user bit field you must gather the entire register.

I would like to be able to change the COLOR of the SENDn messages (as the IDE does when you configure a motor setup) - is there a special prefix or (terminal) ESC sequence that can specify the color?

Charles: Everything you stated is true. And I ended up using "C" code to perform the initialization, just as you described. The fact remains, however, that from the terminal window or the 'GPASCII -2' command, I must know the P-Variable INDEX in order to perform a dynamic re-assignment; since they both act like 'script' programs, that won't work there as well because when you reference "MyGlobal2" you will get "Pnnnn" substituted. So the only recourse is to do the substitution of the index by hand (since to re-define the ptr you need to enter "MyPtr->Sys.P[nnnn]"). I understand how the Script vs. C enumerations conflict in this case so I'm not sure how to do what I want without some sort of smart PPMAC function. - Joe

I do if I want to be able to change it without recompiling...on the fly.

As I stated previously, The point is that I want to be able to SET the pointer definition using symbolic names assigned by the IDE (I don't want to have to know that 'a' refers to P[1]); this also means that I can refer to 'a' in the terminal window by just typing "a" and it will respond with the current value of 'a', and also, I can have an entirely independent C program (running outside the IDE) lookup the value of 'a' by name and it will give me the definition/value assigned via the IDE. This allows me to make the source of the 'ptr' data(what it points to) changeable/selectable and it can point to any hardware or software(perhaps the result of a calculated quantity like a P-Variable) value, as desired.

The point is that I want to be able to SET the pointer definition using symbolic names assigned by the IDE (I don't want to have to know that 'a' refers to P[1]); this also means that I can refer to 'a' in the terminal window by just typing "a" and it will respond with the current value of 'a', and also, I can have an entirely independent C program (running outside the IDE) lookup the value of 'a' by name and it will give me the definition/value assigned via the IDE.

I have a '.pmh' file where I am declaring some 'global' variables with changeable 'ptr's to them. I am using the IDE to declare these and what I's like to be able to do is: global a; global b; ptr var->a; 'ptr' definitions such as these seem to end up having either self-referenced ("->*") definitions or, at times, pointers to some Motor[n]. definition when you report them from the terminal window. I think that part of the problem is that in the Script world, 'a' == P[nnnn] where the IDE sets 'nnnn' and so when I set "ptr var->a" it hasn't yet assigned the 'nnnn' and is confused when it downloads/uploads to/from the PPMAC. I know that a definition such as "ptr var->Sys.P[nnnn]" works fine, but I don't know what the IDE is going to assign 'nnnn' as. What's the solution?

I sit corrected. Thanks.