Re-enable torque button does not work when changing to a wheel without wireless.
Enabling and disabling Emergency stop doesn’t fix it either.
How do I disable automatic torque off?
it wil be fixed in next firmware release.
So next release will have a setting to disable it all together?
wireless wheel torque off when disconnecting a wheel will be removed, and wireless wheel idle timeout re-enable torque button will be fixed.
If it’s networking issues that are causing these, could that cause wheel forces to get strange at the same time?
Either way, since it happened on 0.11.2 I a going to go back to the latest version.
Can I update directly from 0.11.2 or do I still need to go to 0.54 first?
If you have a version you are about to release, I may as well wait until you post it.
UPDATE:
I spent some hours ensuring all my grounding was in place (not that it shouldn’t have been), and then spent more hours in a test session with the same car at the same track.
It can take 30 minutes, or less but it will happen every time.
The wheel is literally losing connection for whatever reason, can be seen in a replay where the wheel of the car (not the actual wheel) will literally stop turning for a split second and this pretty much creates a wreck as when I turn the actual wheel during this disconnect it catches up in an instant and the car is toast.
Hope this makes sense and hope you might have some ideas, or ways I can troubleshoot to see if there’s an actual problem with the SC hardware.
Appreciate your help here as this problem effectively makes my SC useless as I can’t trust it in a race.
UPDATE#2:
I just realized that when I did my fresh install of the current Win 10, I never installed the DFuse demo or had to find drivers for the FTDI USB Serial Convertor or any of the COM ports.
Should I run the DFuse installer or is this not necessary?
I’m trying to cover all angles here and USB/ports could very well be the cause.
This box ‘Load VCP’ was checked and whilst I do not really know what this is about, a quick search revealed that it should only be checked if the user is having trouble finding the correct ‘ports’ listed in device manager.
I unchecked it and it didn’t seem to impact the wheel, but I have not tested it yet to see if it does the same thing after a while of driving.
Do I need to leave this checked?
Simucube - when in use - is visible as a USB Human Interface Device, not a serial port.
Such settings of a serial port do not matter.
Should it say ‘Simucube’ in this area of device manager? Or will it just be one of the many ‘USB Input device’ entries?
Sorry Mika, it’s been years since I even had to look at this stuff.
I found that many of these had this check mark, even though I recall removing them all.
Could this be causing the issue? Some Windows power saving horsecrap even though I have all power saving disabled at the BIOS level?
Yes, Windows does its own USB device things, it doesn’t care about Bios settings.
Disable all those checkboxes and also disable the USB Selective Suspend in your advanced power options.
Simucube is one of those USB Input Devices.
1 Like
Thanks Mika!
Hopefully this was a simple fix - I keep forgetting that when Windows installs updates it often checks all these boxes again.
Off to sleep and will try in 4-5 hours.
Do you have a new FW version to test or is it pretty much just going to be a release?
Thank you!
Mika, most of the time it is a similar amount of degrees out, usually around 10-15 degrees. I tried the Desktop centering spring. No the centering spring worked as its supposed to and did go to 0%. This had no bearing on the recalibrate issue as i tried it with and without. Hope this helps. Running a large MiGe with Heidenhain sincos encoder.
Yeah, there is a code that puts the center offset and the centering spring strength to 0 and 0% respectively, and I wonder whether that is triggering for some reason when the device starts.
There is no version to test, and likely the next release will be straight to public.
My recentering issue was 10-15 deg off with the new firm, I went back to 54, no issues since. Also experienced connection issues, USB dropping the signal.
How long were these drops? Like a fraction of a second where you can’t turn the wheel?
I was having these too but figured it was a Win 10 USB power management issue.
I’m going to test more today, and if the problem persists, will try 0.54 again.
No mine dropped out and it was permanent, you would get the USB disconnected windows chimes… then lifeless wheel.
and you are still good with 0.54?
That’s interesting as I thought the general consensus was that 0.54 was the more problematic FW than 0.11.2
I was on 0.54 for the longest time without issue - that said I do not think my issues are related to SC FW this time, something going on with Windows or perhaps EMI from my new motion rig (which I have grounded in an overkill way so not almost positive it’s not that).
Im on 54c, it is back to business as usual, no indexing errors, no drops… no issues.
I too have motion and a bunch of other usb stuff, I recently put a pcie usb card in as i got sick of usb related issues, had it about 2-3 weeks without incident, had a problematic upgrade to latest, then issues so rotated back and been fine ever since.
sounds like me! servo actuators for motion, startech PCIe USB 3.0 card with dedicated controller for each port (4) and everything has been good.
If I see the issues again I will try 0.54.
Thanks.
Issues with rare communication error at device start is fixed.
Issue where the centering might go wrong on device start is found, and is being fixed.
4 Likes
It is fixed now. However, the [CEN] Require Software Enable must be turned on in the servo drive settings. Simucube firmware will automatically do it before saving settings to flash, thus all outdated DRC files can still be used as the parameter will be automatically changed to servo drive.