How to limit knocker usage in certain tables?

[arngrim]

this is not only on pacled, i have that on ledwiz

Sent from tapatalk

[swisslizard]

Did the same test that xantari did in his video and didnt have any issues with pacled64 or ledwiz. Really wonder what is causing these problems.

xantari:

Just to be sure that there is not some problem which is not related to Dof, I'd be grateful if you could run the same test as in your video again, but with disconnected contactors(Dont change the DOF config, just disconnectnthe contactor). If the problem is still there, then it is probably DOF related (no idea how), otherwise it is a hardware thing.

[xantari]

I unplugged all contactors, knocker, shaker and gear motor. So only thing hooked up to the PacLed64 zebsboards virtual output kit is the RGB Lightbar and the same effect occurs:

https://www.youtube.com/watch?v=FB3rA2LXPTg

I made the above video showing the random firing of RGB LED's with only the RGB lightbar hooked up.

Also, DOF R2 doesn't exhibit this behavior.

I've been pouring over the source code, and the only thing I thought of trying but haven't had the time (probably won't for a couple of weeks) is to add some extreme logging to the July 12, 2014 Github release (DOF R2), and add that same logging to DOF R3 to see if I could pinpoint the source of the problem.

Be sure to test this exact table, B2S file, and ROM. I don't have a lot of tables in my cab right now, and the other one I tried (Road Kings) appears to work OK. So it may have something to do specifically with this table, which is why I added all the table, b2s, and rom info a couple postings ago.

[xantari]

One other thing to add. I do also have a Ultimarc Ultimate I/O card in my pincab as well. Not sure that matters, but it's a secondary Pacdrive based device. It's only purpose is to drive the RGB buttons on the cab.

[xantari]

I wonder if this has something to do with it:

2016.11.09 18:36:24.406    No cabinet config file loaded. Will use AutoConfig.
2016.11.09 18:36:24.406    Cabinet auto configuration started
2016.11.09 18:36:24.406    Detected and added PacLed64 Id 1 with name PacLed64 1
2016.11.09 18:36:24.406    Added LedwizEquivalent Nr. 20 with name PacLed64 1 Equivalent 1 for PacLed64 with Id 1
2016.11.09 18:36:24.406    Debug: Ledwiz devicelist content. Handles: 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, Num devices: 0
2016.11.09 18:36:24.406    Debug: Disposing LedWiz instance -01.
2016.11.09 18:36:24.406    Cabinet auto configuration finished

I don't have an LEDWiz.

Is it emulating an LEDWiz and a PacLed64 at the same time, thus sending events that arrive at the same device? Thus sending events more than once (once to the LEDWiz emulated device), and once to the Pacled64.

This might explain why it is so sensitive to events in DOF R3 versus R2.

Also, see where it says cabinet auto configuration started.

I don't have a cabinet.xml file (I don't know how to make one).

The only USB devices I have in my system are as follows:

1.) Pacled64 based virtual output kit from zebsboards (awesome btw)

2.) Ultimarc Ultimate-IO board (for the RGB buttons, I went overboard here, didn't really need the ultimate IO board for this)

3.) Zebsboards plunger (handles all I/O for buttons and plunger)

[swisslizard]

@xantari

Just ignore the messages regarding the Ledwiz in the Log. They are created when DOF tries to autodetect Ledwiz units. As long as the log doesnt say that it is coniguring or starting a ledwiz everthing is fine.

As long as you use only devices which can be detected automatically you dont need a cabinet config. DOF will setup everything on its own.

If you want to know what DOF has configured for you, you can enter the Frontend of DOF (very basic, pretty slow and not well tested) through the B2S.Server settings window. Click the plugins button, choose DOF in the list of plugins (there should only be one entry in the list of plugins) and open the frontend. The main window of the DOF frontend has a few buttons which allow you to see the actual config of the cabinet (including the output controllers) and also the effect configs as setup in DOF.

 Is the behaviour that you have demonstrated (randomly flickering leds) in your viedo the same for all tables?

 

 

[xantari]

I'll test that scenario in a couple of other tables. Would my version of vpinmame also have an effect on what gets sent to DOF?

[swisslizard]

The Pinmame version shouldnt have a influence on the things that are sent to DOF (at least if there are no bugs in Pinmame).

