george.kontogiorgos

Hi all! I would like to ask why EQU toggle when ServoCapt cross zero. My suspect is that the compare registers are not dealing well with two's complement when the register becomes positive (example: 111111..... to 000000...) When I use CompA and CompB on positive or negative domain strictly, it works as expected. I put this question here because it seems to be related to Choi Woo Shik question. Firmware: 2.5.4.0 IDE version: 4.3.2.19 Thanks! George

Hi Eric! I solved the problem by spliting the large equations into sums. I think this is an intrinscic problem of the compiler, since I saw some reports of this problem on other C compilers (just speculating) George

IDE: 4.3.2.19 firmware: 2.5.4.0 I do not know how to see it, could you please show me? Maybe done by this: Sys.WpKey = $AAAAAAAA? I put this just on one pmh file... All files must contain it? Sure, there are two screenshots showing the problem, one of my plc with large lines (which causes segmentation fault even commented) and the other show the output of the error. The example line (there are many as you can see on screenshot): P76=7.9992320737209082e-10*P62/(sqrt(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) + 0.00050000000000000001*P62*(-5.3709337312250722e-13*P60 - 1.3430231271822752e-12*P61 + 3.7602330006095687e-8*P65)*(5.3194893290244149e-7*P60 + 1.5998464147441817e-6*P61 - 0.042635906952932505*P65)/(sqrt(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1)*pow(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1, 3.0/2.0)) + 0.00050000000000000001*P62*(-8.5103659313096439e-13*P60 - 2.5595085507698126e-12*P61 + 6.8210902878015602e-8*P65)*(5.3194893290244149e-7*P60 + 1.5998464147441817e-6*P61 - 0.042635906952932505*P65)/(pow(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1, 3.0/2.0)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) - 6.5106109364062736e-13*P64*(0.00049450793067729688*P63 - 172.09999999999999)/(sqrt(3.1561671506122976e-13*pow(P64, 2) + 1)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) - 5.6179775280898885e-7*P64*(0.00049450793067729688*P63 - 172.09999999999999)*(-5.3709337312250722e-13*P60 - 1.3430231271822752e-12*P61 + 3.7602330006095687e-8*P65)*(4.6345550827120609e-7*P60 + 1.1588887466803166e-6*P61 - 0.032446885099030487*P65)/(sqrt(3.1561671506122976e-13*pow(P64, 2) + 1)*pow(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1, 3.0/2.0)) + (629.10000000000002 - 7.3904712280461367e-5*P63)*(-5.3709337312250722e-13*P60 - 1.3430231271822752e-12*P61 + 3.7602330006095687e-8*P65)/(sqrt(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1)*pow(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1, 3.0/2.0)) + (629.10000000000002 - 7.3904712280461367e-5*P63)*(-8.5103659313096439e-13*P60 - 2.5595085507698126e-12*P61 + 6.8210902878015602e-8*P65)/(pow(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1, 3.0/2.0)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) + 1.5998464147441817e-6*(0.00049450793067729688*P63 - 172.09999999999999)/(sqrt(3.1561671506122976e-13*pow(P64, 2) + 1)*sqrt(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) + (0.00049450793067729688*P63 - 172.09999999999999)*(-5.3709337312250722e-13*P60 - 1.3430231271822752e-12*P61 + 3.7602330006095687e-8*P65)*(5.3194893290244149e-7*P60 + 1.5998464147441817e-6*P61 - 0.042635906952932505*P65)/(sqrt(3.1561671506122976e-13*pow(P64, 2) + 1)*sqrt(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1)*pow(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1, 3.0/2.0)) + (0.00049450793067729688*P63 - 172.09999999999999)*(-8.5103659313096439e-13*P60 - 2.5595085507698126e-12*P61 + 6.8210902878015602e-8*P65)*(5.3194893290244149e-7*P60 + 1.5998464147441817e-6*P61 - 0.042635906952932505*P65)/(sqrt(3.1561671506122976e-13*pow(P64, 2) + 1)*pow(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1, 3.0/2.0)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) + 590.10000000000002*(-5.3709337312250722e-13*P60 - 1.3430231271822752e-12*P61 + 3.7602330006095687e-8*P65)/(sqrt(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1)*pow(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1, 3.0/2.0)) + 590.10000000000002*(-8.5103659313096439e-13*P60 - 2.5595085507698126e-12*P61 + 6.8210902878015602e-8*P65)/(pow(0.0018178205616991184*pow(1.2476547842401508e-5*P60 + 3.7523452157598445e-5*P61 - P65, 2) + 1, 3.0/2.0)*sqrt(0.0010528003526296867*pow(1.4283513097072426e-5*P60 + 3.5716486902927524e-5*P61 - P65, 2) + 1)) I am using P-variables in order to implement the newton method to solve a non trivial inverse kinematics. These P-variables goes to native matrix operators. This line is one of the elements of jacobian matrix, which is used to implement newton method. It is very large due to the complexity of system kinematics

Hi all! I observed the same problem (segmentation fault) and I am suspecting that my large lines on one of my PLCs are causing the problem. Even if I comment them, the segmentation fault occurs, and, if I remove them, the segmetation fault disappear. Any suggestions about what could I do to solve the problem? I would like to know if compilation does not support large lines of code and if there is a way to download the programs without breaking the calculation in other small pieces. Thanks!

AAnikstein, I sent the e-mail as you requested. Also the answer for "cpu" command is:

Hi AAnikstein! Maybe the problem is a bug on firmware. My coworker found it on this thread http://forums.deltatau.com/showthread.php?tid=2903&highlight=Limit I am using firmware 2.5.0.4

Thanks for replying! The controller is reading limit switches correctly. I validated the connections and the switches, pressing manually the positive and negative limit switches cause MinusLimit and Plus limit flag rise up on motor status wiondow . My Motor[4].pLimits=PowerBrick[0].Chan[3].Status.a and Motor[4].LimitBits=9 are correctly set.

Hi! I was doing some tests with out command: to move my stepper motor in open-loop. Software manual (page 434) says: But when my stage reach the limit switch, it does not stop. I tried setting Motor[x].FaultMode to 0 or 2 and both of them does not stop in closed loop or kill respectively. Am I forgetting something? There is some other configuration that I should do to operate this motor in open-loop on a safe manner? Thanks!

Hi, Eric! Thank you for replying! I thought right and wrote it wrong. But the result values are correct, I just forget the 24 bit shift on equation. Software manual says that index 3 and 4 acts on ECT type 8 and 9 as the same way on ECT type 1, and they are not related to other register sources. I saw about garbage data on manual, but what does it really mean? Garbage is some stuff pre-allocated on registers during start up or the status bits of the encoder? I decided to use PrevEnc based on PowerPMAC User's Manual (page 165 for example). It is working fine for me! So I used type 2. It solved my problem! I thought that PrevEnc was the actual values of EncTables (all EncTables run their calculations in parallel or they do it in sequence?) because software manual (page 840) says: I think this test is no longer needed: Now Motor[7].AbsPosSF is working. The final solution: Encoder file Motor file snippet of poweron settings: Thank you!

Hi all! I am working on a project that should take the mean value of two 26 bits absolute renishaw encoders. I get some power-on postion problems with this mean operation, scale factors and etc. I will separate it into topics: 1. Incorrect sum when try to get the raw serial registers into EncTable I had an incorrect value of the sum when I point to serial encoder raw register. The register values are: Acc84B[0].Chan[3].SerialEncDataA=3510848 Acc84B[0].Chan[3].SerialEncDataB=196609 Acc84B[1].Chan[0].SerialEncDataA=10368788 Acc84B[1].Chan[0].SerialEncDataB=196608 Doing the correct calculations, we have to do SerialEncDataA+(SerialEncDataB & 3)(remember that it is a 26 bit encoder) and I shoud get 20288064 on Acc84B[0].Chan[3] and 10368788 on Acc84B[1].Chan[0]. My EncTable: //**************************************************************************************** // Serial encoder settings Acc84B[0].Chan[3].SerialEncCmd = $21149A Acc84B[1].Chan[0].SerialEncCmd = $21149A //Average EncTable[17].type = 8 EncTable[17].pEnc = Acc84B[0].Chan[3].SerialEncDataA.a EncTable[17].pEnc1 = Acc84B[1].Chan[0].SerialEncDataA.a EncTable[17].index1 = 0 EncTable[17].index2 = 8 EncTable[17].index3 = 0 EncTable[17].index4 = 0 EncTable[17].MaxDelta = 0 EncTable[17].ScaleFactor = 1 Should give me the sum 30656852. First strange thing is that my EncTable[17].PrevEnc return me -2897581 on watch window (Disconsider eventually LSB variations, my encoder has 1 nm resolution and it is very sensible). This value is negative, which makes me think that ther is an representation issue. The power-on position has problems to, here is the code snippet fo power-on: //**************************************************************************************** // PowerOn Position Motor[7].PowerOnMode = 6 Motor[7].pAbsPos = EncTable[17].PrevEnc.a Motor[7].pAbsPos2 = Sys.Pushm Motor[7].AbsPosFormat = $00001A00 Motor[7].AbsPosSF = 1 And the position on position window is 64211285 (Disconsider eventually LSB variations, my encoder has 1 nm resolution and it is very sensible). I did save and $$$ to get the power-on position. 2. Most significant register does not read by EncTable I tryed change the bits operation, set index2 as 0 and put the bit displacement on scale factor as 1/256, as follows: //**************************************************************************************** // Serial encoder settings Acc84B[0].Chan[3].SerialEncCmd = $21149A Acc84B[1].Chan[0].SerialEncCmd = $21149A //Average EncTable[17].type = 8 EncTable[17].pEnc = Acc84B[0].Chan[3].SerialEncDataA.a EncTable[17].pEnc1 = Acc84B[1].Chan[0].SerialEncDataA.a EncTable[17].index1 = 0 EncTable[17].index2 = 0 EncTable[17].index3 = 0 EncTable[17].index4 = 0 EncTable[17].MaxDelta = 0 EncTable[17].ScaleFactor = 1/256 The power-on position settings should now point to start bit 8, as follows: //**************************************************************************************** // PowerOn Position Motor[7].PowerOnMode = 6 Motor[7].pAbsPos = EncTable[17].PrevEnc.a Motor[7].pAbsPos2 = Sys.Pushm Motor[7].AbsPosFormat = $00001A08 Motor[7].AbsPosSF = 1 Doing save and $$$ with those settings I get 13879645 (Disconsider eventually LSB variations, my encoder has 1 nm resolution and it is very sensible), which is the sum of Acc84B[0].Chan[3].SerialEncDataA with Acc84B[1].Chan[0].SerialEncDataA (the less significant ones). This makes me think that this summation is ignoring the most significant registers SerialEncDataB. 3. Type 2 EncTables and scale factor problem Due to those problems I tried to use type 2 EncTable to automatic concatenate the both SerialEncData registers into a 32 bit register. So, my EncTable now looks like that: //**************************************************************************************** // Serial encoder settings Acc84B[0].Chan[3].SerialEncCmd = $21149A Acc84B[1].Chan[0].SerialEncCmd = $21149A EncTable[27].type = 2 EncTable[27].pEnc = Acc84B[0].Chan[3].SerialEncDataA.a EncTable[27].pEnc1 = Acc84B[0].Chan[3].SerialEncDataB.a EncTable[27].index1 = 0 EncTable[27].index2 = 0 EncTable[27].index3 = 0 EncTable[27].index4 = 0 EncTable[27].MaxDelta = 0 EncTable[27].ScaleFactor = 1 EncTable[37].type = 2 EncTable[37].pEnc = Acc84B[1].Chan[0].SerialEncDataA.a EncTable[37].pEnc1 = Acc84B[1].Chan[0].SerialEncDataB.a EncTable[37].index1 = 0 EncTable[37].index2 = 0 EncTable[37].index3 = 0 EncTable[37].index4 = 0 EncTable[37].MaxDelta = 0 EncTable[37].ScaleFactor = 1 //Average EncTable[17].type = 8 EncTable[17].pEnc = EncTable[27].PrevEnc.a EncTable[17].pEnc1 = EncTable[37].PrevEnc.a EncTable[17].index1 = 0 EncTable[17].index2 = 0 EncTable[17].index3 = 0 EncTable[17].index4 = 0 EncTable[17].MaxDelta = 0 EncTable[17].ScaleFactor = 1 and my power-on position settings are: //**************************************************************************************** // PowerOn Position Motor[PIEZO_MOTOR].PowerOnMode = 6 Motor[PIEZO_MOTOR].pAbsPos = EncTable[17].PrevEnc.a Motor[PIEZO_MOTOR].pAbsPos2 = Sys.Pushm Motor[PIEZO_MOTOR].AbsPosFormat = $00002000 Motor[PIEZO_MOTOR].AbsPosSF = 1 Now I get the correct answer for summation. Since I have to take the average between those two encoders, I did, on EncTable settings: EncTable[17].ScaleFactor = 1/2 and on Power-on settings: Motor[7].AbsPosSF = 1/2 Indeed, I get 15328431.5. But things get weired when I try to manipulate scale factors. If I set EncTable scale factor as EncTable[17].ScaleFactor = 1 The result return to 30656852 as power-on position. The software manual says: "It is a 32-bit integer value that has not been multiplied by the saved setup element EncTable[n].ScaleFactor." About EncTable[n].PrevEnc. So modifying EncTable scale factor should not affect power-on position, in theory. But it is changing. Other problem is that the AbsPosSf does not affect the power-on position, only EncTable scale factor. If I set EncTable[17].ScaleFactor = 1/2 and Motor[7].AbsPosSF = 2 or 3 or 100 The result after save and $$$ is always the same: 15328431.5. I am using firmware 2.5.0.4, but this happens to 2.4.0.180 too. I did the same tests downgrading the firmware and the results were always the same. Thank you George

Hi Eric! Thank you, it worked like a charm.

Hello! I am trying to copy gather files from PowerPMAC to my host computer with a python script in order to automate the procedures and improve speed. Python make a system call by SCP, a program that copy files using ssh session. To avoid passing passwords in a insecure way (and for automation reasons), like sshpass, I generated a ssh key (ssh-keygen and ssh-copy-id) and a new user (non root) for PowerPMAC. My problem is when I reboot my PowerPMAC: I lost my new user and just root stay alive. Is there a way to keep new user after rebooting the system? Am I copying files on the right way or there is another possible? Thanks George