ibisjoe
-
Posts
25 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Downloads
Posts posted by ibisjoe
-
-
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"
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"
-
Three times in the past few weeks we have had failures of the Amp Enable on the Acc24E3 cards at three different customer sites. These are operating Glentek and Trust drives, both at TTL levels with internal 10k pullups to 5V. These machines have been functioning normally for periods up to two years. Are these physical relays, and if so, what is the MTBF/MTTF?
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.
-
Not that I know about. But you should tell which type of PPmac and the current firmware version you are using as that could make a difference in debugging technique. For instance, Motion Machine has no RS232 port so the above tests are harder to do. In any case, it is good to first know what is happening.
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?
-
I see what you are saying. Indeed when you try for example:
global MyGlobal1,MyGlobal2;
ptr MyPtr->MyGlobal1;
then MyPtr ends up being self-referenced (MyPtr->*) which is not what you want.
I'm not sure why this doesn't work -- let me forward this post to our Software Engineering manager.
However since most of the useful memory locations in Power PMAC have already been mapped, I'm not sure why you would need to reproduce the "Indirect Addressing" method from Turbo PMAC.
Keep in mind you could do this easily in a C program also, e.g. in a Background C Application:
double *MyPtr;
MyPtr=pshm->P[MyGlobal1]; // now MyPtr points to global variable "MyGlobal1" which you need to have previously defined somewhere in your project
*MyPtr=5.0; // sets MyGlobal1=5.0
MyPtr=pshm->P[MyGlobal2]; // now MyPtr points to global variable "MyGlobal2"
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
-
You have the ability right now to use your symbolic name for a variable in the ide terminal/watch windows and OTHER C applications with either method of variable declaration:
global a
or
#define a P1
You do not need to assign a pointer variable to do this.
I do if I want to be able to change it without recompiling...on the fly.
-
The only difference between the two methods of declaring variable names is who decides which underlying variable is assigned to your symbolic name -- you, or the project manager. In both cases, the matchup is stored in the symbol table inside Power PMAC and so is available to any task that can access the table -- typically through "gpascii -2" (The -2 gives it access to the table.)
I still haven't figured out what advantage you get from assigning a pointer variable to a global variable.
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.
-
I'm not sure I understand why you want to do what you are trying to do, but you can do it easily with the other supported method of variable declaration, i.e.:
#define a P1
#define b P2
ptr var->Sys.P[1]
The declarations like "global a" are for users who have no need to know which underlying variable is being used.
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?
-
The relevant paragraph in the HW Reference manual is:
If the output of the XOR gate on either the A or B channel of the encoder is false, the encoder is
considered “lost”. The status bit Gate3.Chan[j].LossStatus in the channel’s status register
Gate3.Chan[j].Status is set to 1. This is a “transparent” status bit that will return to 0 if the
signal is regained. The “latched” status bit Gate3.Chan[j].LossCapt in the same register is set
to 1 if a loss is detected, and held at 1 until specifically reset (writing a 0 to the bit will reset it).
I sit corrected. Thanks.
-
The "transparent" encoder loss bit Gate3.Chan[j].LossStatus is automatically cleared as soon as the encoder signal is restored. The "latched" encoder loss bit Gate3.Chan[j].LossCapt can be cleared by writing a 0 to the bit (as documented in the description of the bit in the Software Reference Manual chapter on status elements). Of course, if there is not a valid encoder signal, it will immediately be set to 1 again.
one might expect to find that information included (or referenced) in the ACC-24E3 HARDWARE REFERENCE manual where ENCLOSS is discussed.
-
what is the recommended way for clearing ENCLOSS on an Acc24e3 encoder channel?
-
I know about those calls but they appear to be rather "fatty" to me: shouldn't I be able to set the C.S. system ONCE and use some sort of more direct access (more like a Script PLC)?
-
what is the recommended method for accessing Coordinate Systems and the related Q-Variables from a CPLC program?
-
no...I want to know the INDEX to use for manipulating the 'pshm->UserAlgo.BgCplc[iNDEX]' variables, etc. and similar for the Script PLCs.
- Joe
The easiest way (as far as I know) is to just put a global flag inside your CPLC to go high when the CPLC is running.
I.e. you can define a global in your "global definitions.pmh" file as, for example:
global CPLC1_Running, CPLC2_Running;
and then in your CPLC you can just set
pshm->P[CPLC1_Running]=1;
when the CPLC starts, and set it to zero right before the CPLC ends, and so on.
-
are there variables available to tell me WHICH CPLC or Script PLC I am when I am executing? I see everyone just using constants but it would seem that the system KNOWS which CPLC or Script PLC is executing so can I just obtain that information (I have axis CPLCs coded in a subroutine and to check the 'bgcplc[n]' flags you need to have that information).
- Joe
-
yes, I know about Sys.WDTFault and it was a "soft" watchdog trip. What I wanted to know is if you generated any kind of log event that the user could check (such an event might contain the app name if outside of the PPMAC or the PLC if within the PPMAC).
-
yes, I know about Sys.WDTFault and it was a "soft" watchdog trip. What I wanted to know is if you generated any kind of log event that the user could check (such an event might contain the app name if outside of the PPMAC or the PLC if within the PPMAC).
-
is there any logged event/file that lists any information concerning the originator/reason for a watchdog trip?
-
We have a machine that is running software using a UMAC chassis with a MACRO CPU that is controlled by a Turbo PMAC Ultralite. We would like to experiment with transitioning the application to utilize the PPMAC but would like to maintain all of the UMAC wiring etc., so that the machine could be run as normal by switching control back to the MACRO CPU. Is it possible to alternately command the PPMAC or MACRO CPU to "dummy up" and not talk to the UMAC hardware so that we would not have to pull CPU cards to do that (while progressively developing the PPMAC application)?
how to connect to old "Serial Number - Part Number - Rev Info"
in Power PMAC
Posted