Hello granite devices community!
I am facing some problems with my simucube. I have simucube 1, ioni pro hc (25a), MiGe 130st-m10010.
How is it behaving:
At first I was getting a lot of SMbus errors - it was pretty random so to say. Some times there were no errors for the first few minutes, then when the first one occurs the SMbus error count kept increasing constantly sometimes getting to 40-50 errors for 1 minute.
I thought it may be a grounding issue, so I did proper grounding procedure as follows:
I have my power outlet properly grounded. Then I have the controller of my wheel rim ground pin connected with a cable to the quick release. Then I havea wire running from one of the mounting points of the MiGe motor to the CoolerMaster case of the simucube - attached to one of the screws under the case that holds the PSU. It then goes to the PC case. I also have a ground wire to my pedals running to the same mounting point of the MiGe motor.
I did this just in case, but the behavior did not change. I have the same disconnection issues and SMbus error count keeps increasing. I tried to reinstall the simucube firmware and the ioni firmware. I did it by moving the dip switch to dfu mode and installing simucube firmware v1.0.40, Simucube Configuration Tool v. 1.0.39 with DeFuseDemo. I then proceed with reverting the dip switch to normal position and power off/power on the simucube. When I start the Simucube Configuration Tool it detects the wheel is not configured so it starts the configuration wizard. I go through the process and everything works fine so far. I then upload a drc file, or do the settings manually in Granity. The weird part is that I upgraded the ioni firmware to 1.7.21 but I noticed that after initially simucube configuration tool detects the ioni firmware as 1.7.21 after a few hours of usage it goes back to 1.7.20 - Is this normal ?
I am currently at work while I write this, so I am not able to provide screenshots from Config Tool or Granity, but I will upload as soon as I get home.
I have tried using different usb cables, different usb ports to no success. I then ordered a powered usb hub.
Here is the interesting part - with the powered usb hub the errors are very rare, but they still occur.
I also followed some suggestions to turn off xHCI in bios usb configuration, also set usb selective suspend to disabled in windows settings, I removed the ticks from “Allow the computer to turn off device to save power” (I may be quoting this wrong, but you know what I am talking about) in device manager.
Would you guys please help me solve the issues I am facing ? I don’t know what else to do. I really need your expertise on the subject.
Best Regards,
Rosen
I think it might be some sort of a ground loop issue, and the fact that you make the grounding worse at some point (probably at the USB hub) makes it behave better.
What steps should I take in order to prevent a ground loop ? Should I try and remove grounding step by step and see if it improves? I am looking at usb isolators right now. By the way what do you mean by:
Do you mean, that by not grounding the usb hub the negative effect of the ground loops is less noticeable on the usb hub, therefore more stable usb connection ?
The USB hub is the only one that is not grounded except through its power adapter.
Forgot to mention that both X3 and X4 usb cables going to simucube have ferrite beads near the mini usb b ends where they go in the simucube.
Ok, I’ve been reading about ground loops… Please let me know if I get things right!
I have grounded a 6 socket power strip and I have 5 power cables going to 3 monitors, pc and simucube.
As far as I understand ground loop occurs when you have multiple paths to ground. I guess I did just that. Am I right to think that I need to ground only one of the power cables - for example the power cable of the PC and then have a ground wire running between all devices (Motor, pedals, simucube case) to the PC so they all get their ground THROUGH the PC grounded power cable ?
Most likely you should leave all PC peripherals in grounded outlets. It is just that the extra ground paths between your servo motor and the PC cause issues. There is already ground in the servo motor power cable, then there is ground via USB of your wheel, there is ground between USB on the PC and the ground on the Simucube, and then your extra ground. And, also there might be additional ground paths on your rig, through pedals for example.
I will try all that tommorrow.
One more question for now - I saw a picture somewhere while researching all that information where someone had a ground wire running from simucube ground terminal to sdr-480 psu surface - is that a good practice and should I do it to as I believe I now have only +48v and -48v connected to the simucube board terminals?
@porosenoq: SDR480 48VDC GND is already connected to the psu chassis ground, so it is not necessary to do as you have asked.
Edit: Mmm, I have just checked on my SDR960, chassis is not connected to DC GND. Anyway, on Simucube 2, you can connect GND signal from terminal to psu chassis gnd. But because I was using aluminium enclosures, I always only made sure psa chassis was properly grounded, and +/- signals from psu to Simucube were connected.
Other parts of the simucube2 board connected it back directly to the aluminium enclosure, for example, the encoder 15-pin d-sub shell, which contacted my bare aluminium chassis….
Ok, guys. Significant improvement after removing all the ground wires going between motor, simucube case and PC case. Still getting some errors though. I was able to do a 30 minute race for test purposes and I felt I lost FFB for fractions of the second. Not a full disconnect/initialization like before where the wheel got completely lost and then went for the initialization procedure going left and right before it was functional again.
Here is a pastebin of the log I got with 4 errors:
What other things can I do in order to fully eliminate the possibility of a disconnection ?
Also I would like you guys to share best practices for running the motor cables to the case. Should they be close together, further apart from eachother as possible, straight, coiled (guess it is very bad idea), also usb cables, power supply cable ?
And my question regarding the IONI board automatically getting downgraded from 1.7.21 to 1.7.20 did not get answered and I wonder if this is normal or something I should be concerned about ?
I have put a wire between PSU chassis and simucube 2nd gnd terminal where V+ and V- go by the way.
Yes, there indeed seems to be only 4 baudrate resets now.
I would like a few pictures on how things are grounded - are your power cables crossing your USB cables, for example. And similar things also for the e-stop cabling.
Then it would be useful to know if your mains AC outlets are indeed properly grounded to protective earth, or just GND.
Well, I am not exactly sure which is the correct term, but I have a cable going to a metal bar that is going from the roof of the building I live in to the ground and it goes a few meters deep I believe. I hooked directly to that as the building has only 2 wire electric installation. The metal bar I am talking about is a dedicated grounding solution for a mobile antenna on the roof of the building. It is very well made I think.
As for the cabling - I am trying my best not to have crossing cables especially usb cables and power cables.
Unfortunately after what seemed like a better situation this morning it seems it is again pretty random because at some point I got 19 errors in a few seconds and a few reinitializations of the wheel and I can’t tell what provoked them as I was browsing the community and had no game running so no FFB signal coming to the simucube. It is so random…
I was reffering to the fact that with wood you are isolating pretty much everything attached to the wood. I wondered if you need any additional steps in grounding or anything so that whatever is attached to the rig is not affected somehow.
I am so puzzled. Today I decided to redo all the cabling so no power cables cross Usb cables etc. Plugged everything back on and it is the worst its ever been with an error almost immidiately coming up after initialization and then endlessly rising up with amazing frequency… No idea.
Hello,
Sorry to post under my own posts, but I’ve been reading a lot in the wiki and the community and some questions arise.
Is it possible that ferrite cores that I have on my cables are causing issues if they are not of the proper type?
Also I still want to know if IONI Firmware automatically downgrading from 1.7.21 to 1.7.20 is normal or not?
IONI firmware release 1.7.21 has not been tested by us for Simucube use, and the bug that was fixed does not affect use in Simucube use. However, if the reading of the firmware version number fails (communications hickup at that moment) then I think the Simucube firmware will update it which causes the downgrade.
Hello again,
It is almost a month of constant testing and experimenting. Yesterday I tried to shield my cables - no change, same issues. I tried to use different computers - I dismounted everything from my rig and went into an empty room. I layed down the MiGe motor in one end of the room used all the cables length to get the motor as far away from the simucube board as possible. I then used all the length of the usb cables to place a laptop as far away from the motor and simucube/ioni as possible. There were no cables crossing or anything. Same issues.
I was desperate at the time and did not know what to do. I decided to try MMosFFB 2014 - I had some difficulties setting everything up but VOILA - it is working perfectly, no disconnects, no issues, strong ffb - everything is fine…
While this is very good for me because I can finally use my wheel - I wonder what is causing this ?
It is obviously not a hardware/cable/port issue. It is not EMI/grounding/ground loop - it is software/firmware related.
Can you guys help me investigate further because I’d like to use the more advanced and feature rich simucube firmware?
What could cause MMos to work, but simucube not to ?
MMOS does not communicate with the IONI servo drive in any digital way. It just gives a simple direction and PWM (pulse width modulation) signal with completely separate pins, and those signals are much less accurate but also much less sensitive to signal errors than the digital 4.5 Mbps digital serial communications bus that Simucube firmware uses for communications.
And its the digital signaling that is affected with issues here, and so far all cases have been EMI or ground loop related. However the signaling is controlled by chrystal oscillators on both the Simucube processor and the servo drive processor, and it is not completely out of the question that aging components could cause drift in the clock rates that could start to cause issues. But this would be the very first time we’ve seen this.