daves

If it is any help I have just seen it work on 1.6.0.0

I cannot set UserAlgo.CFunc to 1 on my card. On a 1.5.8.0 card this is no problem. It means my CFromScript code will not run from a background PLC. What does CFuncStatus mean. It is not in the SRM, UG, or Help? $$$*** Resetting PowerPMAC PowerPmac Reset complete Please wait!!! database Sync in progress Database sync complete useralgo.CFuncStatus UserAlgo.CFuncStatus=0 useralgo.CFunc=1 useralgo.CFunc UserAlgo.CFunc=0 useralgo.CFuncStatus UserAlgo.CFuncStatus=-1 vers 1.6.0.30

Thanks shansen this built and downloaded. It is a shame the end user needs to have to know about kernel mode limitations (I am currently trying to educate myself in this area!). Maybe this should be implicit from knowledge of the system architecture but some hints in the User Guide would be useful.

I am probably missing something simple here but I am struggling to get the simplest c-code built in to the CFromScript architecture... I can offer a simple example: Create a new project. Add the following to usercode.c //#include "../Include/test.h" double CfromScript(double arg1, double arg2, double arg3, double arg4, double arg5,double arg6, double arg7, LocalData *Ldata) { return fabs(arg1); //return DoTest(arg1); } This works fine. If I want some shared code by uncommenting the include and return from a function: #include "../Include/test.h" double CfromScript(double arg1, double arg2, double arg3, double arg4, double arg5,double arg6, double arg7, LocalData *Ldata) { //return fabs(arg1); return DoTest(arg1); } and test.h contains: double DoTest(double arg1) { return fabs(arg1); } I get build errors containing: C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac5\PowerPmac5\C Language\Realtime Routines\usrcode.c(23,0): Warning : in file included from /cygdrive/c/Users/daves.ABD/DOCUME~1/POWERP~1/PO3361~1/POWERP~1/CLANGU~1/REALTI~1/usrcode.c C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac5\PowerPmac5\C Language\Realtime Routines\test.h(3,0): Error : implicit declaration of function 'fabs' C:\Users\daves.ABD\Documents\PowerPmacSuite\PowerPmac5\PowerPmac5\C Language\Realtime Routines\test.h(3,0): Warning : incompatible implicit declaration of built-in function 'fabs' I had a go at fixing this with standard includes but it got even more complainy. The code I actually want to share in CFromScript used more standard routines than this and actually slowed the build to a painful halt and had to be killed. What am I not getting here? I assume it is to do with the kernel double-build thing somehow as only the ko complains

I do the following in script: cmd "R1AmpFault->u.io:$618020.23.1"; // Gate1[16].Chan[0] I assume you could do it with Command("") in c-code but I never have. Also to use your L0 I guess you would have to format the string first. I would also combine this with sendallcmds and Ldata.CmdStatus as shown in some examples. And beware there is some delay between sending a command to the ascii processor and it being reacted to (i.e. reassign pointers and then have a delay as necessary) This may not be the best way to do it but it is the way I have plumped for.

Perfect. Thank you. Sorry I didn't explicitly say I was talking about PowerPMAC originally... Please put the Desired structure in the IDE Help file, and the Software Reference Manual.

This is good news. I don't see it in: Motor[x].Status[0] is the first 32-bit status word for the motor 31 TriggerMove 30 HomeInProgress 29 MinusLimit 28 PlusLimit 27 FeWarn 26 FeFatal 25 LimitStop 24 AmpFault 23 SoftMinusLimit 22 SoftPlusLimit 21 I2tFault 20 TriggerNotFound 19 AmpWarn 18 EncLoss 16 – 17 (Reserved for future use) 15 HomeComplete 14 DesVelZero 13 ClosedLoop 12 AmpEna 11 InPos 10 (Reserved for future use) 9 BlockRequest 8 PhaseFound 7 TriggerSpeedSel 6 GantryHomed 5 SpindleMotor(bit 1) 4 SpindleMotor(bit 0) 0 – 3 (Reserved for future use) Motor[x].Status[1] is the second 32-bit status word for the motor 31 Csolve 30 SoftLimit 29 DacLimit 28 BlDir 0 – 27 (Reserved) Where do you see it?

