Jump to content
OMRON Forums

runaway motor


JohnR

Recommended Posts

While testing some code in the IDE I was able to get a sevoed motor( #2 ) to runaway and get a fatal following error. This occured when I had plc 1 ruinning a simple task of coying a value from global memory into a global variable. myvar_1=Sys.Udata[0]; this worked fine when from the teminal window I typed Sys.idata[0] = 1234 and the value of myvar_1 shown in the watch window is 1234 BUT when I typed sys.fdata=123.5667 all hell broke loose and the motor took off the value showing in the global var is myvar_1 P8192=1123492391 Why would a type mismatch cause the motor to falut out ? Also I can not close the loop on the motor until I assign an idata value and remove the float. John
Link to comment
Share on other sites

  • Replies 8
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

John, Here is what I think is the cause of the runaway. You are writing to Sys.Udata[0] and writing a floating point to the same register, causes a different value if looked at as a unsigned value (in your case 123.5667 shows up as 1123402391). Up to this point there is nothing strange. but why this can cause a runaway? You're writing to Sys.Udata[0] which is also noted as Sys.pushm (Pmac User Shared Memory). EncTable[0] is always active although it is not being used for any motor by default and it is looking at Sys.pushm as a 32-bit integer number. So any change in Sys.Udata[0] or Sys.Fdata[0] will be affecting the result of EncTable[0]. You can double check this by adding EncTable[0].PrevEnc to watch window and change the Sys.Udata[0]. Also by default all Motor[x].pMasterEnc is pointing to EncTable[0].a which means this would be the master position for the motor. However, nothing should go wrong unless you have enabled the master following, which I believe that's the cause of your runaway. Writing a floating point to the register and reading it as an integer value results in a huge value and if your Motor[x].MasterCtrl is non-zero it will cause a big jump in master position and a closed loop motor tries to move to the commanded position from master encoder. I hope this explains the problem. Regards,
Link to comment
Share on other sites

[quote='Sina' pid='999' dateline='1294332902'] John, Here is what I think is the cause of the runaway. You are writing to Sys.Udata[0] and writing a floating point to the same register, causes a different value if looked at as a unsigned value (in your case 123.5667 shows up as 1123402391). Up to this point there is nothing strange. but why this can cause a runaway? You're writing to Sys.Udata[0] which is also noted as Sys.pushm (Pmac User Shared Memory). EncTable[0] is always active although it is not being used for any motor by default and it is looking at Sys.pushm as a 32-bit integer number. So any change in Sys.Udata[0] or Sys.Fdata[0] will be affecting the result of EncTable[0]. You can double check this by adding EncTable[0].PrevEnc to watch window and change the Sys.Udata[0]. Also by default all Motor[x].pMasterEnc is pointing to EncTable[0].a which means this would be the master position for the motor. However, nothing should go wrong unless you have enabled the master following, which I believe that's the cause of your runaway. Writing a floating point to the register and reading it as an integer value results in a huge value and if your Motor[x].MasterCtrl is non-zero it will cause a big jump in master position and a closed loop motor tries to move to the commanded position from master encoder. I hope this explains the problem. Regards, [/quote] Thanks for explination about the to address being the same as EncTable[0]. My motor setup Motor[2].MasterCtr=0 So I would expect the master following to be off, is that not correct ? Thanks John
Link to comment
Share on other sites

[quote='JohnR' pid='1000' dateline='1294333576'] [quote='Sina' pid='999' dateline='1294332902'] John, Here is what I think is the cause of the runaway. You are writing to Sys.Udata[0] and writing a floating point to the same register, causes a different value if looked at as a unsigned value (in your case 123.5667 shows up as 1123402391). Up to this point there is nothing strange. but why this can cause a runaway? You're writing to Sys.Udata[0] which is also noted as Sys.pushm (Pmac User Shared Memory). EncTable[0] is always active although it is not being used for any motor by default and it is looking at Sys.pushm as a 32-bit integer number. So any change in Sys.Udata[0] or Sys.Fdata[0] will be affecting the result of EncTable[0]. You can double check this by adding EncTable[0].PrevEnc to watch window and change the Sys.Udata[0]. Also by default all Motor[x].pMasterEnc is pointing to EncTable[0].a which means this would be the master position for the motor. However, nothing should go wrong unless you have enabled the master following, which I believe that's the cause of your runaway. Writing a floating point to the register and reading it as an integer value results in a huge value and if your Motor[x].MasterCtrl is non-zero it will cause a big jump in master position and a closed loop motor tries to move to the commanded position from master encoder. I hope this explains the problem. Regards, [/quote] Thanks for explination about the to address being the same as EncTable[0]. My motor setup Motor[2].MasterCtr=0 So I would expect the master following to be off, is that not correct ? Thanks John [/quote] Welcome to PowerPMAC terminal Select device to start communication Telnet communication to PowerPMAC successful Please wait!!! database Sync in progress Database sync complete Sys.Udata[0]=123 Sys.fdata[0]=123.5667 EncTable[0].a EncTable[0].a=$ba38e000 Sys.Udata[0].a Sys.Udata[0].a=$bd10e000 Sys.fdata[0].a Sys.Fdata[0].a=$bd10e000 EncTable[1].a EncTable[1].a=$ba38e038 EncTable[0].a EncTable[0].a=$ba38e000 EncTable[0].PrevEnc.a=$ba38e008 Shouldn't the address of the EncTable[0] and sys.Udata[0] be the same I did monitor EncTable[0].PrevEnc and saw that it does reflect the value in Sys.udata[0], although I still don't understand why it the addresses are different. John
Link to comment
Share on other sites

John, The EncTable[0].a will return the base address for the Encoder Conversion Table entry 0. Sys.Udata[0].a will return the address of first user shared memory location. The only reason EncTable[0].PrevEnc is reflecting the value of Sys.Udata[0] is the fact EncTable[0].pEnc is set to sys.pushm and EncTable[0].Type=1 which means read the value of sys.pushm as a 32-bit integer read. These two are completely different memory locations, but since ECT is active EncTable[0] is reading the sys.pushm which is the same as sys.Udata[0].a Since your Motor[x].MasterCtrl=0, Do you have any PLC or CPLC or background c application running when this runaway happens?
Link to comment
Share on other sites

[quote='Sina' pid='1002' dateline='1294336507'] John, The EncTable[0].a will return the base address for the Encoder Conversion Table entry 0. Sys.Udata[0].a will return the address of first user shared memory location. The only reason EncTable[0].PrevEnc is reflecting the value of Sys.Udata[0] is the fact EncTable[0].pEnc is set to sys.pushm and EncTable[0].Type=1 which means read the value of sys.pushm as a 32-bit integer read. These two are completely different memory locations, but since ECT is active EncTable[0] is reading the sys.pushm which is the same as sys.Udata[0].a Since your Motor[x].MasterCtrl=0, Do you have any PLC or CPLC or background c application running when this runaway happens? [/quote] Ok, now I get it.... Yes I have a plc1 running... Here it is open plc 1 // --------------------User Code Goes Here------------------------ if (myvar_2<=20) { myvar_1 = 200; myvar_2++; } if (myvar_2 > 20) { myvar_1=Sys.Udata[0]; } close I have added myvar_1 to the watch window so that I can verify the changes made to sys.Udata[0] from the terminal window.
Link to comment
Share on other sites

[quote='Sina' pid='1004' dateline='1294337436'] Can you reproduce the runaway situation? Just write a large number to Sys.Udata[0]. You can select a number which results in one inch or one revolution of motor units depending on your motor whether it is linear or rotary and see if it causes any movement on the motor. [/quote] When I enter a value of 100,000,000 to flips out. my axes defs are #1->2000X #2->2000Y both motors are failing.... If I enable only #1 it will fail and if I enable #2 it will fail and if I enbale both, both will fail
Link to comment
Share on other sites

[quote='JohnR' pid='1005' dateline='1294337982'] [quote='Sina' pid='1004' dateline='1294337436'] Can you reproduce the runaway situation? Just write a large number to Sys.Udata[0]. You can select a number which results in one inch or one revolution of motor units depending on your motor whether it is linear or rotary and see if it causes any movement on the motor. [/quote] When I enter a value of 100,000,000 to flips out. my axes defs are #1->2000X #2->2000Y both motors are failing.... If I enable only #1 it will fail and if I enable #2 it will fail and if I enbale both, both will fail [/quote] Also.. No movement at all with smaller values, say 10,000,000.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...