IONI firmware plans

Ideas, News & Feedback
,
33

Hello,

I am really glad to see, that the 1.6.x IONI firmware specifies BiSS and SSI, have been waiting this to happen. Curious to see bit depth limits, the perfectionists want sometimes even more :). Just for a handful of bits more (26/ 32/36 bit) and it could cover the Renishaw Resolute series for example. I assume the SSI/BiSS support would trickle to the ARGON too?

Regards,
Tom

34

Aah, thanks fro clarification. This is probably not doable in useful manner as it would consume the necessary encoder input pins that are only pins there to read analog value.

35

Sounds like you might need higher order TRF as you mentioned. We’re planning some form of lookup table based method there too, which would be more universal and covers higher order ripples too. No date on that yet.

36

@NCG The limit is 32 bits currently but we could support higher as well. Can you point to some encoder specs with more than 32 bits of resolution?

Yes, Argon support should follow (if there is enough demand) after testing on Ioni has been completed.

37

Hi Tero,

thanks for that info! I understand that this is not on top of your list. Still it could be useful for all, as in some games there is really bad cogging when forces get high (like in LFS) and high filter settings in MMOS must be used to get around that.

Thanks again!

Cheers
Max

38

The 32 bit resolution already supported, that is nice to hear! Going to try it with RESA and RA32BAA. The wiki probably needs to be updated, my 24 bit max single turn resolution information came from there. AFAIK, 36 bit is used only for long Resolute linear encoders currently.

39

Hey Guys,
For those asking about the Lenze (and other servos), I made a basic spreadhseet to show main used servos and what we can expect from 48V power source via IONI.

I ordered new Lenze MCS 12H15L and MCS 12H15 arrived, so now I have 400VAC version which will give only ~15NM torque at 48V. I will look at some mods to make things a bit better here. Hope the below is handy for some.

Cheers,
Beano

1024×394 153 KB

40

@ Beano: not quite. It’s rather 16.6 Nm at 48V.
But the common PSUs have the option to increase the voltage up to 55V, which should be ok at the given currents.
Only the Meanwell 480W (without peak option) might struggle there.

In case of 55V you could reach up to 19 Nm.
Although the question is if it actually matters.
I’m running it at 17-18 Nm and actually are only using about 40-50% of the torque in-game. So there is plenty of headroom.

I am still thinking about switching to the 230V version, but mainly because I do have the 960W PSU anyway and it is said to have slightly better response and less cogging, which I’d appreciate because I love drifting.
But I’m pretty happy with my Lenze. :wink:

41

@Berniyh: You need to consider the IONI 92-95% efficiency, it’s not 100%…plus, the coil resistance of this specific Lenze servo at 20 deg C = 5.7R, but increases to 7.7R at 150 deg C. I typically run 20-30Nm in iRacing, depending the car, with other servos.

But I will give this a go, it might feel good actually :slight_smile:

Cheers,
Beano

42

@NCG, actually I remembered it wrong: it is up to 32 bits for single turn and multiturn combined but singleturn limit is 24 bits in current FW beta. But it is possible to change in FW and looks like we should do just that. Let us know when you have the encoder and you can be the tester of that resolution :slight_smile:

43

Quick update on latest development in IONI firmware & Granity:

  • IONI will allow capturing graphs before the trigger event occurred. Until now it has been only possible to capture graph after the trigger occurred. This rendered “Capture on fault” trigger quite useless. Not any more - it will be very good tool for troubleshooting fault reasons.
  • Granity will allow doing captures offline. This means that one can setup capture, disconnect Granity and wait trigger to happen and display the graph later by reconnecting with Granity. This is good for capturing events that happen rarely or are hard to reproduce under Granity.
  • IONI will automatically start a default offline capture when it is powered on. This may be useful for troubleshooting initialization issues.
44

Very nice feature, Tero. So something like ringbuffer. We use same in our Automation system, very handy for difficult to identify problems.

I personally cannot wait for new OS FW :slight_smile: Thank you for all your efforts!

45

I’m Keen as for the new OS FW as well you guys are doing great things for the DIY community so thank you.

46

Another update: serial data encoder support is getting on better.

In TODO list are:

  • Utilize absolute information in drive initialization (no phasing or homing needed)
47

When can we test that new FW, please?

48

@Manolo, sure. It’s not yet finished but shouldn’t take very long. I wan’t to integrate few other new featues in it as well, so it will be quite big upgrade step.

1 Like
49

Okay, sounds good. Is that feature to set more than 12 at TRF1 and 2, inside?

50

Good idea to do it on same update. I just did that.

53

This may have been too early said. The useful range will be few bits less as such resolution would need bit more changes, it seems. But who needs 4 billion counts per revolution anyways? I don’t know :slight_smile:

However, one can still connect any resolution BiSS encoder, just set lower number of bits in settings and it still works. It just won’t utilize some of lowest bits.

54

Hello to Granite Devices team, hello all.

I had an opportunity to work with IONI and IONICUBE 1X. It is a great idea of a product “all-in-one” and I like that.

I was trying to adapt and integrate the IONICUBE 1X and have the following notes for you to consider. They might seem critical, but take them as my experience, and, preferrably, create some constructive ideas out of them:

  1. Fault signal seems more similar to working_ok signal. In my opinion there should be no fault when only Enable is off or STO is activated.
  2. Ready signal is somewhat similar to consider. Maybe the drive is ready when not enabled, so it is ready to enable, or it should be named more clearly or be free to customize its behavior.
  3. There is no mode to be able to control the drive with enable signal, get simple fault signal and clear it easily on negative or immediately after next positive front of enable signal. This makes LinuxCNC integration with amp-fault signal complicated. And if it can be reached with current modes, it either requires excessive wires, non compatible voltage levels, complex logic from controller and not clear mode names to choose from…
  4. Setpoint (at least in torque mode) is not accepted in PWM mode when is at 0 or 100% (not pulsing). This behaviour could be selected in configuration.
  5. Charge pump on STO is not possible in SimuCUBE mode while it could when CEP is selected.
  6. I would like to freely select how fault signal should work, when it is cleared, what type of enable and STO to use
  7. Drive enable delay is too big (tested with brushed DC motor). Could be microseconds to a millisecond range, but it is ~200ms.
  8. It is not clearly stated what input signal levels can IONICUBE 1X accept and open collector output signals live with. Wiki needs at least a sentence more here: https://granitedevices.com/wiki/IONICUBE_1X_connectors_and_pinouts#Using_24_Volt_control_signals.
  9. There is no three-phase stepper motor control.
  10. Granity in Linux Debian Jessie amd64 runs, finds an USB adapter, but can’t find a drive. It does not give any error message, just the button text changes to “Searching devices…” and terminal output says it is scrolling through addresses. While Granity for Windows in the same computer on VM works.
  11. Capture and graphs in Granity are really slow, not real-time, lack trigger funcionality.
  12. List of found and powered drives in Granity asking to select the drive each time after reconnect or drive reboot is somewhat annoying (especially when there is one single drive). Integrator has to move a mouse to the center of the screen, double-click on that thin line or take two hands to Shift+Tab, Enter. While integrator is often using the hands on multiple apps, systems, physical things to touch, etc.
  13. My suggestion on naming: avoid repeating names, codes in different context, like matching of connector names on different products should be avoided. Now very similar product names and the matching connector names may be the reason for mistakes or… smoke.
1 Like