Am I right in concluding the UMAC flag: Bit 17 Move Timer Active has been removed from the motor status x-word? Our Windows software used to show a nice graphical LED for each motor when active. It seems to just be for a coordinate system now. Any chance of using a spare bit and putting this back? I feel like I have asked this before so apologies if this is a repeat question...

This worried me so I investigated. I only looked at the first case. There are a couple of issues with the logic you have used: Firstly this cannot be all the code as you don't show that you start the home or how you initialise Timer1. I will assume you start the home, set Timer1=Sys.Time+3, start the PLC. //Wait until time out or home in progress = 0 while ((Sys.Time > Timer1) && (Motor[1].HomeInProgress==0)) {} should be //Wait until time out or home in progress = 0 while ((Sys.Time < Timer1) && (Motor[1].HomeInProgress==1)) {} you want to wait WHILE the timeout has not been reached and WHILE the home is still in progress. In your code, during the home, your while will just drop through. The 7th send send 2,"Sys.time=%d\n",L1 should be send 2,"Sys.time=%d\n",Sys.Time You say you get the first four sent messages (or what you call 'hooks') repeatedly but I found the first eight sends repeated with the bad logic. This is because during the home and timeout period your 'while' drops through and neither of the following 'if' conditions are met so the PLC executes again repeating the eight messages. PLCs are effectively loops. A quick experiment shows mine running at 1000Hz. So your example was buffering out 8000 message lines a second. This looks slow in the Unsolicited window as it is catching up with these buffered messages, and appears unchanging as there are 8000 messages before Sys.Time will have a new value.

As an answer for myself I found a reference to the control word over MACRO in the Acc14E manual, so I'm going to use that: cmd "MacroSlave0, I198 = $408807"; cmd "MacroSlave0, I199 = $7"; I hope it is right

I spoke too soon on that last post. There was a 'd' error on the ring. After clearing and trying again it worked. Thank you so much for your help, being able to come from a working configuration was the key to spotting what I must have been doing wrong originally. I think my main problems were coming from misunderstanding the bytes in the registers. For the record (possibly useful to someone else) I now have for my Acc14E at $9800 over a MACRO16 to an Acc5E3 in a PPMAC rack, transferring to the 16-bit node registers in Node B11: // Set up the Acc5E3 Sys.WpKey = $AAAAAAAA; Gate3[0].MacroEnableA = $0FFFFF00; Gate3[0].MacroModeA = $00403000; Gate3[0].MacroEnableB = $1FBFFF00; Gate3[0].MacroModeB = $00001000; Sys.WpKey = 0; // Set up the nodes macroslave0,i19=4 macroslave0,i996=$0FFFFF macroslave0,i975=$CCC macroslave0,i1996=$1FBFFF // Set 25-48 as outputs on the Acc14E macroslave0,i198=$409807 macroslave0,i199=7 // Set 3x16-bit transfer on B11 from $9800 macroslave0,i69=$10C0F5319800 The outputs are at: Acc5E3[0].Macrooutb[11][3]=$F0000000 // 48-45 Acc5E3[0].Macrooutb[11][3]=$0F000000 // 44-41 Acc5E3[0].Macrooutb[11][3]=$00F00000 // 40-37 Acc5E3[0].Macrooutb[11][3]=$000F0000 // 36-33 Acc5E3[0].Macrooutb[11][2]=$F0000000 // 32-29 Acc5E3[0].Macrooutb[11][2]=$0F000000 // 28-25 So I use addressing to access the bits e.g: m25->i.io:$9007B8.24.1 ... m32->i.io:$9007B8.31.1 m33->i.io:$9007BC.16.1 ... m48->i.io:$9007BC.31.1

