Request (Feature) Support for GraniteDevices IONI (SimpleMotion V2) protocol

I've been working with GraniteDevices products (first Argon for my OpenSimwheel build, now IONI x4 for a controlling actuators) for a while now and I'm wondering if there is a plugin-system or an interface definition to add GD's SimpleMotion V2 protocol as an output type?

At first I was thinking about writing everything from scratch, but somehow I realized that I just don't have that much time right now so I'd like to build it on top of SimTools.

Just for information: IONI is a low-cost motor controller (that can run AC servos, DC servos, stepper, actuators etc) out of the box, ranging from velocity control to position control to torque control. I'm planning converting my SCN5 based 2DOF motion set up to a AC servo actuator based setup (Bimba Actuators with AC servo motors) but in order to communicate with the IONI servo drives I'd need a new Output Type.

The communication protocol is rather simple and well documented, so I'd like to offer my help in implementing it.

Any timetable on ST2? I'd also love to see some usability improvements tbh. While way less PITA than the original X-Sim it's still kind of ugly to set up and get it working.

You should possibly have a look at Lince which really is stellar in terms of usability

I've had my SCN5 controllers wired in a bus system on a single com port hence ID 0 and ID 1. For starters it would be nice to know that this is a requirement - so putting a warning/info label on the axis setup screen would have been a big help. But since RS485 can handle such infrastructures it would be best to let the user manually enter the COM port and Device ID in the setup screen. Keep in mind that with RS485 you could hook up to 253 on a single physical COM port.

In my case this is fairly important as this is the way my IONI build will be set up, but it also applies to anything hooked up via RS485.

---

About the Software and usability:
- it's a bit confusing when setting up the effects, especially when configuring min/max values for different kind of DOF effects and filters. While it seems to have a normalized UI it kind of feels like all the sliders and effects are spread not only over different tabs and screens but also over different applications (GameEngine and the profile tool for example). IMHO this needs to become centralized so it can be accessed from a single entry point
- all in all the whole UI experience is a bit scattered. Too many different entry points for similar things

I really urge you to have a look at Lince at some point. While not perfect in many regards it is the easiest user experience so far regarding motion setup. It lacks some features that SimTools provides - but creating a working motion profile is not only easy, but intuitive.

I've done my fair share of UI design in the past, but the SimTools experience is almost as confusing as the old X-Sim experience or the SX SimCommander. It lacks focus of the important things for the end user and concentrates a little bit too much on the technical stuff. I am a professional (.NET) software engineer but even I can't seem to figure out SimTools without help from 3rd parties, surfing the forums and reading the documentation over and over again. I think this has always been the achilles heel of XSim and SimTools and the reason quite many run away scared to the competition. The only reason that SimCommander from SX works is hype marketing and specialized feature-richness regarding 3DOF sims, the user experience is almost as catastrophic..

sidenote:
- what I find annoying is that I have to set up the game plugin every time I make a change on another config screen. While setting up iRacing I had to choose the plugin about 3 or 4 times on different screens, everytime I open them. Would be nice if this could be stored in the session, not a dealbreaker, but annoying.

Sorry if this sounds like a rant, but I'd honestly like to provide constructive critics, but I feel it's a too big topic to discuss here on a sidenote. But a UX overhaul is drastically needed, not only in my opinion :/

I'll probably drop some UI mockups next week (if I find the time) that I sketched up for my motion project (which I'd love to abandon when the enhanced plugin system of 2.0 comes out). It's structured in a similar way as SimTools is I think, but as I'm not a huge fan of re-inventing the wheel and realized that I won't have the time to do it all from scratch I'd like to move to SimTools

I understand the structure and why it is modeled that way - totally agree in that point. It's already a big leap forward to the old X-Sim days and the flexibility in output types, mixing the effects, the broad availibility of plugins - they're all off the charts and great. I love it to see that there is continous development, that the plugin interface gets expanded etc. But features and flexibility don't neccesarily have to end up in complex UI design. That's pretty much the one and only complaint I got at this point - so may sound a lot worse and depressed than I intend to be

Still.. After 6 hours of use I still struggle to use the whole range of my SCN5/100mm actuators. No matter what I change I only get about 20% of movement out of them. Doesn't matter if I change the axis limits, the 'default' profile, the game profile or even the min/max values in the tuning menu.

The thing is that I'm not sure if it's a bug in SimTools or the game plugin or if I'm just too dumb to set it up to my likings because I just don't have an overview of what slider effects the whole experience in what way - and that's usually bad after almost a working day worth of time invested.

