That is strange, never seen that happen. There is a slight possibility that the motor goes into some other fault mode, but I think my bit masking code checked only that particular bit from the motor status register. Actually, that register content that is also send to the configuration tool, and is the only thing SimuCUBE does with that register…
Does it also show that E-stop is pressed in Granity?
Can’t get the E-Stop issue replicated for now.
Another issue that I found:
This messes up the profile settings.
I tried this last night and successfully loaded DRC file setting in Granity 1.13 with no issues using the above mentioned method. All was good for me.
Wheel did not require re-centering.
Could see TBW limits, center notch and damping/friction/inertia settings from my DRC file populate the settings in SimuCube configuration tool window.
Hmm. Interesting. I used to have similar issues in some cases, but they should be very much handled now. Did this affect all the profile settings or just the ones from Ioni (i. e. the filters?)
Hi Martin,
When you get the e-stop alarm, can you check if you have not exceeded over velocity in Granity? You can make that bigger to prevent the fault…if it indeed is that…
All profile settings are changed. Here is a screenshot of the changed settings.
Y-Axis and brake-axis are jumping around and have to be set to “not configured”.
Still wasn’t able to trigger the E-Stop fault again, but I’m sure it wasn’t over velocity fault.
Upon disabling the SimpleMotion USB configuration mode, the configuration tool sets a flag that updates are required. That will then automatically populate hardware settings, analog settings and profile settings, with 3 separate commands / “batches”.
Having all of them (well, at least analog and profile configuration packets) corrupted like this is strange and shouldn’t happen. However, the software doesn’t yet actually check if the packets are correct format at all, it just dumps what happens to come from the SimuCUBE as responses.
To help debugging whether this is a connection issue with SimuCUBE at this particular moment, or if something very unexpected happens in the firmware, you can report if the same corrupted values appear when you close the Configuration Tool and reopen it. It will re-establish communication and retrieve values again.
Please also tell if you first disconnect from the drive in Granity or if you just leave granity running in the background when you click the button in the Configuration Tool.
About the e-stop issue: Most likely you have a loose or failing cable for your hard-wired e-stop. I highly recommend using an actual e-stop switch, especially when using beta firmwares like this.
I managed to repeat this bug.
Settings auto-apply every two seconds. If you change a setting and then click save very fast before the auto-apply timer runs, then the blinking notification will actually start to blink after you have pressed the save button.
I will try to accommodate this case. Maybe the save button will have to first auto-apply all, then save, even if the auto-apply all isn’t required for 99% of the “slower” users 
Wrong profile values are shown as soon as the button “enable Ioni USB configuration” is pressed.
Restarting the configuration tool solves this and the correct values are now displayed.
Changing parameters (like TBW) in Granity works as well. The new value is shown after restarting the configuration tool.
Does it absolutely always do that?
Yes, exactly. It won’t show correct values without restarting.
Just ran 1 BSS and 1 IMSA race today with plenty of practice in between and have had no issues rising up so far.
One thing I noticed in iRacing and thought that maybe it is best to mention here. When I had old custom controls saved on a car, I removed the custom controls so that it would use the default controls I have calibrated for the SimuCUBE. After I did that, I did not have FFB at all but the wheel was turning. I could recover the FFB by just restarting the client.
Not sure if this related to SimuCUBE or just to the way how iRacing handles peripherals in general.
There was a mention in the stream chat that someone had the similar thing happening to him on Thrustmaster wheel, so that makes me thing it’s the way of iRacing of handling the USB devices.
I cant change anything, what i have missed, please.
I have 2 USB-cables connected, flashed and restarted the SimuCUBE and system:
Have you rechecked that the dfu mode dip switch is in correct position?
Is simucube or any other device visible in windows game controllers or in control panel?
I don’t change the switch, but i think it was flashed. please look my pictures.
At this time, the SimuCUBE works already fine and like before. I can made changes by MMOs and use Granity.
Did i have to change the dip switch for flash the new FW? I think, that makes the DFU-mode in MMOs.
edit:
I just change the dip switch and try it again…
Flash it proper, by moving switch. I suspected earlier you have not done correctly.
Cheers,
Beano
I Didn’t have to change the jumpers on the initial firmware update working great but if I understand correctly I will have to if I want to update to the next iteration.
Same here. Did not have to open the case when changing from MMOS to 0.4.1
