490 replies to this topic

[DDH69]

From DOFLinx 6.20 onward R3++ is required.  This includes Extensions.dll.  DOFLinx will fail without this essential part of DOF R3++

[senseless]

Been trying to get R3++ up and running and I am at a loss here. Installed using the installer and DOF is active but behaves strangly.

 

Flippers do not always fire and DOF looks like it's interruped. During interaction on the table the contactors are sometimes not firing when flippers are pressed. The behaviour is similar in VPX and FX3. 

 

Despite using the installer I checked all dll files to see if one of them was blocked.Generated new global config and cabinet file with no noticable result. Running the R3 beta I have no issues with DOF.

 

My config is 2 ledwiz cards, windows 10 64 bits. I enclosed the directoutput log and config flies.

 

Thanks for the help.

Attached Files

•  DirectOutput.zip   86.84KB   16 downloads

Edited by senseless, 26 February 2018 - 03:07 PM.

[mjr]

Been trying to get R3++ up and running and I am at a loss here. Installed using the installer and DOF is active but behaves strangly.

My config is 2 ledwiz cards, windows 10 64 bits. I enclosed the directoutput log and config flies.

 

For anyone who's having trouble with sporadic LedWiz behavior like that, try adjusting the "LedWiz Default Min Command Interval":

 

- make sure all other programs are closed, especially PinballX, VP, B2S

 

- run the DOF Global Config Editor

 

- load your existing Config\GlobalConfig_B2SServer.xml

 

- go to the Misc page

 

- change the "LedWiz Default Min Command Interval" to 10ms

 

- save changes back to the same file

 

- repeat for Config\GlobalConfig_PinballX.xml

 

If that helps, you can try experimenting with shorter delay times.  The delay time works around a bug in the LedWiz USB implementation that makes it randomly misinterpret commands if they're sent too quickly from the PC.  You don't want to make it longer than necessary, but you have to make it long enough that the LedWiz doesn't get overwhelmed with DOF updates.  5 to 10 ms seems pretty typical.

[mjr]

After lots of frustration, I swapped back to my 6.11 DirectOutput folder by simply renaming both (swapping the active one) .. All works great (my PROC tables too).  Figuring all MUST be fixed, I just did another clean DOFLinx/DOF R3++/DOFConfig as Terry did.

Still that same error about Extensions.dll not loading with Vpinball.  Super Bizarre.

 

I'm thinking there is some dependency for Extensions.dll that my system has a problem with. (e.g. some .Net version or something I need as a Pre-requisite?) The file is installed by your msi, so it must be correct.  Is Vpinball the only setup that leverages Extensions.dll or do FX2 and FX2 backglasses do as well?

 

The Extensions.dll dependency is directly in the main DirectOutput.dll, so it gets hit in every possible way of loading DOF.  Whatever's going on is down in the bowels of Windows or .Net.  DOF isn't doing anything unusual here; it just uses the standard C# dependency management, so I think what's tripping things up is one of the weird internal rules in Windows or .Net for resolving DLL paths.  There must be something about the system environment when VP is running that changes the way DLL paths are resolved vs when those other programs are running.  The only weirdness I can think of is the unusual way that B2S loads DOF, which is via that Windows desktop shortcut link in the Visual Pinball\Tables\Plugins folder.  Maybe something having that shortcut in the mix is screwing up the path resolution. 

 

The only other similar case I've run into turned out to be that issue with space characters in the path that I mentioned, but that doesn't seem to be the issue on your machine.  Maybe if you post of your relevant directory paths something will jump out - VP, VP tables, B2S, DOF.  Or maybe not; I would never have guessed that the space character would cause problems, so maybe there's some other thing I'd never guess, like maybe you're not allowed to use the letter "D" in paths some of the time with .Net or something bizarre and stupid like that...

One other thing you might want to try, speaking of the bowels of .Net: there's a tool called GACUTIL that you can run in a CMD window.

 

C:\>  GACUTIL /L

 

