I’m using an IONI basic with small Maxon external rotor 90w AC45 flat motor. Encoder is CUI. Twice now I have had the motor overheat and burn out a coil while testing with Granity. The first time I had no idea why it happened, the second time I think it was associated with a frayed motor wire. One problem I have found with the IONI Cube is the terminal connection tends to cut into the wire and break the strands very easily. When the motor overheated it had been working fine, I was just trying a few tweaks when it starting getting hot and then suddenly it was smoking. One coil now shows slightly lower resistance than the others, and while the motor will still start up without an initial fault, Granity fails if I try and measure the resistance/inductance. Anyway - after the incident I noticed one of he motor coils was barely connected, hanging on by one strand of wire. I’m not 100% sure this was the cause but seems like there is a fair chance it was? I’m a bit reticent to experiment and risk another motor. So is it something that invariably will cause overheating, and if so, is there anything that could be done to make the drive more failsafe? I was planning to make a portable device using this drive, which has to be very reliable, and I am afraid that if a motor wire ever becomes slightly loose, it is going to risk this happening at a bad time… Thanks
IONI measures the current flowing into the motor all the time and if the current deviates from the set, then the operation is halted. IONI also measures it’s own temperature all the time and reduces output power if the temperature rises too high.
Was the motor under load or without when this happened?
To help with this issue, please reply with the motors datasheet and IONI settings.
Thanks - the motor was not moving at the time and I didn’t notice if the IONI was hot… Sorry my memory is a bit vague, I think it might have been while I was trying to auto setup the hall sensors - which can take a while - and in this case failed or stalled, I’m not sure. I had trouble deciding on a value for time constant - and found the minimum allowed value seemed to be 30? BTW - should the max current be set to peak or stall current ? Does that upper value always limit current to the motor under all circumstances? EC45_90w_catalog.pdf (144.5 KB) MaxonEC45_Working.drc (8.5 KB)
Motor Continuous Current (MCC parameter) is the motor nominal current. This is defined in the datasheet as parameter 6.
Motor Momentary Current (MMC parameter) is the peak current that the motor can handle. Some manufacturers state the peak current in stead of the stall current, and this is usually three times the continuous current. Stall current can be much higher as it can simply state the physical current the motor draws when it’s not rotating with the rated voltage. In this case it’s about 7 times the nominal/continuous current.
The MMC is the maximum current at any given time that is driven into the motor.
The time constant should be such that when the motor is operated with peak current, the time allowed for peak current is limited (byt the time constant) so that the motor will not over heat.
So - given the specs what settings would you use in IONI?
According to your advice I should multiply the published values x 1.4. . ie. MCC: 3.57 x 1.4 = 5A and MMC 5Ax3 = 15A, (Where it was previously 4A and 8A.)
But these tweaks don’t seem likely to explain the problem. If anything I had more conservative settings than required? The motor had been working previously ok without incident and without getting hot. So how could the coil suddenly burn out? If the motor was not moving or being commanded to move? I could understand if maybe it was driving against a load…
As I mentioned - I am suspecting a bad connection somewhere - but is still concerning that this could happen out of the blue…
PS - I have a new Nanotec motor I am replacing this one with, model DF45L024048. Very similar specs but for current it states Current Rated/Peak (A) = 3.26 / 9.5 Would you do the same for that - ie. multiply by 1.4? And is there a way I would be able to tell if it is the wrong thing to do? !
You are correct, that these current values do not explain why the motors has burned. It’s also very weird that they would overheat so much with lower current than nominal.
I can’t see how bad connection would neither cause this issue as IONI would stop driving the motor if it detects lost connection.
For the Nanotec motor, you could first set the system with the current values stated in the datasheet. This would be safe bet, and the performance in the application will tell if the achieved torque is enough or not. At least you would be able to build the system and test it, and ensure that the current setting is on the safe side.
I think there is a bug here somewhere because this is the second time this has happened. I had it happen with a Nanotec some time back. Is it possible the frayed wire could cause it? It wasn’t completely disconnected, rather it would have presented a higher resistance on one coil.
I also noticed that one of the Maxon Hall sensors was not working after the incident. Could there be any link there?
I am now using ferrules. With screw terminals I hadn’t had such a problem.
From what you say it seems impossible to burn a coil - yet it happened…
If there was some conflict in settings, or fault somewhere, such as Hall sensors - could that be a cause? It’s possible there was a typo error in some setting which wasn’t saved - so doesn’t show up in the file?
BTW I often get “program not responding” when I change from test graphs to help in the right pane. I don’t have proper internet connection in the workshop - could that cause the long and indefinite pauses?
We are investigating why Granity software currently hangs when changing tabs. Its somehow to do with the loading or attempting to load the website pane on the right. It seems to happen on new Windows 10 installations but not on the “older” development machines we have.
One possibility is that we will just port the software to the latest Qt framework version and see what happens then.
Thats good information as well. Nothing has changed in the software, and when Windows 7 was the latest Windows, we never had the issue. So something is changed, maybe its to do with some network/security related things.
I have more tings to ask - not sure if this is the place - but here goes.
Why are there 3 places to enter maximum rpm? I have found these setting really hard to distinguish between… If the descriptions were a bit more detailed and explained what effect they have it might help. But it seems there might be some duplication of functions…
The motion fault error is a bit obscure to me. What exactly does it measure? As an example, I had the motor sitting idle for a while and it kept faulting for no apparent reason - no motion commands had been sent.
I’d also like to backup what someone else suggested. That bandwidth could be reduced when there is no movement. That would make the motor less noisy when at rest. To get good response I have it set to 330 or 470, but at 470 is a lot of motor noise - like random static…I’ve seen similar kinds of adaptive tuning on other servos and it was quite effective…
In the fault register it said “motion”. I presume it refers to the FMO setting?
Of course it’s not happening now, so I can’t tell if there was any other information…
*Edit - it just happened again. It is fault 140415
Seems to refer to excessive step or direction pulses? Yet there are none being sent - maybe it’s noise? Though I can’t see any movement or evidence of phantom pulses…
