Purpose of this post is to shed light on what’s going on in IONI firmware development.
In development:
Finalize BiSS encoder support
Add SSI encoder support as well
Direct support for AustriaMicrosystems (ams) SSI encoders and RLS BiSS & SSI encoders. Both make nice low cost magnetic rotary and linear encoders.
Automatic foolproof configuration of Hall sensors - if such sensor is wired, no longer need for motor phase search procedure (the swinging of motor shaft)
Enhancements to buffered motion stream usage: reduce number of Simplemotion commands to transmit to fill buffer -> reduced buffer latency
Planning:
Full-featured absolute encoder utilization (eliminate need for homing & phasing & hall sensors)
Auto-tuning of all motor parameters
If you got an idea or comment regarding IONI features, go ahead and post it below
Okay, some people wondering about the spring- oder rubber-like feeling of the DD.
That problem is, they are conditioned the cogging of the small servos in the gaming wheel.
If you set in TRF1: 12 and TRA1: 0.50A, you can simulate that and the feeling are like that, what they expect.
But, 12 are to low. When that value are open / free to change, you can simulate that. I think, 60 - 120 will enough.
I know, that feeling is wrong, and the feature are to eliminate that “problem” called cogging, but this will be open source and why not, if you only change the maximum vom 12 to 300, thats it.
We can simulate older wheel to show friends, how it was with the old wheel at big cogging and 2,5nm.
Is there any way to program the GPI / GPOs of the IONI? I have a processor connected to it & I want to change a GPO depending on the encoder direction. I’d also like a GPI to switch between motor types. A lot to ask, but ask I shall!
@Manolo So would you need this just to produce cogging, not to eliminate it? That would be easy to add to the SimuCUBE OS FW, needs just one line of code. So I bet that would be a good place for that.
@Dan_G I have some ideas to make GPIO configurable so that you can select their function from pre-made choices. Full programmability of them is not easily done in Ioni due to program size & speed constraints. In Argon drive you can do that as it has own MPU for IO completely.
Thanks, Tero. Just a thought like having a link in Granity to mirror a function on a set GPIO would be great!It may be a little application-specific (as we always ask for!) but might b a neat twist.
Would it be possible to implemet the IONI firmware such that lower currents are used for the phase search and initialization and then ramped up during normal usage?
Asking, because with the correct parameters for my SimuCUBE/IONI HC Pro/Lenze(MCS12H15, 400V) setup of 5.5A cont./14.5A peak, the phase search will fail, but if I set lower currents (e.g. max 2A cont.) and ramp it up later on, it works as expected and I actually never experienced a failure other than during the initialization.
@Dan_G We’ll think about such feature, it would be useful indeed.
Currently we do such changes as custom firmwares. If you need one, you can order such change. Usually these are small jobs and not costing fortunes. I hope this helps!
@Berniyh Which fault you are getting? If you set too high peak current that is impossible to drive (due to motor resistance vs supply voltage), then that may be the reason for problem. Proper solution to that is to lower the peak current setting. By that you won’t lose any torque if it was impossible to reach such current anyways.
It claims an undervoltage fault (440501).
The currents should be ok for my servo (I0 4.1A, IN 3.8A, Imax 12A).
The current at which max torque (29Nm) should be reached is 29Nm / 2.79 Nm/A * 1.41 = 14.6 A.
Slightly lower values (e.g. 4.5A cont. and 14A max) won’t work as well, I have to reduce one of them significantly, e.g. cont. to below 4A.
In case you wonder, the PSU can supply 20A cont. (and 26A peak) at 48V, so that’s not the issue either.
Once phase search is finished, I can set 5.5A cont. 14.5A peak without having an issue. To test it, I did a 30min drive in a high-downforce car (Lotus 98T around Nordschleife) at max. FFB and didn’t notice a fault or a torque drop.
That undervoltage fault 440501 means exactly that it was inpossible to induce such current to motor with given supply voltage. I.e. if motor resistance would be 5 ohms and you have supply voltage of 48V, then theoretical maximum current would be 48/5=9.6A, and in practicel little bit less than that.
To get more current flowing, higher voltage or lower resistance would be needed. That’s Ohm’s law.
@Berniyh it means peak current (same scale that you enter parameters). I guess MMC values between 7.5-8.4A would be realistic. Yes, you can increase supply voltage little bit to get little bit more torq, but difference would be only few percents.
It’s not that big of a deal, as I’m not after maximum torque.
The FFB is just strong enough even when I set it to 40-50% in game, so I’m not worried there.
My main motivation was that I wanted to understand what happens here and indeed I did not consider the resistance (and so did noone else I talked to). It does make sense.
I played around a bit with the values and with 5.5A cont. and with that everything up to 11.5A works reliably for the phase search.
But indeed with the voltage I have currently set up (53VDC), I can get a maximum current of 9.5A judging from the testing tab.
One last question on the topic though:
So why did a value of e.g. 2A cont. and 14.5A peak work during initialization? If the drive tries to output the peak current, shouldn’t it fail regardless of what is set as cont.?
Drive calculates initialization current from parameters MCC, MMC and MTC. The phasing current will be a value between MCC and MMC, so that’s why also continuous limit (MCC) affects.