If you want to test if Pinmame is a part of the problem, you can run the test you did with STNG with a EM table which doesnt use Pinmame.

 

[zebulon]

silly suggestion but have you tried a different backglass just to rule out the possibility that it is coming from the B2S server?  I realize that it is only in DOF R3 and not occurring in R2 but it couldn't hurt to eliminate all possibilities.

[xantari]

@swisslizard

Quote

Is the behaviour that you have demonstrated (randomly flickering leds) in your viedo the same for all tables?

Yes it appears most of them do. I didn't record a video of it but Terminator 2 doesn't appear to have the issue. But it's sort of random when it does occur so maybe I didn't wait long enough.

Quote

If you want to test if Pinmame is a part of the problem, you can run the test you did with STNG with a EM table which doesnt use Pinmame.

I upgraded to toxies Oct 31,2016 version of PinMame (VPM) to see if that changed anything. It did not.

Can you point me in the right direction of a table to try that is an EM table that has DOF integrated? Not having much luck finding one. I Probably just don't know where to look :-)

 

3 hours ago, zebulon said:

 

silly suggestion but have you tried a different backglass just to rule out the possibility that it is coming from the B2S server?  I realize that it is only in DOF R3 and not occurring in R2 but it couldn't hurt to eliminate all possibilities.

 

What backglass should I use?

Here is more info on my setup.

I am using B2S Server 1.3.0.1 which I believe was the last release.

Here are some additional tables I have tried which exhibit the LED issue (which is easier to show than the knocker issue. But if you listen in some of these videos you will hear the knocker going off periodically).

https://www.youtube.com/watch?v=Y6URpmv7B2g (Ball Supersonic 1..1 with DOF) - I don't have the backglass for this table. But it did do the vpinmame score DMD, and highlights the issue with the RGB lights randomly flickering. Contactors do work. I believe this is a "EM" table? I used the VPU patcher on this table to add DOF effects to the original table (Ball Supersonic 1.0)

https://www.youtube.com/watch?v=y4x3hn6ptis (Elvis knight mod). If you watch from the beginning it seems to play alright, At around the 1:00 minute mark I do my test of hitting the flippers to see if that triggers random LED's to fire on the lightbar, and it does.

https://www.youtube.com/watch?v=aFmGFS9PMJQ (Road Kings). Watch this one from the beginning. During table initialization it does the knocker several times (I don't recall if R2 did that). (it does do that in R2) But you will then hear the knocker fire (seemingly random at 0:31, 1:19, 1:29). LED Random Flickering test begins at 1:46, which you will see exhibits the same issues as other tables (ST TNG, Evlis Knight mod, Ball Supersonic 1.1).

 

[xantari]

Here is a better capture of DOF R2 versus DOF R3 in two tables (Road Kings and ST TNG).

I had the idea of turning of the audio, so all feedback you hear is what is generated from DOF. You will notice that the feedback from DOF R3 in these two tables fires alot of knockers unnecessarily. 