I just plugged in an Acc5E to try using gate2 and followed your instructions (the station is a MACRO16CPU btw): Acc5E[0].MacroEnable=$ff3ff Acc5E[0].MacroMode=$30 macroslave0,i19=4 macroslave0,i975=$cc macroslave0,i996=$ffcff macroslave0,i71=$10C0A8219800 Acc5E[0].Macro[7][0]=$ffffff This didn't work but after setting the control word: macroslave0,i198=$409807 macroslave0,i199 $00000000003f macroslave0,i199=7 Acc5E[0].Macro[7][0]=$ffffff It worked! Repeating for Acc5E3 I cannot get to work: sys.WpKey=$aaaaaaaa Acc5E3[0].MacroEnableA=$ff3ff00 Acc5E3[0].Macromodea=$3000 sys.WpKey=0 macroslave0,i19=4 macroslave0,i975=$cc macroslave0,i996=$ffcff macroslave0,i71=$10C0A8219800 macroslave0,i198=$409807 macroslave0,i199=7 Acc5E3[0].Macroouta[7][0]=$ffffff I must be missing something simple... Dave

Thanks for the reply I am still struggling. I have similar settings, it is gate3, I am already successfully transferring lots of data from Acc36E, Acc24E2S, Acc65E and motors on Acc24E2As so I feel like the MACRO is set up OK: Sys.WpKey = $AAAAAAAA; Gate3[0].MacroEnableA = $0FFFFF00; Gate3[0].MacroModeA = $00403000; Gate3[0].MacroEnableB = $1FBFFF00; Gate3[0].MacroModeB = $00001000; Gate3[1].MacroEnableA = $2FBFFF00; Gate3[1].MacroModeA = $00001000; Gate3[1].MacroEnableB = $3FBFFF00; Gate3[1].MacroModeB = $00001000; Sys.WpKey = 0; macroslave0,i19 $000000000004 macroslave0,i975 $000000000ccc macroslave0,i996 $0000000fbfff I tried using node 6/7 24-bit registers similar to your suggestion: macroslave0,i71=$10C0A8219800 Gate3[0].MacroOutA[7][0]=$ffffff This did not work. I tried saving, resetting, etc.

I am struggling to use an Acc14E over MACRO. The card is at $79C00 = $A0800C = $9800. I can put the card in the main PPMAC rack and do the following, and lights 25-32 come on as expected: m9->i.io:$A0801C.8.8 m9 M9=63 m9=7 m9->i.io:$A0800C.8.8 m9 M9=0 m9=$ff Trying to set the card for output on some or all lines does not work. Setting up node transfers does not work. Trying the direct read methods can change the control word but not the data: macroslave0,i198=$409807 macroslave0,i199 $00000000003f macroslave0,i199=7 macroslave0,i199 $000000000007 macroslave0,i198=$409803 macroslave0,i199 $000000000000 macroslave0,i199=$ff macroslave0,i199 $000000000000 I guess I am missing something but cannot figure out what...

Thanks for the replies. I guess the bit in the macro output doesn't get reset because it is just that, an output. I just need to know to reset it myself. To look at the local ECT output should I look at EncTable[n].PrevEnc multiplied by EncTable[n].ScaleFactor? What is the equivalent? The idea of using a Motor is what I was thinking. We do this for some encoders. We do not do it for all encoders as one of our Turbo developers says the active motors add an overhead. This throws up a lot of questions concerning timing and the schedule of direct reads, processing ECT, processing motors, and RTI wich may be described somewhere and we will have to look at later (a servo-cycle delay between reference and measurement encoders can make our machine appear out of spec). For now can you tell me the impact of the increased overhead of using motors? We would have 49 encoders to read in addition to 19 real motors.

Does/should the macro encoder zeroing work the same as zeroing an encoder in the main rack? I have ZeroFLHWPMSEnc1->u.io:$600034.18.1; // Gate1[4].Chan[0] ZeroSpareEnc02->u.io:$90074c.20.1; // Gate3[0].MacroOutB[0][3] Setting the first one to 1 zeroes the encoder and sets itself back to 0 as expected. Setting the second one to 1 zeroes the encoder sometimes but usually goes to 16/31 counts and DOESN'T set itself back to 0 so the encoder keeps attempting the zero. The first one is a Acc24E2S the second one happens to be a Acc24E2S at $9000. Is this normal for MACRO? How can I properly zero the encoder?

Please update the software reference manual, the acc36e manual (and any other affected accessories), and the IDE help file with respect to the format of ConvertCode. All these say it takes value $n00. All the examples show this. I spent a lot of time investigating why my ResultHigh values were always unsigned before I looked for this post. I assume this is the correct way and will not change in a firmware update?