That lists all of the DLLs in the .Net "Global Assembly Cache", which is a temp folder .Net creates and populates with copies of DLLs used in C# and other .Net programs.  .Net loads DLLs preferentially from that temp cache even when other copies exist on the system, which can sometimes cause problems with updates, since .Net can sometimes ignore new versions you install and run old versions from the cache instead.  So you might try running GACUTIL /L and see if you spot Extensions.dll or any of the other DirectOutput DLLs in the list.  If so, you can remove them with GACUTIL /U <dll name>. 

 

I don't expect that's what's going on in your case, but given that you've ruled out everything else I can think of, it might be worth a shot.

[tttttwii]

 

Been trying to get R3++ up and running and I am at a loss here. Installed using the installer and DOF is active but behaves strangly.

My config is 2 ledwiz cards, windows 10 64 bits. I enclosed the directoutput log and config flies.

 

For anyone who's having trouble with sporadic LedWiz behavior like that, try adjusting the "LedWiz Default Min Command Interval":

 

- make sure all other programs are closed, especially PinballX, VP, B2S

 

- run the DOF Global Config Editor

 

- load your existing Config\GlobalConfig_B2SServer.xml

 

- go to the Misc page

 

- change the "LedWiz Default Min Command Interval" to 10ms

 

- save changes back to the same file

 

- repeat for Config\GlobalConfig_PinballX.xml

 

If that helps, you can try experimenting with shorter delay times.  The delay time works around a bug in the LedWiz USB implementation that makes it randomly misinterpret commands if they're sent too quickly from the PC.  You don't want to make it longer than necessary, but you have to make it long enough that the LedWiz doesn't get overwhelmed with DOF updates.  5 to 10 ms seems pretty typical.

 

 

My misc folder is empty. There is nothing to change! Can I also edit the xml?

[tttttwii]

Everything OK. I had still V2 installed on my cab and now replaced it by your code. Now I see the menu! Thanks for your great work!

[senseless]

 

Been trying to get R3++ up and running and I am at a loss here. Installed using the installer and DOF is active but behaves strangly.

My config is 2 ledwiz cards, windows 10 64 bits. I enclosed the directoutput log and config flies.

 

For anyone who's having trouble with sporadic LedWiz behavior like that, try adjusting the "LedWiz Default Min Command Interval":

 

- make sure all other programs are closed, especially PinballX, VP, B2S

 

- run the DOF Global Config Editor

 

- load your existing Config\GlobalConfig_B2SServer.xml

 

- go to the Misc page

 

- change the "LedWiz Default Min Command Interval" to 10ms

 

- save changes back to the same file

 

- repeat for Config\GlobalConfig_PinballX.xml

 

If that helps, you can try experimenting with shorter delay times.  The delay time works around a bug in the LedWiz USB implementation that makes it randomly misinterpret commands if they're sent too quickly from the PC.  You don't want to make it longer than necessary, but you have to make it long enough that the LedWiz doesn't get overwhelmed with DOF updates.  5 to 10 ms seems pretty typical.

 

 

I tried several different Command Intervals but with no notice differences. The LedWiz USB implementation did help me to think outside the box. I reassessed the USB connections for my two LedWiz cards and saw they were not connected on the same USB 2.0 bank. I changed this and connected both Ledwiz cards on USB port 1 and 2 and did some tests.

 

The whole sporadic LedWiz behavior was gone and very direct response of the DOF toys and flippers on all interactions. This was clearly the problem! So for anyone who has strange behaviour my advice is to also look (in case you have multple LedWiz cards) at how they are connected to your motherboard as this can cause strange sporadic LedWiz behavior.

 

The only thing that still puzzle me is why this sporadic LedWiz behavior started with th R3++ DOF version and is not noticable with the previous R3 beta. This remains a mistery to me.

 

But all in all glad I got this solved! Thanks guys for the help and without the responses I would have never looked at my USB connections...

[mjr]

 

 