Additionally you will notice the flipper test which fires randomly the RGB LED lights on the lightbar in the previous videos, and the R3 versions of the videos below (road kings below I didn't do the flipper / RGB Lightbar test)

DOF R2:

DOF R2 Road Kings: https://www.youtube.com/watch?v=MbqDJnFVZDc

DOF R2 ST TNG: https://www.youtube.com/watch?v=-euuGD8EUtM

DOF R3:

DOF R3 Road Kings: https://www.youtube.com/watch?v=7MoOa_NrbwI

DOF R3 ST TNG: https://www.youtube.com/watch?v=8IhVa5LBj2A

 

Here are the screen captures of B2S Server settings, and the DOF B2S Plugin settings:

[arngrim]

i have the same than you xantari, it appears on some tables only, like sttng or scared stiff, the thing is i got used to it, but a fix is welcome

Sent from tapatalk

[swisslizard]

@xantari & @arngrim

Please try zebulons suggestion with the different backglass. This is a good idea to rule out problems coming from the backglass (I think it is a unlikely cause, but you never know). Just copy the backglass of a table which doesnt have those issues and rename it the name of the org backglass file for that table. If you do this the backglass will most likely show no or wrong effects, but for the test to check whether the backglass is involved into the problem that is not relevant. 

Another similar test scenario would be to remove the backglass of the critical tables. The B2S.Server does also work without a backglass and it does still forward the event data to DOF. If the problem we're trying to track down is caused by the backglass, everything should work fine withouth the backglass.

 

[swisslizard]

@xantari

Your DOF frontend screenshots look normal.

[xantari]

I just tried ST TNG without the .B2S file and the backglass showed up blank (expected).

The table behaved the same in DOF R3 (lots of knockers, random LED flickering when pressing flipper buttons).

I then tried a different ST TNG VpinMame ROM (edited the table script to pick a different ST TNG ROM) and it did the same thing.

Help me understand something. How does DOF receive events? Is this a process flow all events go through:

• Virtual Pinball Event <---> B2S Server
• B2S Server  < --- > VPinMame
• B2S Server ---> DOF

Where does an event begin and end? Are the events bidirectional as indicated above, with the only unidirectional flow of information going to DOF?

Did the way events are getting interpreted changed from R2 to R3?

I keep coming back to the fact that things are fine (as shown in my videos 4 posts back) with R2. 

I'm suspecting R3 is so much faster at interpreting events from the B2S Server that these artifacts are now showing up. Did some timing interval changed between DOF R2 and R3?

Did the PacDrive.dll change between DOF R2 and R3?

[swisslizard]

Quote

Help me understand something. How does DOF receive events? Is this a process flow all events go through:

Yes, every event resp. command which is passed between Pinmame and the table script is passed to DOF. DOF put every input into a queue for further processing. The design ensures (I hope) that it is not possible to miss any data which is passed to DOF.

I just made the diagram below to illustrate what is happening between table script, B2S.Server, Pinmame and DOF. DOF does only receive data which the B2S.Server intercepts from the Pinmame vs table script "communication".

Quote

Did the way events are getting interpreted changed from R2 to R3?

At least not be intention. A few additions have been made to allow for named table elements (used for PBX support), but apart from that everything should work the same it always did.

Quote

I'm suspecting R3 is so much faster at interpreting events from the B2S Server that these artifacts are now showing up. Did some timing interval changed between DOF R2 and R3?

There is no reason why R3 would be faster than R2. DOF wise there is also no timing thing involved when receiving data. All data is put in a buffer and reading the buffer is also not timing relevant. The reading thread is signaled when data is written to ensure that data is read as fast as possible.

The only timing thing is kind of a alarm clock for the main thread of DOF which is required for updating effects which have a result which changes over time (e.g. fading). That part of the code has not changed recently.

Quote

Did the PacDrive.dll change between DOF R2 and R3?

No, the dll is still the same, but there is a small change to reset Pacled64s built in fading to 0 in the output controller class for the pacled64.

 

Way forward

I still havent got a clue what causes these problems. Will try the following (but dont know how long it will take me to do this since I have just limited time):

• Comparison of the R2 code to the latest R3 code. That will be quite a bit of work since many new things (mainly for addressabled ledstrips) have been added.
• Will try to make a small B2S.Server plugin which will record all data which also received by DOF. I'm pretty curios to find out if there are any unexpected events recorded.

If you have other ideas what could be checked to nail down that problem, please let me know.

Another thing which would be good to know, is which effect setting is causing the unexpected flickering and knocks. Typically tapping the flipper button will only triger the solenoid for that flipper and nothing else. In least in theory a config which links a solenoid event (for the flipper fingers often S47, S48 or S49) whith a contactor toy, cant trigger another toy by mistake. Testing this would require to modify the config (dropping everything appart from the configs for the flipper finger to contactor connection) for a table and then trying again if the problems still exist. If they dont, more effecst could be added for further checks until the problem is back again. If you can find out what combinations of effects are causing the problems, we might get a good step ahead.

 

 

 

[xantari]

Thank you for that diagram. That definitely clears things up for me and is very helpful.

1 hour ago, swisslizard said:

Will try to make a small B2S.Server plugin which will record all data which also received by DOF. I'm pretty curios to find out if there are any unexpected events recorded.

This was my action plan as well. I am well versed in C#, but not so well versed in B2S, and VPinMame data. So my plan was to swap out the logging logic with Serilog Nuget package and add a lot of logging statements throughout the code to try familiarize myself with it. Unfortunately, like you I have limited time at the moment, in about a month or so i'm hoping to be done with a large project and then some time will free up. With serilog we could then put in logging levels in the Global config. And set it to "Debug" level which should output a massive amount of data versus the default level of "Informational". Basically all the current logging statements that exists will be at the informational level. And anything we add to diagnose this issue is at the "Debug" logging level.

I was planning on doing this on the July 2014 revision of DOF R2 as well as the latest revision of DOF R3 to compare/contrast the logs.

1 hour ago, swisslizard said:

Another thing which would be good to know, is which effect setting is causing the unexpected flickering and knocks. Typically tapping the flipper button will only triger the solenoid for that flipper and nothing else. In least in theory a config which links a solenoid event (for the flipper fingers often S47, S48 or S49) whith a contactor toy, cant trigger another toy by mistake. Testing this would require to modify the config (dropping everything appart from the configs for the flipper finger to contactor connection) for a table and then trying again if the problems still exist. If they dont, more effecst could be added for further checks until the problem is back again. If you can find out what combinations of effects are causing the problems, we might get a good step ahead.

This is actually what I was thinking at the start of this thread. My problem is I don't know how to decipher all the values in the config file and correlate it back to a specific event (such as fire knocker) to know what are the appropriate modifications to make. This is definitely one process of elimination though that would be helpful to pursue. I just need help pursuing it.

[swisslizard]

I have starteed to work on the recorder plugin. Should be ready soon.

Quote

So my plan was to swap out the logging logic with Serilog Nuget package and add a ton of logging statements throughout the code to try familiarize myself with it.

Replacing the logging in DOF with some better mechanism would be a good idea. However, please consider log4net if you try to change the logging. Be aware that adding logging statements to the threads doing the actual work in DOF might slow down the framework.

Quote

My problem is I don't know how to decipher all the values in the config file and correlate it back to a specific event (such as fire knocker) to know what are the appropriate modifications to make

It is not that hard. The columns in the ini file lines are delimited by comma. The configured effects per column (which relates to a toy) are separated by /. You can remove any number of effect configs from a column if you just remove the stuff between two /. If you have no more effects in a column, just enter a single 0 into that column.

There is a bit more on the ini configs in the dof docu: http://pinball.weilenmann.net/docu/DirectOutputWIP/inifiles.html

If you want to get rid of knocker configs check for effects which start with S7 (Solenoid 7). This is for many table the knocker. You can lookup the numbers of the toys for the configs in the manuals of the org pinball machines (can be found on IPDB).

 

[xantari]

Sounds good. I'd suggest Serilog over log4net as it has many advantages over log4net. We've switched a lot of our code based over to Serilog since it has a very nice XML-less fluent configuration interface.

Additionally it can hook into every popular logging format out there (including log4net).

It's main selling point is the way it automatically serializes complex classes as JSON strings in the log file.

Lastly, there is already an addon which is discussed here (https://github.com/serilog/serilog/issues/809) and is actually implemented here: https://github.com/serilog/serilog-sinks-async which should cause no overhead with DOF, or very very minimal overhead as it does async logging. There is also an alternative batching mechnism here: https://github.com/serilog/serilog-sinks-periodicbatching 

 

[swisslizard]

Will have to look into serilog. Sounds pretty good.

Will send you a PM shortly.

 

[swisslizard]

Hi guys

Made a small plugin to record all data which is sent by the B2S.Server. Install that plugin like you install DOF (plugin folder of B2S.Server). The plugin runs in paralell with DOF and write all data it receives from B2S.Server to the file B2SEventData.txt in the table folder. Important: Dont forget to remove the plugin later on. Otherwise it will generate a HUGE file of table data over time.

You can download this small hack here: http://pinball.weilenmann.net/B2SServerDataRecorder_not_even_alpha.zip

The file with the event data contains 4 columns:

• Timestamp of the event
• Table Element Type (as defined here: http://pinball.weilenmann.net/docu/DirectOutputWIP/namespace_direct_output.html#a175aa273230ef2862f0ed4e5551ceb38)
• Table Element Number
• Table Element Value

If you want to translate the table emement type and table element number to the actual table element, you'll need to download the tables manual from IPDB. The manual have pages on solenoids/flashers, switch matrix and lamp matrix where you can lookup the table elements.

Xantari has already done a small first test with that plugin and provided me with the file of B2SEventData. Already found something slightly strange, but I'll need to check this with xantari first.

Hope to have some more info soon!

 

[swisslizard]

Xantari has provided me with some more data to analyze. At first sight it looked like the problem is caused by incorrect data which is supplied to DOF, but that assumption turned out to be wrong. I think that the data which is sent to DOF is correct. Since this pretty much rules out the input side of DOF as a cause for these problem, we'll have to start checking some other things:

• The experiment with the reduced configs, as proposed in a previous post would still be a good idea. Unfortunately I cant do that myself, since I havent got any problems here. Here is the proposal again:
  Another thing which would be good to know, is which effect setting is causing the unexpected flickering and knocks. Typically tapping the flipper button will only triger the solenoid for that flipper and nothing else. In least in theory a config which links a solenoid event (for the flipper fingers often S47, S48 or S49) whith a contactor toy, cant trigger another toy by mistake. Testing this would require to modify the config (dropping everything appart from the configs for the flipper finger to contactor connection) for a table and then trying again if the problems still exist. If they dont, more effecst could be added for further checks until the problem is back again. If you can find out what combinations of effects are causing the problems, we might get a good step ahead.
• I'll try to make a experimental DOF version which logs all data which is sent to the Pacled64 device. This would allow to check for unexcpected data. If there is unexpected data, the cause for the problems must be in the toys or effects implementation. If there is no unexpected data, the cause for the problems is most likely in pacleds org driver dll.

 

 

[swisslizard]

As promised I made a DOF version which records all commands which are sent to the pacled64 in a file. All Pacledled 64 commands and their parameters are written to the file PacLed64Data.txt in the table folder. Download is here: http://pinball.weilenmann.net/DirectOutput_Pacled64test_experimental_Build_6166_18436.zip

Dont use the build for anythiung else than checking for problems with the pacled64 and remember to reinstall a normal DOF version after your tests, since the test version will generate a log file which grows bigger and bigger over time.

File content

The file is tab delimited which maikes it easy to open it in excel or some other program which can use delimited data.

• Column 0: Timestamp
• Column 1: Command
• Column 2: Index of the Pacled64 device
• Column 3-n: Remaining paras for Command as follows:
  SetLEDIntensities -> Intensity values for all outputs
  SetLEDFadeTime -> Fadetime
  SetLEDIntensity -> Outputnumber, Intensity
  SetLEDStates -> Group of Outputs (8 outputs are a group), State as Byte with Bitpattern for all outputs in the group

 

The intensity command allow to set opacled64 outputs to the specified intensity. The state commands all9ow to turn a output off or to revert it to its last intensity value. Generally DOF tries to use the state commands to turn off outputs and to use the intensity commands to set output to a on state. If a lot of outputs (>30) have to be updated at the same time, DOF uses the SetLEDIntensities command, for small number of changes DOF uses the SetLEDIntensity repeatedly since this is faster.

@xantari

 

Please repeat the test you did with STNG and the clock on the BG screen with this DOF version, so we can check what is sent to the Pacled when the flickering occurs. To properly parse the data I'll also need a list of your output assignments. I screenshot of you pacled config page in the config tool will serve that purpose well.

 

 

 

[xantari]

3 hours ago, swisslizard said:

Please repeat the test you did with STNG and the clock on the BG screen with this DOF version, so we can check what is sent to the Pacled when the flickering occurs. To properly parse the data I'll also need a list of your output assignments. I screenshot of you pacled config page in the config tool will serve that purpose well.

@swisslizard

I repeated the test. What is strange is the problem is now gone. Did you change anything other than adding logging statements?

Here is the logging data: https://drive.google.com/open?id=0B__g7EhWQEETMUFJcDBlV05ldEE

Here is the video: https://www.youtube.com/watch?v=SKrDCImH0Pk

Here is the screenshot of my DOF Config: https://s4.postimg.org/gxhoccwp9/DOFConfig.png

[swisslizard]

Very strange. Didnt change anything apart from the recording code.

Will look at your data when I back home.