Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
runaway motor
#1
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
Reply
#2
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,
Sina Sattari
Hardware Engineering Manager
Delta Tau Data Systems, Inc.
Reply
#3
(01-06-2011, 09:55 AM)Sina Wrote: 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,


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

Reply
#4
(01-06-2011, 10:06 AM)JohnR Wrote:
(01-06-2011, 09:55 AM)Sina Wrote: 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,


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

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
Reply
#5
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?

Sina Sattari
Hardware Engineering Manager
Delta Tau Data Systems, Inc.
Reply
#6
(01-06-2011, 10:55 AM)Sina Wrote: 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?

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.
Reply
#7
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.
Sina Sattari
Hardware Engineering Manager
Delta Tau Data Systems, Inc.
Reply
#8
(01-06-2011, 11:10 AM)Sina Wrote: 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.

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

Reply
#9
(01-06-2011, 11:19 AM)JohnR Wrote:
(01-06-2011, 11:10 AM)Sina Wrote: 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.

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

Also..

No movement at all with smaller values, say 10,000,000.

Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)