I tried several different Command Intervals but with no notice differences. The LedWiz USB implementation did help me to think outside the box. I reassessed the USB connections for my two LedWiz cards and saw they were not connected on the same USB 2.0 bank. I changed this and connected both Ledwiz cards on USB port 1 and 2 and did some tests.

 

The whole sporadic LedWiz behavior was gone and very direct response of the DOF toys and flippers on all interactions. This was clearly the problem! So for anyone who has strange behaviour my advice is to also look (in case you have multple LedWiz cards) at how they are connected to your motherboard as this can cause strange sporadic LedWiz behavior.

 

The only thing that still puzzle me is why this sporadic LedWiz behavior started with th R3++ DOF version and is not noticable with the previous R3 beta. This remains a mistery to me.

I'm glad you found the solution!  I wouldn't have thought of trying that, but it does make a certain kind of sense given that the root of the problem seems to be in the LedWiz's USB connection.

 

I agree that it's pretty mysterious that the problem only showed up with the new version, but I have a guess.  If you were on the original 2015 R3 beta from Swisslizard, that still used ledwiz.dll, whereas the new version bypasses that and talks directly to the LedWiz via its USB protocol.  That probably speeds up the packet timing for multiple devices since DOF uses a separate thread for each device.  Moving both devices to one USB hub probably restored the old status quo to some extent by forcing them to share USB bandwidth.

[senseless]

 

 

I tried several different Command Intervals but with no notice differences. The LedWiz USB implementation did help me to think outside the box. I reassessed the USB connections for my two LedWiz cards and saw they were not connected on the same USB 2.0 bank. I changed this and connected both Ledwiz cards on USB port 1 and 2 and did some tests.
 
The whole sporadic LedWiz behavior was gone and very direct response of the DOF toys and flippers on all interactions. This was clearly the problem! So for anyone who has strange behaviour my advice is to also look (in case you have multple LedWiz cards) at how they are connected to your motherboard as this can cause strange sporadic LedWiz behavior.
 
The only thing that still puzzle me is why this sporadic LedWiz behavior started with th R3++ DOF version and is not noticable with the previous R3 beta. This remains a mistery to me.

I'm glad you found the solution!  I wouldn't have thought of trying that, but it does make a certain kind of sense given that the root of the problem seems to be in the LedWiz's USB connection.
 
I agree that it's pretty mysterious that the problem only showed up with the new version, but I have a guess.  If you were on the original 2015 R3 beta from Swisslizard, that still used ledwiz.dll, whereas the new version bypasses that and talks directly to the LedWiz via its USB protocol.  That probably speeds up the packet timing for multiple devices since DOF uses a separate thread for each device.  Moving both devices to one USB hub probably restored the old status quo to some extent by forcing them to share USB bandwidth.

That sounds like a very logical explaination. This also implies a better overall response discarding the old ledwiz.dll.

I'm really glad I'm now able to enjoy your DOF R++ update in the full. Thanks for your hard work and help .

Verstuurd vanaf mijn SM-G930F met Tapatalk

[psmiraglia]

Just FYI, I still have timing issues with PacLed, so I decided to run DOF3++/Doflinx6.22 for FX3, and DOF3/Doflinx6.11 for PBX, VP, FP, PinPro and FX2. Ugly, but stable...

[mjr]

Just FYI, I still have timing issues with PacLed, so I decided to run DOF3++/Doflinx6.22 for FX3, and DOF3/Doflinx6.11 for PBX, VP, FP, PinPro and FX2. Ugly, but stable...

 

I wish I knew what was going on with that.  If there's anyone here who has a PacLed to test with and can find their way around C#, the code is all on GitHub.

[senseless]

Just FYI, I still have timing issues with PacLed, so I decided to run DOF3++/Doflinx6.22 for FX3, and DOF3/Doflinx6.11 for PBX, VP, FP, PinPro and FX2. Ugly, but stable...

Probably a longshot but did you try switching usb ports to see if there is any change in the timing? Not all usb ports are created equal .

Verstuurd vanaf mijn SM-G930F met Tapatalk

[psmiraglia]

