Jump to content
xantari

How to limit knocker usage in certain tables?

Recommended Posts

If you didn't change anything I'm wondering if the logging code is running on the same thread that sends the events to the file system.

If so, it may be that you are slowing the sending of the updates to the pacled64 just enough to remove the issue.

If that theory is correct, there may be some issue with sending the pacled64 events too fast. Or, you are sending multiple events at the same time to the pacled64 on different threads and the controller is getting confused and can't keep up fast enough.

Just a thought...

What might exhibit the issue and still maintain logging is to ensure that we use something like the serilog logging approach so that all logging happens on a different thread so it doesn't cause any blocking of the existing DOF worker threads.

Share this post


Link to post
Share on other sites

There are really no changes apart from the logging. I did not even fix a small bug in the code that I found by mistake (nothing grave and very easy to fix).

The logging code is not running in the same thread. There is a thread which only does the Pacled updates. When a update is sent to the pacled, the same data is also put in a queue for logging. In addition there is a timer firing every 5 seconds which empties the queue and writes the data to the file. The timer is a normal System.Timer object which means (if I'm not mistaken) that the elapsed event will run in a separate thread. Like that the impact on the thread sending the data to the pacled should be minimal and even if it has a impact that would only happen every 5 seconds or so.

If you want to check the logging code, I'll be happy to post it.

It seems that the problem we're trying to find is something which is influenced by the timing or frequency of updates and maybe also by the involved hardware (e.g. USB controller of your main board). This is probably also the reason why I never have these issues and other users experience them all the time.

@xantari

Just for curiosity, did you ever try to connect your pacled64 to another usb port or to put a usb hub between the pacled64 and the mainboard. I wonder if this has a effect.

 

Share this post


Link to post
Share on other sites

I have not tried plugging it into another port or try a USB hub. I will try that tonight.

What is interesting is the logging code must have slowed it down just enough to fix the problem. So something in R2 must be doing the same thing (slowing it down just enough).

I'm also going to try several more test runs of the table (I only did one run), to see if it is always fixed, or if the symptoms periodically come back.

If you post a branch to github, or .zip up the file i'd be interested in taking a look this weekend.

In regards to System.Timer object, I'm not sure. I tried reading the documentation on it, and it's a bit confusing, but appears that it does run on a different thread. http://stackoverflow.com/questions/7893773/do-system-timers-timer-run-in-independent-threads

 

Share this post


Link to post
Share on other sites

I have an ASrock Extreme4 (Intel Z170 chipset board). All Z170 chipset USB ports have this effect.

When I plugged it into the USB 3.1 port (ASMedia ASM1142) the problem went away. But then DOF Feedback was noticeably delayed.

I also tried different USB BIOS settings, and also play around with the power management functions in windows, but no change.

So it seems this is USB hardware related.

I purchased 4 different 4-port USB hubs to try (a mix of 2.0 and 3.0 hubs). 

If that doesn't work, I'll start looking for USB PCI-Express addon cards to try.

Share this post


Link to post
Share on other sites
2 hours ago, xantari said:

But then DOF Feedback was noticeably delayed.

This is surprising. Driver issue?

2 hours ago, xantari said:

So it seems this is USB hardware related.

It seems to be some issue wich is influenced by more than one of several factors.: DOF and its timing of sending updates, USB driver, USB hardware, output controller hardware and firmware. The only thing I can influence is DOF.

I'll add some extra config option the the for the PacLed64 output controller class, which allows to specify a minimum intervall between updates. If the timing is influencing the issue that could probably help. In most cases that extra delay will not have a effect, since the time between the updates is long enough anyway. Only if there are a lot of updates in a short time the extra delay would have a effect, but if that delay is small enough it will be hardly noticeable.

Share this post


Link to post
Share on other sites

I don't suspect driver (although it could be), because I didn't have to install any, and there are no specific drivers for the Intel Z170 series from what I can tell when running Windows 10. It just downloads some Microsoft USB host controller driver.

I'm guessing if I went back to Windows 7, where i would have to install USB drivers that maybe things might be different. But that would take a bit of time to test out. I'll buy a new SSD and try that out in the coming weeks so I can swap my environment back and forth between windows 7 and windows 10 to see what type of effect that has.

Is the new build with the delay setting published anywhere? What is the new global b2s config file property?

Share this post


Link to post
Share on other sites

BTW, when I did my test with the different USB ports, I did go back to the 5818 build of R3, which I believe was from Nov 2015, which is what I was using when I started this thread.

Share this post


Link to post
Share on other sites
3 minutes ago, swisslizard said:

Working on it right now.

Thanks! Will this setting be different from this setting:  LedWizDefaultMinCommandIntervalMs

I tried that, and that behaves a bit differently than I expected. Putting large values there misses lots of events.

Share this post


Link to post
Share on other sites

Was glad to find this thread, I have been wasting weeks trying to get this to go also, and still haven't fixed it. I am using a Gigabyte z170/i5/16gig ram/Win10, I have tried the USB3 and USB 2 ports and both have bad problems. DOFR2 works fine though.

I see the last post was Nov23rd 2016, has anyone made any progress on this ? I would prefer to get a proper fix rather than buying random USB hubs to test out

Share this post


Link to post
Share on other sites
Was glad to find this thread, I have been wasting weeks trying to get this to go also, and still haven't fixed it. I am using a Gigabyte z170/i5/16gig ram/Win10, I have tried the USB3 and USB 2 ports and both have bad problems. DOFR2 works fine though.

I see the last post was Nov23rd 2016, has anyone made any progress on this ? I would prefer to get a proper fix rather than buying random USB hubs to test out



The fix I implemented was to purchase amazon basics USB 2.0 controller. I only had USB 3.0 ports. Fix is only 7 bucks: AmazonBasics 4-Port USB 2.0 Ultra-Mini Hub https://www.amazon.com/dp/B003M0NURK/ref=cm_sw_r_cp_api_aulKybJZ4EEQ2

A software delay parameter has also been added for pacled64 devices, but I haven't tried it yet since I solved the problem with the USB 2.0 4 port hub.

Also specify what issues you are specifically having as it is unclear in your post.

Share this post


Link to post
Share on other sites

I had a thread on the competing  pinball site :/ Arngrim was suggesting testing methods to help me

Basically, when I install R3 I get crazy stuff happening, random outputs firing for no reason. Even when they are not configured in Dof config tool, when I configure flippers only replay knocker, gear motor, shaker, solenoids randomly fire. At first I thought I did something wrong and worked on it for the last 2 weeks driving my-self mad in the process.

DOFR2 has been working perfectly for the last year or so, so I couldn't understand what was happening until I read this thread.

Also what software delay do you suggest trying ? I will try the USB hub method also and post results, I live in Australia so I probably wont  get the Amazon, will try some other cheap piece of shit hub.

Cant test atm, my wife and 4 kids are asleep :)

