Estimated Max Torque MIGE

I have a question regarding SIMUCUBE and the MAX TORQUE ESTIMATION

My hardware configuration:
Servo Motor Mige (10000ppr) (130ST-M15015)
Granite Devices IONI pro HC
NDR-480-48 (480W

How should i interpretate this: “Estimated Max Torque = 41.33Nm( is that “high” value not dangerous for the motor spec i have ?)

Knowing that the motor is a 30Nm

But when starting the “configure motor, encoder and center point” , the requested value set to “0” by default should be set to 1.58


Thanks for the support :wink:

PS: i leave you below how the GRANITE setting are for what i use:


Please take a look at firmware release history page. It clearly states, as a known issue, that estimated torque calculation is most likely wrong.

Not everyone uses Small Mige, and the torque constant isn’t saved in motor configuration / drc file, so for the moment, it is going to remain as it is.

Hello @Mika,

thank you for the quick support :wink:

I should have post as an as an interrogation ( modified first post )

So to make sure i unserstand it well ( sorry for my bad english ) .You mean that i should not take the “estimated max torque value as reference” . I can leave the “overall strength” to 100% ?

I´m a “newbee” in the new world :slight_smile:

You can use the system as you like. The number (which is, for the moment, calculated in a wrong way) is just not correct.

Depending on the motor and wiring resistance differences, the small Mige should output around 20 Nm of torque using the highest rated current.

Ok…Mine is 30… ??

Yes, the number is just wrong.

If this bothers you, run the motor configuration wizard again, and put 0.00 to the constant.

thank you for the support @Mika

I just want to make sure not to do something wrong …

There is a two part calculation to get that torque number and in prior to current release versions only one part of the calculation was being done (the one that gave Maximum torque regardless of the amperage setting) which is why the number is incorrectly high. When time is found to implement both calculations correctly that feature may come back. It is NOT a performance feature it is just a usability feature so it is not supper high in priority.

Just noticed this is a really old thread… weird just came up as new postings for me…