QuoteProbably a longshot but did you try switching usb ports to see if there is any change in the timing? Not all usb ports are created equal .

Cant do that. I have all 3 boards and DMD on an ESD protected usb hub and want to keep it that way. This should be a SW fix.

[gigalula]

Thanks MJR... Yesterday I tried to get my cab working with new DOF R3++ but light and selenoid on my LEDWIZ was not acting properly so after reading this topic now I understand more and see a light over the tunnel hehehehe... so I will try again tommorow by changing "LedWiz Default Min Command Interval" and get back with result.

[gigalula]

Yep that was it  

 

1 make a backup of you DirectOutput folder

2 Deleted all files from inside this last

3 Use the installer with the same exact old path

4 Ensure that you have B2Sserver updated to latest version 1.3.0.2 in my case

5 Update your DirectOutputConfig.ini (Usually for me inside vp Tables folder same location as B2SServer files)

 

I had no existing file so I took "GlobalConfig_B2SServer.xml" from examples folder then copied inside folder "...\DirectOutput\Config\" and load the XML with GlobalConfigEditor.exe and set interval to to 5ms and voila!  all VP reacting normal after many test with all version of VP I have

 

Also adding path for GlobalConfig_B2SServer.xml inside DOFLinx.ini as per pdf and this also fixed my problem with FX3

 

 

Now everything back to normal in my case concerning my 1x LedWiz  +  1x Pinscape (Not use for toy only tilt)

 

Thanks again guys for this helpfull topic

[mjr]

gigalulu - glad that did the trick.  I'm changing the default interval to 10ms for future builds, since it seems to be such a common issue.  

 

psmiraglia - I made the PacLed timing configurable via GlobalConfig_xxx, so you can experiment with different timings to see if that makes any difference.  You can use the new PacLed tab in the Global Config Editor to change it.  Try kicking it up to 10 or 20 ms and see if that helps.  Remember that VP uses GlobalConfig_B2SServer.xml and PinballX uses GlobalConfig_PinballX.xml, so you'll have to make the changes in both places.  I also spotted a potential concurrency error in the way the initialization was being done, which could conceivably be causing the random firing when you return from VP to PBX, but I kind of doubt it because I don't think this particular error would manifest as consistently as you seem to see it.  But it's possible.  Anyway, new builds are here:  

 

http://mjrnet.org/pi...jr-20180301.zip

http://mjrnet.org/pi...jr-20180301.msi

 

I'm not updating the links to them on my downloads page yet since the PacLed initialization changes could have broken something - if you have a chance to try it, let me whether or not it's at least "working" as well as before.  Hopefully it didn't cause worse problems even if it didn't help with the random firing.

[doogie2301]

I have an issue after upgrading to DOF R3++.  I only have a SainSmart relay board triggering solenoids.  When I open a VPX table, sometimes there is no DOF at all.  There does seem to be one difference in the log when it works vs. when it doesn't, which I highlighted in red below (the name of the controller is different).  I don't recall if I was getting that exception before, but it doesn't seem to make a difference in the first scenario because the DOF still works.

 

​Log when it works

---------------------------------------------------------------------------------

