How to limit knocker usage in certain tables?

[xantari]

I updated to DOF R3 from DOF R2 and it seems like tables react with much more feedback than before.

I don't know why this is, but the reaction in star trek TNG is firing off the knocker far to much. Multiball and special events seem to trigger the knocker to go crazy (several knocker hits in a span of several seconds).

My question is:

What setting would reduce the knocker activity in the DOF config tool?

I'm trying to decipher the values for that table, but not having a lot of luck in determining how those values affect knockers, contactors, LED lights, etc.

I did look at the documeentation, but am still lost.

Is there a tutorial on the DOF config tool and the associated values?

Additionally, I don't know what some of the values in the DOF config tool mean such as: "PF Back PBX MX". What does PF mean? What does MX mean? I'm guessing PBX means Visual Pinball 10, or perhaps it means PinballX front end? :-)

Also, what is an "E config"?

[arngrim]

mx is matrix, it is a toy for ledstrip adressable with a controller like teensy
e config is a non rom config, we have to script events like DOF 101, DOFPulse and in the ini we put E101 somewhere and connection can be made
in sttng, knocker has only the knocker solenoid mapped, S7 so mapping is normal, but dof has a bug that fire the knocker on its own, i have that rarely

Sent from tapatalk

[arngrim]

try to increase this in the GlobalConfig_B2SServer.xml to see if it makes a difference

 

<GlobalConfig>
  <LedWizDefaultMinCommandIntervalMs>3</LedWizDefaultMinCommandIntervalMs>

[mjr]

9 hours ago, arngrim said:

...but dof has a bug that fire the knocker on its own, i have that rarely

For what it's worth, I've never encountered this.  Are you absolutely sure it's a DOF bug?  Do you ever see random misfires of other devices?  If the knocker is the only device you've seen do this, I'd suspect a hardware issue rather than DOF.  If it's a DOF bug, the misfires would most likely occur on random ports rather than on the same port every time.

 

[arngrim]

it is not only me, randr and others has that too, swisslizard is aware, with dof r3 and reducing the ms like i explain reduce the issue, i can't explain the why or the how

Sent from tapatalk

[xantari]

it is not only me, randr and others has that too, swisslizard is aware, with dof r3 and reducing the ms like i explain reduce the issue, i can't explain the why or the how

Sent from tapatalk

Thanks I'll try that out this weekend

[mjr]

On 11/1/2016 at 11:27 AM, arngrim said:

it is not only me, randr and others has that too, swisslizard is aware, with dof r3 and reducing the ms like i explain reduce the issue, i can't explain the why or the how

Understood.  I'm still curious, though - is it ONLY the knocker that this happens on, or does it happen on all channels?

 

[arngrim]

sometimes it is so quick that i barely hear the knocker going up, i see the flashers very briefly occasionally, there were discussions about it long ago, have to find them back here, not sure all controllers were affected, i have that on ledwiz

Sent from tapatalk

[mjr]

18 minutes ago, arngrim said:

sometimes it is so quick that i barely hear the knocker going up, i see the flashers very briefly occasionally, there were discussions about it long ago, have to find them back here, not sure all controllers were affected, i have that on ledwiz

