IONI firmware plans

Ideas, News & Feedback
,
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
55

@propcoder, that is a very good and constructive feedback, thank you! I will go through the list during next days.

Good point. To help this, the text Granity version will pre-select the device that has been connected previously. If no previous selection exists, it pre-selects the first list item.

56

Is that possible, that we can generate a “lag” for SimuCUBE. I know, that lags be things, that we don’t want. But with my wheel, i see, why another driver loos the cars because the “gaming-wheels” has big lags. If i can set a synthetic lag, i can test that or show another people, what are the difference between gaming and DD-wheels. With TRF1 at 100, TRA1 at 0.33A, max Force 18,333% and 30 - 40ms outputlag, we can simulate a thrustmaster T500RS.
When its open (source), why not.

57

Things like this, that don’t improve the feeling, are very low on the todo list at the moment.

58

All set up with RESA 32 bit encoder system, so would gladly test it out when the new beta is available :D.

About SSI support - if user can define the actual start and end bits of positioning bit sequence and the sequence endianness in Granity, it would probably be possible to cover more currently not supported encoders. Example: the position info starts form 6-th (first 5 bits position non-relevant data) bit and goes to 26 (having some additional 8 bits of non-relevant data in the end of sequence), so all the bits between are position, starting from most significant bit.

59

IONI firmware 1.6.0 beta 2 has been just released. It adds many new features, not just BiSS/SSI support. For full list & download, see http://granitedevices.com/wiki/IONI_firmware_releases.

Also grab a copy of just released Granity 1.13.0 which is needed for the new FW: http://granitedevices.com/wiki/Granity.

We’ll appreciate any shared experiecnes and feedback regarding this FW+Granity combo :slight_smile:

60

@NCG, all SSI encoders I’ve seen so far had same number of bits before position data is transitted. Do you know any specific encoder model/make that has discardable bits at the beginning?

All of those encoders had model specific additional bits (such as warning bits) at the end of transmission, so they don’t affect read-out of the position data.

61

Zettlex IncOders have SSI variations with timestamp (SSI4), validity etc bits in the beginning and/or end. I do not have any specific versions at hand currently but will order few for testing.

62

Thanks! Indeed they seem make different data combinations. Perhaps we implement the more generic SSI support if there becomes enough demand for that, or at some point in future if all the other pending features are already done :slight_smile:

There are few pending tasks such as utilizing the absolute information from encoder in the to-do list. Now they all run in differential mode even if encoder has absolute capability.