480 replies to this topic

[mjr]

I don't know what's going on with DOF + Admin mode, but of course my baseline advice is always the same regarding Admin mode:  Just Don't Do It.  If you can focus first on getting rid of all of those Admin mode processes, things will work much better across the board.

 

> [themaxx2k]

> padder must be run as admin, else no keypresses in PinUpMenu (strange?!)

 

It's actually not strange.  It's an intentional security feature in Windows, and it's just the sort of reason you should stop running everything in Admin mode.  You don't get key presses because Windows by design sets up firewalls between Admin mode processes and everything else.  One of those firewalls is that non-elevated processes can't intercept the keyboard when an elevated process has focus, because Windows doesn't want key loggers to be able to grab system passwords and other potentially sensitive keyboard input.

 

> [NailBuster]

> some fixes reported by users:

> remove DOF entries in registry and re-run registercomobject.exe as admin.  (doesn't work for all)

 

Actually, you *always* have to run RegisterComObject in Admin mode, because it updates protected system keys. 

 

I think whoever came up with this advice must be imagining that running RegisterComObject in Admin mode somehow sprinkles magic Admin Mode Dust over the keys it updates.  It doesn't.  Running the registration in Admin mode simply allows the registration to happen at all.

 

 

Here's a wild guess:

 

Are the people who are having the DOF + Admin mode problem running with UAC turned off?

 

If so, that might be the whole issue.  Turning off UAC prevents Windows from being able to elevate processes in certain cases.  You might be *thinking* that you're running RegisterComObject in Admin mode, but not *actually* running in Admin mode, because of the absence of UAC.  Everyone thinks that turning off UAC just shuts off some prompts, but it actually shuts down the whole system service that allows the desktop shell to elevate selected processes.

[Aetios]

 

Hi guys,

 

thx to @mjr and @DJRobX for this update. 

 

Could it be possible to modify TeensyStripController.cs from the code source to integrate the compatibility with the WEMOS D1 Mini Pro which actually can do the same work as the Teensy for our Virtual Pinball.

 

Here is the modded code :et + ByteNumber] = ReadBuffer[0];

This modification would be really appreciate because for the moment we have to modify your code at each update.

 

Thx a lot,

 

Byebye

 

IMO,  these code changes shouldn't be applied to the working Teensy working class.  What i did is just create a new class called WeMosStripController with the needed changes.  Keeps it separate and allows some better fine tuning with the esp8266 interface code without messing with the teensycontroller driver.

 

I can send the PR if you want....but i just did the changes now, so I'll be testing it a bit to get those sleep times a bit lower.

 

 

These changes had been added or not ? 

 

If you need somebody to test it, I'm your guy !

[mjr]

These changes [wemos strip controller] had been added or not ? 

 

From the github history, it looks like the answer is no.  Looking back through the thread, it looks like there were some unsettled questions about exactly what to implement, and it looks like we left it with nailbuster having a preliminary version that he needed to test further before submitting a pull request.  If someone wants to go back and find the code and submit a pull request, I'd be happy to look at merging it.  From reading back through the thread, I'd say the thing to do would be to go with the "separate device" approach so that it doesn't break things for people using the regular teensy setup.

[Totaltimo]

Hi and sorry for pulling this back up to surface, but:

Has there already been a solution for DOFslave.exe crashing after ProPinball starts? Anyone with a working version of DOFslave.exe here? 

 

Thansk and cheers

Timo

[wrd1972]

 

i haven't checked any logs as i never knew there was any, i think what the problem is the contractors are taking too long to release after they have fired because i can see them staying on meaning that they are not ready in time to fire again when the next bumper/target etc is hit but i know nothing about any of this so im just really guessing 

 