Interesting.  You might try my new version - it eliminates LEDWIZ.DLL and talks to the LedWiz directly.  That might make it a little more robust, since it can check for USB communications errors.  (http://mjrnet.org/pinscape/dll-updates.html)

 

[mjr]

18 minutes ago, arngrim said:

sometimes it is so quick that i barely hear the knocker going up, i see the flashers very briefly occasionally, there were discussions about it long ago, have to find them back here, not sure all controllers were affected, i have that on ledwiz

Interesting.  You might try my new version - it eliminates LEDWIZ.DLL and talks to the LedWiz directly.  That might make it a little more robust, since it can check for USB communications errors.  (http://mjrnet.org/pinscape/dll-updates.html)

 

[xantari]

Is the mjr version of DOF R3 make any difference for Pacled64 (I am using zebsboards full setup, light bar, virtual output kit, knocker, shaker and gear motor combo)

[mjr]

1 hour ago, xantari said:

Is the mjr version of DOF R3 make any difference for Pacled64 (I am using zebsboards full setup, light bar, virtual output kit, knocker, shaker and gear motor combo)

As far as I've been able to determine, it's based on the same code as the Nov 30, 2015 official DOF release from SwissLizard, with my updates for LedWiz and Pinscape.  So it should have no differences for the Pacled64 code.

[arngrim]

i found 2 mentions about the random firing in the forum=

 

[xantari]

So I tried the  LedWizDefaultMinCommandIntervalMs  setting, by first setting it to 3, then to 10. No effect. 

The knocker goes crazy in ST TNG in DOF R3.

I have made a video of what I am experiencing here: https://www.youtube.com/watch?v=xUFXybKx-qk

and here: https://www.youtube.com/watch?v=Ut_GbjbeReI 

I did a test and reverted back to R2 and things acted normally. Infact after about 7-8 minutes of gameplay using R2 instead of R3 I had yet to hear a knocker in ST TNG. I even triggered some events that would normally have made the knocker go crazy in R3 (extra ball), but when I got an extra ball while running R2 I heard no knocker, just the normal LED lights and contactor feedback.

With R3 5818 version I hear the knocker a lot, On this table it is very pronounced, I get it probably every 15-20 seconds something triggers it.

[xantari]

I see one of the other posts linked here mentioned zebsboards, I am also using his virtual output kit.

I don't think it is the kit though since it doesn't happen with R2.

[xantari]

Deleted, duplicate post

[xantari]

What value unmaps knocker activity in the config file as one way to solve this issue since there appears to be a difference in R3's behavior of interpreting table events compared to R2 as indicated in the video examples?

[arngrim]

i think it's not linked to any value, you can try to remove the only value that it is in the knocker, but i don't think it will change anything, try it

[xantari]

Which value to do I remove? Is it a value in the tablemapping config file? I want to turn it off only for this one game (ST TNG).

Is there a way to turn on "extreme logging", the logging from DOF seems to be very minimal when I turn it on. 

What I'm looking for is all the events that happen, such as "Fire port 19 [Knocker] on PacLed64 for extra ball event"

[xantari]

I wonder if this has something to do with my problem, since i'm using a PacLed64 to control the outputs. This quote is from SwissLizard:

The Pacled64 has a global fadetime setting which influences how fast the value of the physical output changes when a output is set to a new value. DOF did not set this fade time para during initializtaion in the past. The resulted in a somewhat erratic behaviour of the Pacled64.

Now DOF does initialize that value with a fade time of 0 (DOF handles the fading on its own, not hardware fading support required) which make sure that the behaviour of the Pacled64 is now predictable and correct.

I wonder if that new code is working correctly.

[swisslizard]

Hi

Just got xantaris message through Github regarding the problems with the paclead64.

Sinc DOF R2 two things have changed in the Pacled implementation:

Fix for the Fadetime of the Pacled

This is a pretty trivial fix: The only change to the code is a new routine to set the fadetime of the pacled to 0.

private void ResetFadeTime()
{
   PDSingleton.PacLed64SetLEDFadeTime(Index, 0);
}

I doubt the the problems are related to this. At least in my cab the pacled64 does behave correctly since I've add this intialization. Before I had some strange behaviour since the pacled64 had always put his on fading logic on top of the effects.

Activation of logic to decide on full or partial updates on the Pacled64

The pacled64 has several commands which can update the outputs. There is a command for a full update which will set the values for all output and there is also a command which just updates a single output. The pacled64 controller class of DOF did always have a bit of extra logic to decide wether to do full updates or just updates on some single outputs. The reason for this is, that updating less than 30 single outputs is faster than sending a full update. There is also a flag which forces the code to do full updates regardless on the number of changed outputs (typically used on initialization of DOF). Sowhere along the way a have removed the code which resets that flag (dont remember why). The results in full updates all the time. This is slightly slower, but also much simpler than the partial update logic. Just checked the code and didnt find anything which looks wrong.

I'll build a DOF version where the mentioned flag is reset as it was in the past, so you can try if that fixes your problem.

 

 

 

[swisslizard]

As promised I have built/compiled a new DOF version with the reseting of the ForceFullUpdate flag back in place. On my cab things seem to work as expected.

Please download the following file, extract the contents to the DOF folder (dont forget to check if you need to unlock some files) and check and let me know if things work better like that:

http://pinball.weilenmann.net/DirectOutput_R3Beta_Build_6154_19933.zip

 

[xantari]

Thank you so much!!! I will try this tonight and report back.

[xantari]

Same issue is occurring. Knocker is firing in ST TNG on so many events.

I've attached the table, ROM, B2S file, and DOF log. Using Visual Pinball 9.92. Using PacLED64 based virtual output kit from Zebsboards.

I have also attached my configs folder from DOF. DOF log is in the DOF config folder.

I have also attached a debug log of B2SServer (this really slowed the refresh rate of virtual pinball down to unplayable levels, but I was able to get the knocker to fire a few times, MANY events were not working as expected due to the excessive slowdowns due to the B2SServer logging I enabled (enabled all LAMP, solenoid logging).

https://drive.google.com/open?id=0B__g7EhWQEETTS0zdy1zT1Ztb2s

 

 

[xantari]

Here is an additional video: https://www.youtube.com/watch?v=EnmdFDgUz40

This shows another strange behavior of DOF R3 and PacLed64.

It randomly is firing LED events as well. Notice I press the flipper button in ST TNG table, and it randomly fires RGB LED lights.

It's almost as if some sort of strobing effect is happening here, and DOF R3 is much more sensitive to that than R2.