DirectOutput Version 3.1.6623.21194, built 2018.02.18 11:46
MJR Grander Unified DOF R3++ edition feat. Djrobx, Rambo3, and Freezy
DOF created by SwissLizard | https://github.com/mjrgh/DirectOutput
2018.03.01 16:53:31.181 DirectOutput Logger initialized
2018.03.01 16:53:31.165 Global config filename is "C:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml"
2018.03.01 16:53:31.181 Global config loaded from: C:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml
2018.03.01 16:53:31.181 Loading Pinball parts
2018.03.01 16:53:31.181 Loading cabinet
2018.03.01 16:53:31.181 Will load cabinet config file: C:\DirectOutput\config\Cabinet.xml
2018.03.01 16:53:31.227 1 output controller defnitions and 1 toy definitions loaded from cabinet config.
2018.03.01 16:53:31.227 Cabinet config file has AutoConfig feature enabled. Calling AutoConfig.
2018.03.01 16:53:31.227 Cabinet auto configuration started
2018.03.01 16:53:31.243 PhilipsHueAutoConfigurator.AutoConfig started...note, actual connection detection will happen asynchronously, and device disabled if not succesfull (check further down in the log)
2018.03.01 16:53:31.539 FT245RBitbangControllerAutoConfigurator.AutoConfig.. Detected FT245RBitbangController[0], name=FT245RBitbangController 0, serial #12345678
2018.03.01 16:53:31.539 Detected and added FT245RBitbangController Id 0 with name FT245RBitbangController 0
2018.03.01 16:53:31.539 Cabinet auto configuration finished
2018.03.01 16:53:31.539 Autoconfig complete.
2018.03.01 16:53:31.539 Cabinet config loaded successfully from C:\DirectOutput\config\Cabinet.xml
2018.03.01 16:53:31.539 Cabinet loaded
2018.03.01 16:53:31.539 Loading table config
2018.03.01 16:53:31.539 Warning: No table config file found. Will try to load config from LedControl file(s).
2018.03.01 16:53:31.539 Will try to load configs from DirectOutput.ini or LedControl.ini file(s) for RomName neptune
2018.03.01 16:53:31.539 Loading LedControl file C:\DirectOutput\config\directoutputconfig40.ini
2018.03.01 16:53:31.539 Min DOF Version is 0.8 for file directoutputconfig40.ini
2018.03.01 16:53:31.654 1 directoutputconfig.ini or ledcontrol.ini files loaded.
2018.03.01 16:53:31.654 Config for RomName neptune exists in LedControl data. Updating cabinet and config.
2018.03.01 16:53:31.669 Table config loading finished: romname=neptune, tablename=Neptune (Gottlieb 1978)
2018.03.01 16:53:31.669 Pinball parts loaded
2018.03.01 16:53:31.669 Starting processes
2018.03.01 16:53:31.669 Initializing cabinet
2018.03.01 16:53:31.669 Debug: Initializing output controllers
2018.03.01 16:53:31.669 FT245RBitbangController Sainsmart 1 with serial number 12345678 has been initialized and the updater thread has been started.
2018.03.01 16:53:31.669 FT245RBitbangController FT245RBitbangController 0 with serial number 12345678 has been initialized and the updater thread has been started.
2018.03.01 16:53:31.669 Debug: Output controllers initialized
2018.03.01 16:53:31.669 Cabinet initialized
2018.03.01 16:53:31.685 Loading shape definition file: C:\DirectOutput\config\DirectOutputShapes.xml
2018.03.01 16:53:31.685 EXCEPTION: Could not open the connection to FTDI chip with serial number 12345678.
2018.03.01 16:53:31.685 EXCEPTION: Thread: FT245RBitbangController 12345678 named FT245RBitbangController 0 updater thread
2018.03.01 16:53:31.685 EXCEPTION: Message: FT_EXCEPTION --> FTDI device not opened.
2018.03.01 16:53:31.685 EXCEPTION: Stacktrace:    at DirectOutput.Cab.Out.FTDIChip.FTDI.ErrorHandler(FT_STATUS ftStatus, FT_ERROR ftErrorCondition)
2018.03.01 16:53:31.685 EXCEPTION: Stacktrace:    at DirectOutput.Cab.Out.FTDIChip.FTDI.ErrorHandler(FT_STATUS ftStatus)
2018.03.01 16:53:31.685 EXCEPTION: Stacktrace:    at DirectOutput.Cab.Out.FTDIChip.FT245RBitbangController.Connect()
2018.03.01 16:53:31.685 EXCEPTION: Targetsite: Void ErrorHandler(FT_STATUS, FT_ERROR)
2018.03.01 16:53:31.685 Connection to FTDI chip 12345678 established.
2018.03.01 16:53:31.685 Warning: No connection to FTDI chip 12345678. Updater thread will terminate.
2018.03.01 16:53:31.716 Framework initialized.
2018.03.01 16:53:31.716 Have fun!
2018.03.01 16:53:41.961 Finishing framework
2018.03.01 16:53:41.963 Finishing cabinet
2018.03.01 16:53:41.963 Debug: Finishing output controllers
2018.03.01 16:53:42.078 Connection to FTDI chip 12345678 closed.
2018.03.01 16:53:42.078 FT245RBitbangController Sainsmart 1 with serial number 12345678 has been finished and the updater thread has been terminated.
2018.03.01 16:53:42.078 FT245RBitbangController FT245RBitbangController 0 with serial number 12345678 has been finished and the updater thread has been terminated.
2018.03.01 16:53:42.078 Debug: Output controllers finished
2018.03.01 16:53:42.078 Cabinet finished
2018.03.01 16:53:42.078 DirectOutput framework finished.
2018.03.01 16:53:42.078 Bye and thanks for using!
 

