Jump to content
OMRON Forums

george.kontogiorgos

Members
 View Profile  See their activity

  • Posts

    37

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Posts posted by george.kontogiorgos

    Inquiries about PowerPMAC EQU signal.

    in Power PMAC

    Posted

    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

    Segmentation fault on code download

    in Power PMAC

    Posted

    What IDE and firmware version are you using?

     

    IDE: 4.3.2.19

    firmware: 2.5.4.0

     

    Are you encrypting your project?

     

    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?

     

    Can you paste in an example line that causes a segmentation fault even when commented?

     

    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

    seg_fault_message.thumb.PNG.cdb484a3c3372619254c50b0e84ff4ab.PNG

    large_plc_lines.thumb.PNG.9a9b08d763d9635e3153c2e3981dd56c.PNG

    Segmentation fault on code download

    in Power PMAC

    Posted

    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!

    Open loop does not respect physical limit switches

    in Power PMAC

    Posted

    Thanks for replying!

     

    Can you confirm whether or not PMAC is reading it as a limit switch, or reading it as the correct limit switch?

     

    The controller is reading limit switches correctly.

     

    In the "Motor Status" tab of a "Status" window, select the correct motor number and manually toggle the limit switches--you should see bits "PlusLimit" and "MinusLimit" go true and false.

     

    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 .

     

    If you do not, then verify Motor[x].pLimits and Motor[x].LimitBits, along with verifying that your switches are wired into the correct inputs.

     

    My Motor[4].pLimits=PowerBrick[0].Chan[3].Status.a and Motor[4].LimitBits=9 are correctly set.

    Open loop does not respect physical limit switches

    in Power PMAC

    Posted

    Hi!

     

    I was doing some tests with out command:

     

    #1out0.1

    #1out-0.1

     

    to move my stepper motor in open-loop. Software manual (page 434) says:

     

    Bit 1 (value 2) controls the action when this motor is in open-loop enabled mode (as from an online outn or buffered coutn command) and the motor hits an overtravel limit (hardware or

    software), or the coordinate system operation is aborted (abort or adisable command,

    aborting error or run-time error in the coordinate system). [..]

     

    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!

    AbsPosSf power on problems

    in Power PMAC

    Posted

    Hi, Eric!

     

    Thank you for replying!

     

    I am a bit confused here. The first 24 bits of your position are in SerialEncDataA with the remaining 2 bits in SerialEncDataB. This means calculating your total position would be require left shifting SerialEncDataB like:

    SerialEncDataA+(SerialEncDataB & $3) << 24

     

    I thought right and wrote it wrong. But the result values are correct, I just forget the 24 bit shift on equation.

     

    Symmetry: The way index 1 and 2 work for the first source is how index 3 and 4 work for the second source. So you will need to shift both numbers the same amount.

     

    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.

     

    SerialEncDataA has values in the high 24 bits of a 32 bit register when viewed by the firmware or in C (the low 24 bits when viewed in script). This means if we right shift 8 bits to clear any garbage data, we will want to left shift afterwards.

     

    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'm not sure going through the encoder conversion table and using power on mode is a good idea to read initial position, but nothing is going wrong with using the method for me.

     

    I decided to use PrevEnc based on PowerPMAC User's Manual (page 165 for example). It is working fine for me!

     

    Yes, 100%. The encoder table is only reading SerialEncDataA

     

    So I used type 2.

     

    Not a big deal, but I believe the ECT entry that is type 8 should be the highest index. When enctable 17 runs, 27 and 37 have not yet run that cycle and must use positions from last servo period.

     

    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:

     

    EncTable[n].PrevEnc is the processed source position for the most recent servo cycle, stored by Power PMAC for use in the next servo cycle.

     

    I think this test is no longer needed:

     

    I can't replicate this result. Can you check the value of Motor[7].AbsPosSF in the terminal after save and $$$? It may be reverting back to the value in global includes files that run at boot.

     

    Now Motor[7].AbsPosSF is working.

     

    The final solution:

     

    Encoder file

     

    //****************************************************************************************

    // Serial encoder settings

    Acc84B[0].Chan[3].SerialEncCmd = $21149A

    Acc84B[1].Chan[0].SerialEncCmd = $21149A

     

    //****************************************************************************************

    // First term of average enctable 17

    EncTable[17].type = 2

    EncTable[17].pEnc = Acc84B[0].Chan[3].SerialEncDataA.a

    EncTable[17].pEnc1 = Acc84B[0].Chan[3].SerialEncDataB.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

     

    //****************************************************************************************

    // First term of average enctable 17

    EncTable[27].type = 2

    EncTable[27].pEnc = Acc84B[1].Chan[0].SerialEncDataA.a

    EncTable[27].pEnc1 = Acc84B[1].Chan[0].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

     

    //****************************************************************************************

    // Closed loop encoder settings

    EncTable[37].type = 8

    EncTable[37].pEnc = EncTable[17].PrevEnc.a

    EncTable[37].pEnc1 = EncTable[27].PrevEnc.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/2

     

    Motor file snippet of poweron settings:

     

    //****************************************************************************************

    // PowerOn Position

    Motor[7].PowerOnMode = 6

    Motor[7].pAbsPos = EncTable[37].PrevEnc.a

    Motor[7].pAbsPos2 = Sys.Pushm

    Motor[7].AbsPosFormat = $00002000

    Motor[7].AbsPosSf = 1/2

     

    Thank you!

    AbsPosSf power on problems

    in Power PMAC

    Posted

    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

    Copy gather files via SCP and new user on PowerPMAC

    in Power PMAC

    Posted

    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

×
×
  • Create New...