I dont think so, its a problem of physics… Any servo has its power/peak whatever you name it, if you send a 100% force to the servo, its amplifyed by the rim like a lever, so the servo isnt capable to reproduce that extra forces to act like a bumpstop
Mechanical bumpstops are meant for this purpose
EDIT:
Example, on iRacing with its software bumpstops, you can feel how they act the same, like a spring that can be overpassed and then the forces bounce back and forth. SC2 does the same but cuts off power at certain degrees over maximun rotation
This has got me thinking that I should change my bumpstop settings to try and mitigate any possible problems. I don’t remember ever changing them but I just took a look and seem to be set very low.
Try it!
I like zero deadzone bumpstops, so when i reach max rotation i dont feel any damping, only the bumpstop. The wheel is smooth all the way down to the max rotation.
Try yours at Overview tab
@EsxPaul For me, is more important to play with Profile Steering Range & Bumpstop Range
MIka, is SC2 bumpstop implementation different from MMOs/Argon?
I don’t remember ever going over bumpstop with OSW but it did happen with SC2 few times already after wall/collision crashes, in R3E and in PCars2.
Also in TD Interface during “TorqueOff, collecting metrics” event wheel goes past bumpstop and getting stuck there.
I do not know how MMOS implemented its bumpstop. However, early in Simucube firmware development we decided to experiment with setting up the overall strength via the maximum motor current parameter on the servo drive, instead of scaling the signal into the drive.
Unexpectedly, this caused better FFB feel (or so people reported), and it has stayed that way since.
The MMC parameter cannot be adjusted on the fly, because user would feel a notch while the system calculates many feedback loop gains and other parameters when doing that. Thats why the bumpstop does not feel “strong” in Simucube at the moment.
It would be possible to change this, but then people would complain about the changes in the FFB feel, or that we “do not give the option to have the old way”, so I’m still thinking on what to do. Maybe I will focus on the detection of the stuck torque as it would be required anyway to implement ultimately safe behavior.
If it is worth anything or not, I don’t know, but here my POV: Last time I had an issue with cable wrapping, was in 2014 during early Argon testing.
Also, I have never used bump stops on Simucube, ever. Admittedly, I only race in iRacing. At the torque-levels most people are using, I am not sure why you let go of the wheel in any case during a crash. Perhaps watching to much of those hysterical boob-tubers, most who seems to really dramatise stuff simply for effect and clicks.
This should not even be part of a discussion, tbh. But that’s just me. For the record, I am using much higher torque than 99% + of people, it is very seldom I ever let go of the wheel, not sure how many years ago I last used the e-stop. Been in DD wheel development for 6 years now, never had any serious injury. The worst was the old Argon spinning and the USB cable wacking me across my legs.
Thanks Mika.
Guess I am starting to understand the root of the problem. With Argon we had MMC at max motor capacity and tuned overall strength in MMOs, which still allowed bumpstop to operate at max amperage/strength as it was independent.
Yeah, seems like not an easy one to solve unless you add control of the FFB signal strength in TD and run MMC at motor max.
In early OSW days I have done lots of testing comparing effect on FFB dialing down MMC vs MMOs Max Force. To me result was always the same or virtually indistinguishable.
Guess at least for now, if I understand the problem correctly, the solution is to run TD Overall Strength at 100% and control gain via in game FFB settings (if it has one). This way bumpstop can be at max motor amperage.
And for bumpstop, set maximum strength to 100% and add some damping to prevent bounce back when hitting the stop. Something along these lines. It won’t be soft, if you used to that, but at least safe.
Andrew, those are the type of numbers I was thinking of using when I posted my questions and current settings earlier on.
I don’t care what effects they have whilst driving because I never get anywhere near using them. I would just like to have something in place that might minimise damage if something unexpected were to happen.
Thanks for confirming the default numbers. I don’t remember altering mine but looking at the numbers, I must have at some point and am too old to remember
It could be me changing mine at some point as well. The User Guide shows 20% for instance.
Guess it should be locked at 100% and softness simulated via other means, ramp angle, damping, etc.
I’m not sure I fully understand what you are saying, but you should not be able to overpass the bumpstop so the servo is not longer trying to stop movement in that direction. The bumpstop shouldn’t be a torque peak after which there is no torque applied. As the wheel approaches the bump stop the torque signal from the game should be reduced and the bumpstop torque increased. If this is done then when the bumpstop position is exceeded there will be a returning torque that will always defeat the inertia and return to the point at which the bumpstop and game torque balance out.
Using the full motor current would be nice but not essential. The problem I’ve had is not when the game has crashed but when the bumpstop has been defeated and the wheel continues to spin using power. This could be solved by reducing the game signal when approaching the bumpstop whilst increasing the bumpstop torque, and keeping the bumpstop torque applied even if the wheel passes the bumpstop. The wheel will always return to the bumpstop position in this case even if the game is sending a max torque signal.