Share this post


Link to post
Share on other sites

I took your advice, and got a cheap USB hub, cheapest nastiest piece of shit USB 2.0 hub I could lay my hands on. Plugged into the USB port, plugged pacled64 into shit hub and presto, working well. Doflinx working, Future Pinball looks fantastic. I got the Zebs all in one board.

It really makes no sense why R2 works properly, and R3 wont

Again, massive thanks to you and this thread, great to find info like this when really need it.

dofconfig.png

Share this post


Link to post
Share on other sites
I took your advice, and got a cheap USB hub, cheapest nastiest piece of shit USB 2.0 hub I could lay my hands on. Plugged into the USB port, plugged pacled64 into shit hub and presto, working well. Doflinx working, Future Pinball looks fantastic. I got the Zebs all in one board.

It really makes no sense why R2 works properly, and R3 wont

Again, massive thanks to you and this thread, great to find info like this when really need it.

dofconfig.png



I believe the main difference between R2 and R3 was the speed at which commands could be sent. R3 being faster. That combined with the speed of some USB traffic would cause events to arrive to fast. Sort of a strobing effect, at least that is the theory. Those normally wouldn't get picked up in R2 but now R3 is more sensitive.

We are basically slowing things down by introducing the USB hub. Don't get a 3.0 hub though, probably too fast again and would result in random things firing.

Share this post


Link to post
Share on other sites

@xantari

Or anyone else in the know, was there ever a newer version released that slows down the USB transfer speed?  I have zebs complete setup as well and just experienced the same issue, however I had version R3 running perfectly on Windows 7.  Now this past weekend I installed Windows 10 and this problem started up for me.  The only difference in setup is the Windows OS, which would mean Windows 10 is just too efficient.

Also thanks for this topic, I thought I was doing something majorly wrong till now

Share this post


Link to post
Share on other sites

There is a newer build that adds a delay to the pacled64 devices. It would be nice to know if the delay setting works for you as I ended up not having time to try it without my USB hub option.

Here is the documentation on where to put the delay settings: http://pinball.weilenmann.net/docu/DirectOutputWIP/outputcontrollers_builtin.html#use_DirectOutput_Cab_Out_Pac_PacLed64

MinUpdateIntervalMs is the value.

Here is a link to this build: https://drive.google.com/open?id=0B__g7EhWQEETZDA5TjdWQjg0NVU

 

Share this post


Link to post
Share on other sites
On 2/26/2017 at 11:18 AM, xantari said:

There is a newer build that adds a delay to the pacled64 devices. It would be nice to know if the delay setting works for you as I ended up not having time to try it without my USB hub option.

Here is the documentation on where to put the delay settings: http://pinball.weilenmann.net/docu/DirectOutputWIP/outputcontrollers_builtin.html#use_DirectOutput_Cab_Out_Pac_PacLed64

MinUpdateIntervalMs is the value.

Here is a link to this build: https://drive.google.com/open?id=0B__g7EhWQEETZDA5TjdWQjg0NVU

 

I was having this same issue.....the link to this build completely fixed the problem.  This is ideal since my motherboard doesnt have usb 2.0 ports

Share this post


Link to post
Share on other sites

@swisslizard Could you update master or add a branch to your github repository that contains the MinUpdateIntervalMs and other updates that were made while diagnosing this issue? It appears to be beneficial for some folks. Thanks man!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×