About the RS485 stuff: yeah, I've made the same observations, 2 is fine but anything more will hurt performance badly. Still this is how it's supposed to work so I think it should be possible to select a) the same com port on different axis' and b) to select the device ID which is RS485 protocol standard. I actually use a PCIe RS485 card because it lowers response latency and gives a better throughput than the FTDI chips which I had needed in the early OpenSimwheel days..

haha, wasn't my intention, I actually intended to do the opposite Hitting that small icon on my old, lagging droid phone isn't as easy as it sounds^^

If you're interested, I've tried to compile the simple motion library, and found a few simple bugs that I have corrected.
Be aware though that in the current status of the IONI firmware, you wont be able to send messages at more than 60 FPS.
I've sent a message to Tero of GD, asking if it could improve this refresh rate, but I've had no reply so far.

You'll have to use low level functions to gain speed. In the case of motion it's simple - the only thing you need is to set a position setpoint, so you basically set the cmdParam just once and only send the bytes needed for the position in every cycle. You don't even have to request a return value.

Have a look at either the Argon Wiki or my OSWCommander project at GitHub (github.com/OpenSimwheel).

On the Argon the limiting factor was the bad response time from the uC, the IONI chip responds much quicker.

With an FTDI USB adaptor i was able to achieve around 250Hz stable, with some tweaks in the SMv2 lib and the IO side code on the Argon even close to 600Hz. With a PCIe RS485 card I was even able to get beyond 1KHz on the Argon, but that's when the Windows timers start to fail badly, even while controlling the loop through CPUFreq..

IONI should be able to go past 500Hz without additional tweaks on a standard FTDI USB chip when using lowlevel functions.

Ok thanks a lot, I must have missed something somewhere.
I'll have a look at the Argon Wiki and your OSWCommander project.

...oh and of course you'll have to change the timeout of your FTDI adaptor to 1ms (default 16ms) in the device manager - advanced settings. This could also be the reason for your 60Hz experience.. ;-)

Ooooh Ok, that's what I was missing ! (FTDI advanced settings)
Now it takes between 2 and 3 ms to send torque or receive position, so approx 7 ms total. Better, but 120 Hz is still not enough to do a proper FFB.

I'm currently using these 2 calls :
smRead1Parameter(smh,nodeAddress,SMP_ACTUAL_POSITION_FB,&position);
smSetParameter(smh,nodeAddress,SMP_ABSOLUTE_SETPOINT,torque);

Could you please explain what you mean by "low level functions" ?

Thanks

What exactly are you trying to accomplish? Without modifying the firmware I'd heavily recommend to rethink the project as windows timers are very jittery and not nearly precise enough to calculate smooth damping or anything else in that regard.

About the lowlevel functions.. have a look at the OpenSimwheel Commander project as I can't recall the exact function right now..

You basically initialize the parameter you want to retrieve, set the byte length (once), set the parameter you want to retrieve and set (once), retrieve and ignore the null values in the buffer (loop), read the parameter and set the setpoint value..

There is a pretty good example somewhere in the GD wiki.. I'd look it up if I wasn't on my phone..

I am trying to do a FFB wheel using RS485, either directly on windows (so with a driver that would need to be written, or directly in my game engine), or from an arduino board using a RS485 shield (could not manage to get it working yet). This would reduce wiring complexity and would mean no additional microcontroler hardware in case of direct control on Windows.
I already have managed to do a FFB wheel using an Arduino Leonardo. I'm decoding the quadrature encoder signals and sending a PWM+Dir torque setpoint, but if RS485 communications were fast enough, it would be even smarter to use it (especially considering that the IONI does'nt have a replicated port for quadrature signals like the VSD had, so replicating these signals to a microcontroller is a pain in the ass, a special cable is needed).
I'll search in your OpenSimwheel Commander project for lowlevel functions, but I'm not sure I can use them to read position and send torque, as it seems to be suited to send or receive only, not both. I'll see.
Thank you very much for your help, I've learned something today

Erm.. I do exactly that in my commander app ;-) Read position and feed a new torque setpoint. Haven't done any work on the public repo as I abandoned it in favor of a vJoy FFB implementation. I'm just waiting for vJoy 2.1.6 to be released some time in August/Early september which fixes a few major issues regarding steering wheel FFB.

I wouldn't go the windows only route though if you're planning on using a servo (direct drive) as damping is the most critical component on this system to avoid oscillations and to add a bit of weight to the wheel as it feels completely unnatural and too responsive without it. Without a RealTime OS you'll get ugly jitter in your calculations which will either kill the detail out of it and introduce lag if you're going to postprocess/filter it or you'll get unwanted, unnatural 'sand' in the gearbox if you don't. Precise velocity and acceleration calculations are a requirement imho.