​Log when it doesn't work

---------------------------------------------------------------------------------
DirectOutput Version 3.1.6623.21194, built 2018.02.18 11:46
MJR Grander Unified DOF R3++ edition feat. Djrobx, Rambo3, and Freezy
DOF created by SwissLizard | https://github.com/mjrgh/DirectOutput
2018.03.01 17:05:34.555 DirectOutput Logger initialized
2018.03.01 17:05:34.539 Global config filename is "C:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml"
2018.03.01 17:05:34.555 Global config loaded from: C:\DIRECTOUTPUT\config\GlobalConfig_B2SServer.xml
2018.03.01 17:05:34.555 Loading Pinball parts
2018.03.01 17:05:34.555 Loading cabinet
2018.03.01 17:05:34.555 Will load cabinet config file: C:\DirectOutput\config\Cabinet.xml
2018.03.01 17:05:34.602 1 output controller defnitions and 1 toy definitions loaded from cabinet config.
2018.03.01 17:05:34.602 Cabinet config file has AutoConfig feature enabled. Calling AutoConfig.
2018.03.01 17:05:34.602 Cabinet auto configuration started
2018.03.01 17:05:34.618 PhilipsHueAutoConfigurator.AutoConfig started...note, actual connection detection will happen asynchronously, and device disabled if not succesfull (check further down in the log)
2018.03.01 17:05:34.899 FT245RBitbangControllerAutoConfigurator.AutoConfig.. Detected FT245RBitbangController[0], name=FT245RBitbangController 0, serial #12345678
2018.03.01 17:05:34.899 Detected and added FT245RBitbangController Id 0 with name FT245RBitbangController 0
2018.03.01 17:05:34.899 Cabinet auto configuration finished
2018.03.01 17:05:34.899 Autoconfig complete.
2018.03.01 17:05:34.899 Cabinet config loaded successfully from C:\DirectOutput\config\Cabinet.xml
2018.03.01 17:05:34.899 Cabinet loaded
2018.03.01 17:05:34.899 Loading table config
2018.03.01 17:05:34.899 Warning: No table config file found. Will try to load config from LedControl file(s).
2018.03.01 17:05:34.899 Will try to load configs from DirectOutput.ini or LedControl.ini file(s) for RomName neptune
2018.03.01 17:05:34.899 Loading LedControl file C:\DirectOutput\config\directoutputconfig40.ini
2018.03.01 17:05:34.899 Min DOF Version is 0.8 for file directoutputconfig40.ini
2018.03.01 17:05:35.008 1 directoutputconfig.ini or ledcontrol.ini files loaded.
2018.03.01 17:05:35.008 Config for RomName neptune exists in LedControl data. Updating cabinet and config.
2018.03.01 17:05:35.024 Table config loading finished: romname=neptune, tablename=Neptune (Gottlieb 1978)
2018.03.01 17:05:35.024 Pinball parts loaded
2018.03.01 17:05:35.024 Starting processes
2018.03.01 17:05:35.024 Initializing cabinet
2018.03.01 17:05:35.024 Debug: Initializing output controllers
2018.03.01 17:05:35.024 FT245RBitbangController Sainsmart 1 with serial number 12345678 has been initialized and the updater thread has been started.
2018.03.01 17:05:35.024 FT245RBitbangController FT245RBitbangController 0 with serial number 12345678 has been initialized and the updater thread has been started.
2018.03.01 17:05:35.024 Debug: Output controllers initialized
2018.03.01 17:05:35.024 Cabinet initialized
2018.03.01 17:05:35.040 Loading shape definition file: C:\DirectOutput\config\DirectOutputShapes.xml
2018.03.01 17:05:35.040 EXCEPTION: Could not open the connection to FTDI chip with serial number 12345678.
2018.03.01 17:05:35.040 EXCEPTION: Thread: FT245RBitbangController 12345678 named Sainsmart 1 updater thread
2018.03.01 17:05:35.040 EXCEPTION: Message: FT_EXCEPTION --> FTDI device not opened.
2018.03.01 17:05:35.040 EXCEPTION: Stacktrace:    at DirectOutput.Cab.Out.FTDIChip.FTDI.ErrorHandler(FT_STATUS ftStatus, FT_ERROR ftErrorCondition)
2018.03.01 17:05:35.040 EXCEPTION: Stacktrace:    at DirectOutput.Cab.Out.FTDIChip.FTDI.ErrorHandler(FT_STATUS ftStatus)
2018.03.01 17:05:35.040 EXCEPTION: Stacktrace:    at DirectOutput.Cab.Out.FTDIChip.FT245RBitbangController.Connect()
2018.03.01 17:05:35.040 EXCEPTION: Targetsite: Void ErrorHandler(FT_STATUS, FT_ERROR)
2018.03.01 17:05:35.040 Connection to FTDI chip 12345678 established.
2018.03.01 17:05:35.040 Warning: No connection to FTDI chip 12345678. Updater thread will terminate.
2018.03.01 17:05:35.071 Framework initialized.
2018.03.01 17:05:35.071 Have fun!
2018.03.01 17:05:44.731 Finishing framework
2018.03.01 17:05:44.735 Finishing cabinet
2018.03.01 17:05:44.736 Debug: Finishing output controllers
2018.03.01 17:05:44.736 FT245RBitbangController Sainsmart 1 with serial number 12345678 has been finished and the updater thread has been terminated.
2018.03.01 17:05:44.868 Connection to FTDI chip 12345678 closed.
2018.03.01 17:05:44.868 FT245RBitbangController FT245RBitbangController 0 with serial number 12345678 has been finished and the updater thread has been terminated.
2018.03.01 17:05:44.868 Debug: Output controllers finished
2018.03.01 17:05:44.868 Cabinet finished
2018.03.01 17:05:44.868 DirectOutput framework finished.
2018.03.01 17:05:44.868 Bye and thanks for using!
 

[mjr]

doogie2301 - it looks like you might be having a conflict between the new SainSmart auto-detection and your explicit Cabinet.xml SainSmart entry.  Try removing the SainSmart entry from your Cabinet.xml file.  I think the reason it sometimes works and sometimes doesn't is that DOF handles each device on a separate thread, so the order in which it initializes the devices depends kind of randomly on which thread runs first.  I think what's happening is that sometimes the auto-config thread manages to claim control of the device first, and sometimes the other thread claims it first - whichever thread wins locks out the other, which causes the exception.  So if you can get it down to just the single auto-config thread by removing the Cabinet.xml entry, hopefully that'll fix it for you.

[doogie2301]

got it, thanks, that worked.  so do I need Cabinet.xml at all?  when I remove it, the auto-configuration seems to handle it and the DOF is working. 

[mjr]

got it, thanks, that worked.  so do I need Cabinet.xml at all?  when I remove it, the auto-configuration seems to handle it and the DOF is working. 

 

Great!

 

I think you can ditch Cabinet.xml now, as long as the only reason you needed it was for the Sainsmart device setup.  You do still need it for the addressable LED strips if you're using those, but I think that's the only thing that requires it now.