I was one of the lucky guys to receive a SC2 sport out of the first batch.
Unfortunately i have an issue i can’t solve.
Every now and then the wheel seems to "slip" when FFB is applied (e.g. during long, fast corners). It is not a mechanical slip of the QR on the motor axis but a turning of the motor itself. This turning is not recognized by the simucube software and therefore the wheel center is off afterwards.
This happens during driving, but it also happened while the Game (in this case pcars2) was only running in the background.
When reaching the steering lock there is only a very little resistance of the motor and i can keep on turning the wheel. Sometimes you can year a high buzzing sound of the motor.
It almost sounds and feels like a failsave that is releasing the ffb strength. One or two clicks through different programs and then ffb is back to normal, no change in settings needed (but center is still off).
Hand off detection is on mid, temperatures are low (can’t feel any warming up of the housing), high torque mode is on, torque set to 60% and firmware is up to date. Log file does not show any errors or warnings.
I currently only have pcars2 running but will test other games within the next days.
A Video that shows the problem: https://youtu.be/zoSy7sFVCaM (while pcars runs in background, simucube software is active task)
Anybody here who has/had the same issue or knows how to solve this situation?
I had something like that when the clamp shaft on my Reimer OSW wasn’t tightened properly, I’m not sure how you can check that on the SC2.
It is in fact hard to see. But all bolts are properly tightened and by the sound of the motor and the feel to it, i am 99,8% sure it is not a slipping between shaft and Quick release but really the Motor turning.
Also the fact that once the problem appears i can solve it by closing and opening the game makes me believe it is a software/user issue and not a mechanical problem.
But good advice anyways, thanks
@EmoJack Could you see if the encoder is tightened properly into the shaft ?
We strongly advice to NOT touch the encoder. Such stuff is not user serviceable in Simucube 2 and will void warranty for sure. Also it would require a remote session to recalibrate the motor after that.
Most likely the QR is mechanically slipping. The screws are behind the front plate on the QR and could be checked and tightened.
@Mika can you give me a torque value for a correct tightening of the QR bolts?
Also does it make sense to have some locktite on the shaft?
I will try tonight and give feedback if I maybe was wrong and it IS the QR not being properly fixed.
Locktite on the shaft should not be needed. I heard that the correct torque is 5 Nm. I have no idea how tight that would be. If you have a torque wrench, you can check it out.
5NM is like hand tight with an allen key. wont be enough but make sure the shaft of the motor is clean, degrease it.
My smallest torque wrench starts at 13Nm. But it felt quite loose when i took the clamp of. And there is quite a layer of oil on the shaft. There are no lateral scratch marks on the shaft, but that might be due to the oil film.
So after degreasind it a bit - just wiped the oil of, no degreaser used - and tightening the bolts “a bit more than hand tight” (so with settings on 13Nm and not tightening until it clicks) i reassembled it.
First test was good, but i have to wait a few days before i have time for an extended test session.
I really didnt expect that to be the reason, but maybe it was just at the edge of slipping and therefor only slipped sometimes and not every time i turned it.
If it still happens i will take it off again and fully degrease clamp and shaft.
Will keep you postet if the problem is solved.
Thanks for the help for now
With the drive lock on the Mige and AKM motors we always cleaned all oil from the motor shaft and drive lock. I personally used alcohol on a paper towel.
Then tighten it as tight as possible with a normal hex key. I did this even on the HRS CNC hubs. Not sure if the SC2 hubs are made of the same alloy?
The spec sheet rated the holding force of the drive lock around 40% higher with oil cleaned from the surfaces. Since we are not using them in a hostile environment oil free is the best.
The tightening torque for the 24x50 and 22x47 (mige) Drivelock bushes we use is 17Nm
thanks. It appears that the 5 Nm was not correct answer as per our product assembly manual. We shall add more torque and verify that degreasing step is there. It should be, but maybe it has been missed in manufacturing.
Yes I think that will save you many headaches.
I would guess that 99% of the complaints from all OSW complaint that “wheel losing center” ended up being loose drive lock.
The other 1% was loose or bad encoder.
We are sorry for this inconvenience! This is simply human error in assembly, but we need to inspect and improve this aspect of the assembly process with our partner so that such does not happen again. The below one is the used shaft clamp model. You can tighten the screws upto 17Nm, but that amount is not necessary as such amount of tightening allows the shaft clamp to transfer torque upto 290Nm. Around 5Nm - 10Nm is enough in this application. 10Nm is about 1kg with 1m torque arm and 10kg from 10cm torque arm if you do not use your torque wrench but just estimate the tightness.
If you have now tightened the bolts to 13Nm, that should be plenty more than enough.
Tommi, is this something you are advising all new users to do before use, or only those that experience the slipping issue?
I received my Pro today but am waiting for some shorter bolts to arrive for the sqr so I won’t be using it until at least this weekend.
No, tightening these screws is not standard procedure for the end-user. Currently I don’t quite understand how this is possible, because all the units are tested with production tester before packaging. The products will simply not work if they do not pass the test. The tester does test the max torque and several values of the product and store the data to our database. This sort of shaft slipping should be noticeable during the test and fail the test, if the product fails the test it is not packed until the issue is corrected and the unit tested again and passed the test.
Thanks for the information, Tommi.
It does seem to be an isolated issue at the moment so I will leave things exactly as they are.
@Mika @Tommi no inconvenience at all! if i wasnt happy to help improving the product at this eary stage, i would have not bought a prerelease product.
Thats just what you get when you are an early adopter: you are one of the first ones to experience the product but at the same time have to be willing to identify issues that have not happened in testing before.
So with this easy fix i see no problem at all.