Kaspersky did the same to us (for other IDEs as well). Developers were first allowed to exclude their source folders, then disable on-access file scans, then finally remove the AV software altogether!! I wonder if the PPMAC IDE may suffer from having 21,937 c-files and 21,220 h-files under the Program Files which may not be excludable under certain enterprise rules and possibly get accessed during the build... I would experiment excluding that if I had any AV software running!

I am using the recommended approach: Ldata.CmdStatus = 1; cmd "whatever" sendallcmds; while (Ldata.CmdStatus > 0) {} if (Ldata.CmdStatus < 0) { send 1 "1: error %d", Ldata.CmdStatus; } I have a PLC which is like: call SetupMACRO(); call DefineStuff1(); call DefineStuff2(); call DefineStuff3(); The first sub program sets up the macro. The others do some ptr assignment all using cmd as outlined above. I was getting an error -50 (which I found was MACRO COM TIMEOUT from another post here) in DefineStuff2. If I commented out DefineStuff2 it would appear in DefineStuff3. Neither of these talked to MACRO. It was more confusing in my real code but I managed to track it down to a bit in SetupMACRO where I had: ... cmd "MacroSlaveSAVE32"; sendallcmds; // Start plccs cmd "MacroSlave32, I15=1"; ... It appears the call to MacroSlave32 is being attempted too soon after the save (does this sound correct?). Is it possible to know when the save has finished or do I have to pause 1s? Why does the error return at a later time than the recommended code to trap errors? If this is the nature of the ASCII buffers it makes it rather unusable. Can it be fixed? Can cmd not return until a response is received (success or error)?

In the following case 16 is OK, case 17 throws an error and has to be written as in case 18. Why? Is it going to work? case 16: ZeroSpareEnc17 = 1; break; case 17: cmd "#22hmz"; break; case 18: cmd "#23hmz"; break;

You're right, my search in the PDFs for "index" quickly lost my attention! Although it does explicitly say the index to the 'Motor' (I also now see it mentioned in comptable[m].data for i, coord[x], sys.cdata etc). No mention in EncTable[n]. Can I assume this is the case for all [] access in script code? Perhaps it should be explained in POWER PMAC COMPUTATIONAL FEATURES - Pre-Defined Data Structures where indexing is described, and in the same area as the other quirks of the script language. Ultimately I think it would be nice to allow P-variable indexing. It seems natural to want to define a machine configuration (e.g. FrontMotor=1) in a global variable then refer to this throughout the code without worrying about its type.

I have the following in my standard PPMAC code (which originally came from Turbo code): // Bits 0-23 are inputs, bits 24-47 are outputs // Set up Acc65E card GateIo[0].CtrlReg = $07; Phase II of my code has the acc65e being transferred over MACRO. Do I need to set this for my card and if so how do I do it through the MACRO CPU? It appears to be working without setting this but the help says "This setting is strongly recommended"

Thanks for the info, I altered my design to use parameters in a callsub (so effectively local in the sub) and I am happy.

Is it the intention that I cannot index structure elements by Global (P) variable in a pmc file? e.g. global MyEnc; Motor[14].pEnc = EncTable[MyEnc].a; It seems to allow global MyEnc; local enc = MyEnc; Motor[14].pEnc = EncTable[enc].a; I need this for flexible code for different machine configurations and using the local variable feels like a waste. I cannot find this mentioned in the user guide in the computational features area discussing element indexing.

Hmmm... Thanks for the reply, I hope this isn't the case. We cannot practicably hold/build all the configurations of racks our customers have when we release a new version of code (time, hardware, scope for error). If an upgrade has to be done through the IDE, and we therefore have to supply the source to the customer, doesn't this make the encryption options worthless for upgrades? Not to mention training or instructing customers to use the IDE correctly... Perhaps a standalone tool (automatically running on the PPMAC or from the stick) is needed which can perform the download from the gpg encrypted files on the stick (also reproducing the hardware configuring actions done by the IDE). Is this actually just projpp or tools already there? Thanks, Dave