That's plausible.  DOF is faster than the legacy interfaces because it doesn't block the client program on USB I/O.  Contactors definitely have a relatively long minimum cycle time because of the physical motion involved.  If you want to test this idea, you could temporarily replace your contactors with LEDs and see if they suffer from the same problem.  LEDs can respond pretty much instantaneously (at least on the time scales we're talking about here), so if they show the same laggy behavior, it would rule out the contactors as the issue.

 

I just ran across this and I agree there are lags or maybe better called "voids" with contactors/solenoids firing such as in a cluster of pop-bumpers. Its like the firing functions just cant keep up and cant return to a ready state quite fast enough. I can even manually drive a ball against a bumpper very rapidly, and the "feedback" cant keep up. Any possible solution to this in the future?

[Outhere]

What type of hardware are you using

Edited by Outhere, 27 August 2019 - 05:15 AM.

[mjr]

Has there already been a solution for DOFslave.exe crashing after ProPinball starts? Anyone with a working version of DOFslave.exe here? 

 

You're trying with the latest?  If so, then I'm afraid the answer is no.  (That part of the project isn't something I've ever worked on, and I kind of assume it's dead since it hasn't been updated in forever.  The source code is there if you want to take it over.)

 

 

i haven't checked any logs as i never knew there was any, i think what the problem is the contractors are taking too long to release after they have fired because i can see them staying on meaning that they are not ready in time to fire again when the next bumper/target etc is hit but i know nothing about any of this so im just really guessing 

 

That's plausible.  DOF is faster than the legacy interfaces because it doesn't block the client program on USB I/O.  Contactors definitely have a relatively long minimum cycle time because of the physical motion involved.  If you want to test this idea, you could temporarily replace your contactors with LEDs and see if they suffer from the same problem.  LEDs can respond pretty much instantaneously (at least on the time scales we're talking about here), so if they show the same laggy behavior, it would rule out the contactors as the issue.

 

 

I just ran across this and I agree there are lags or maybe better called "voids" with contactors/solenoids firing such as in a cluster of pop-bumpers. Its like the firing functions just cant keep up and cant return to a ready state quite fast enough. I can even manually drive a ball against a bumpper very rapidly, and the "feedback" cant keep up. Any possible solution to this in the future?

 

"Any possible solution to this in the future?" - probably not as a DOF fix, if that's what you mean, since as I was insinuating, I don't think it has anything to do with DOF.  I think it's the response speed of your contactors.  It's beyond my software expertise to change Newton's laws to make those go faster.

 

If you think it really is DOF after all, did you try that LED experiment I suggested, to see if you can see the same effect in devices that aren't physics-bound (or differently physics-bound, anyway)?

[Adeysan]

Greetings.

 

Regarding DOF and lag... I've been noticing some (0.5-1 sec) lag on my contactors firing if there are too many other DOF effects going on.  It's especially noticeable if any of the front buttons are fading on/off or if Undercab Complex is very busy.  I have mostly fixed this with the 'remove front button fade'/Undercab Smart settings in DOF, but the problem returns if a game fades the Launch Ball button.   

 

Is this particularly normal?

 

It's a new setup, so I'm not sure if a hardware or software cockup on my side could be causing this.  I'm using a PinControl 2 board with 10 contactors, gear, shaker, and 3 LED arrays.

 

Cheers!

[mjr]

Regarding DOF and lag... I've been noticing some (0.5-1 sec) lag on my contactors firing if there are too many other DOF effects going on.  It's especially noticeable if any of the front buttons are fading on/off or if Undercab Complex is very busy.  I have mostly fixed this with the 'remove front button fade'/Undercab Smart settings in DOF, but the problem returns if a game fades the Launch Ball button.   

 

Is this particularly normal?

 

That sounds pretty slow.  Given that changing the button fade settings affects it, my guess would be that you've got a USB bottleneck.  A fade translates to a long string of updates to the controller: "set brightness to 254", "set brightness to 253", "set brightness to 252"...  Let's see... yeah, PInControl 2 uses a COM port protocol, and it looks like it has a kind of chatty ASCII interface.  So I think you might have found your solution (get rid of those high-overhead fades).  Unless someone else with a PinControl 2 wants to chime in and say otherwise...

[wrd1972]

"I think it's the response speed of your contractors.  It's beyond my software expertise to change Newton's laws to make those go faster. :)"

 

I am still hesitant to blame the solenoids. If I wire a solenoid to a 12V source, and quickly activate/deactivate it. It will respond as quickly as I can make/break the connection. It seems very fast in terms of its responsiveness. But if I manually drive the ball on a table against a pop-bumper, the sound effect of a hit perfectly corresponds to the ball hitting/un-hitting the bumper. But the DOF response from the solenoid simply does not do that. I might be able to get a single DOF solenoid response, for every three hits of manually tagging the bumper as fast as I can. However the sound effect from a bumper hit stays in perfect sync. Hope that makes some sense.

 

Anyone else maybe notice this. Maybe I have a HW limitation in my cab somewhere.

[Outhere]

What hardware are you using to Control your solenoids

[mjr]

"I think it's the response speed of your contractors.  It's beyond my software expertise to change Newton's laws to make those go faster. :)"

 

I am still hesitant to blame the solenoids. If I wire a solenoid to a 12V source, and quickly activate/deactivate it. It will respond as quickly as I can make/break the connection. It seems very fast in terms of its responsiveness. But if I manually drive the ball on a table against a pop-bumper, the sound effect of a hit perfectly corresponds to the ball hitting/un-hitting the bumper. But the DOF response from the solenoid simply does not do that. I might be able to get a single DOF solenoid response, for every three hits of manually tagging the bumper as fast as I can. However the sound effect from a bumper hit stays in perfect sync. Hope that makes some sense.

 

Anyone else maybe notice this. Maybe I have a HW limitation in my cab somewhere.

 

Really, the LED test I keep suggesting seems like the thing to do here.

[Adeysan]

 

Regarding DOF and lag... I've been noticing some (0.5-1 sec) lag on my contactors firing if there are too many other DOF effects going on.  It's especially noticeable if any of the front buttons are fading on/off or if Undercab Complex is very busy.  I have mostly fixed this with the 'remove front button fade'/Undercab Smart settings in DOF, but the problem returns if a game fades the Launch Ball button.   

 

Is this particularly normal?

 

That sounds pretty slow.  Given that changing the button fade settings affects it, my guess would be that you've got a USB bottleneck.  A fade translates to a long string of updates to the controller: "set brightness to 254", "set brightness to 253", "set brightness to 252"...  Let's see... yeah, PInControl 2 uses a COM port protocol, and it looks like it has a kind of chatty ASCII interface.  So I think you might have found your solution (get rid of those high-overhead fades).  Unless someone else with a PinControl 2 wants to chime in and say otherwise...

 

 

Thanks MJR for the informative, but slightly disappointing reply.  .   I guess the situation is even worse than you describe, as the lights in question are not 'dimmable', so presumably either DOF or the controller have to tell them to constantly flash on and off extremely quickly at any brightness level less than the max.  Still, the PinControl uses ethernet for talking to the toys (I think), so bandwidth there shouldn't really be a problem.  

 

For now, just removing any fade commands from the table configs is keeping everything snappy, but it's a bit of a pain.  Anyone know of a way to do this globally?

[wrd1972]

What hardware are you using to Control your solenoids

Pinscape power board. I noticed the same issue when I was using Sainsmart 8-relay USB boards too. Wonder if its a USB bus speed or driver issue? I am using a very old Dell T3400 workstation with a Core2 Quad. But I have zero performance issue when playing VP.

Edited by wrd1972, 27 August 2019 - 02:59 PM.

[mjr]

I guess the situation is even worse than you describe, as the lights in question are not 'dimmable', so presumably either DOF or the controller have to tell them to constantly flash on and off extremely quickly at any brightness level less than the max.  

 

Right, that's always the case with LEDs.  The rapid flashing is called "PWM" (pulse-width modulation), and it's something the controller does, not the PC.  I can tell you that for sure looking at the DOF code, because it's sending commands to the controller that work in terms of abstract brightness levels, not rapid on/off pulses.  Even if I didn't see it right there in the code, I'd be pretty sure anyway, because the comms channel from the PC wouldn't be fast enough to make that plausible.

 

 

Still, the PinControl uses ethernet for talking to the toys (I think), so bandwidth there shouldn't really be a problem.  

 

Really?  That's odd; the DOF code seems to think it's on a USB COM port.  Maybe I'm missing something.  In any case, it definitely is operating on a virtual COM (serial port) channel, nominally at 115200 bps, which translates to about 10k bytes per second.  It updates ports one at a time, with ASCII commands that look like they'd average around 12 bytes per port, so you could send about 1000 of those per second if you were blasting them flat out.  There's also some overhead (another 12 bytes give or take) per update, which adds anywhere from 15% to 50% overhead (if I'm reading this correctly), so let's say on average it's about 30%, so the max rate goes down to maybe 650 updates per second.  I imagine that, in actual practice, the virtual serial port isn't quite as fast as the nominal baud rate, so we can probably look at 650 updates/second as an estimated upper bound that you won't actually reach.  So if we're pessimistic and say the real throughput is around 300 updates/second, I can see how fade ramps could be saturating that pretty badly - doing a fade ramp on a single RGB device might use up 180 of those 300 updates/s.

 

 

 

 

What hardware are you using to Control your solenoids

 

Pinscape power board. I noticed the same issue when I was using Sainsmart 8-relay USB boards too. Wonder if its a USB bus speed or driver issue? I am using a very old Dell T3400 workstation with a Core2 Quad. But I have zero performance issue when playing VP.

 

Hmm, do you happen to know the USB technology generation?  I wonder if that could be old enough that you have USB 1.1.   That could actually be a bottleneck if so.

 

If you have a free PCI slot, you could try adding in a USB 2.0 card and see if that helps.  (USB 3 won't make it go any faster as the KL25Z's USB hardware is USB 2.0.  Which *should* be upwardly compatible with USB 3, and mostly is, but mbed's crappy KL25Z USB stack has been a source of constant misery on this point, for people using it and for me trying to debug it.  It's mostly compatible at this point, but people still have mysterious problems from time to time that are probably USB 3 compatibility issues.)

[wrd1972]

Okay so my PC does have USB 2.0. But it appears to only be accessible through the 2 front side ports. I will plug the Pinscape into one of those ports and see if the problem is fixed, and respond back.

[pinball1904]

Tried to install that DOF R3+ and I get an error when trying to install C:B2SServerDirectOutputPlugin.dll
Verify that you have access to that directory

[electricmagma]

Hi guys

 

Just painfully read through all of the pages on this thread,  i think i started thinking of Gilligans Island around page 12 - 14,  so if my answer is in that area,  my apologies..

 

I am trying to determine if DOFSlave.exe is actually modified at during these revisions, or if this is Freezies initial version thru it all.

 

Trying to get pro-pinball to work,   the .exe is called, and the DOFLog shows that NO LEDWiz devices are there.   I am using Zeb's stuff that has the modified DLL that you've wonderfully fixed to not need in the unified version.  

 

So, yea,  just trying to figure out if i am on the tight track with DOFSlave having the orginal ledwiz.dll bundled in the executable?

 

Thanks for all of your hard work guys,  

[mjr]

Tried to install that DOF R3+ and I get an error when trying to install C:B2SServerDirectOutputPlugin.dll
Verify that you have access to that directory

 

Hmm... that target path looks suspiciously empty (C: with no \ path???).  What directory are specifying when asked where to install DOF in the setup dialogs?  Maybe try a different one?

 

If that doesn't help, you can get more logging information to look at.  Try running the setup program from a DOS prompt like this:

 

    DOFSetup.msi /L*V setup.log

 

That'll create a log file that you can look through to see if you can spot the problem.

I am trying to determine if DOFSlave.exe is actually modified at during these revisions, or if this is Freezies initial version thru it all.

 

Trying to get pro-pinball to work,   the .exe is called, and the DOFLog shows that NO LEDWiz devices are there.   I am using Zeb's stuff that has the modified DLL that you've wonderfully fixed to not need in the unified version.  

 

So, yea,  just trying to figure out if i am on the tight track with DOFSlave having the orginal ledwiz.dll bundled in the executable?

 

I don't think I've ever made any changes to DOFSlave myself, so I think you're probably right that it's the original Freezy version.  I've never even looked at it to see how it works, so I don't know whether or not it uses ledwiz.dll.  My guess would be that it never used ledwiz.dll directly, since I thought the whole point was to go through DOF, but that's only a guess.

[electricmagma]

Dofslave is a self contained dof build. My dof works fine otherwise. The path for this particular case is the pro pinball path in the steam directory. Almost positive the dofslave version has the older ledwiz.dll version in it. (The Logs don’t detect a Ledwiz and the zebs board I am using requires it )

I tried compiling a new on using freezys git, but my level of understanding this is still pretty basic