Framework's Actions Under The Hood

[Spektre]

I was wondering what the Framework actually does under the hood so I'd understand the consequences of what I want to do to my .ini files.

 

Does it simply translate ROM switch calls to LED-Wiz calls or does it internally store ROM states?  If so, it is somewhat dependent on these lights never coming on at the same time, yes?

 

Let me give an example.

 

I map two ROM switches (ROM1, ROM2) to the same LED Output (we'll call it LED1 although it would be named something else in the config tool).

 

If the table's ROM sends these calls:  ROM1 ON, ROM2 ON, ROM1 OFF.  what is the state of LED1.  My guess would be the framework simply translates these calls and thus LED1 would be OFF even though you might think it would still be ON due to ROM2 never having been commanded OFF.

 

This has ramification for how I would like to combine certain outputs for my cabinet.  If I were to combine say STROBE and BEACON, into one physical light, the behavior might end up being a little strange.

 

Thanks.

[arngrim]

In your example, led1 will be on, rom1 off will not shutdown led1 because rom2 is still on

[arngrim]

But i don't really advise to use a led for strobe output, there are blinking effects with 10 ms, too fast for a simple led

[Spektre]

Wow, I'm impressed!  So the Framework actually keeps track of the various ROM switches listed in its .ini file and then OR's them together when making a determination when to send an output to the LEDWiz?

 

What happens if the ROM commands an LED on and another sends the same LED a PWM command?

 

----

 

As for the strobe, the first strobe I had seen as Chriz99's and if memory serves it was an analog strobe with its timing set at the light.  This is not the method chosen for the Strobe signal?

 

----

 

The reason for the question is to try and map what I can achieve with the config tool to what I have in my cabinet.

 

I do not have GEARS and SHAKERS, I have a separate device that I would like activated whenever either of those are.  If combine the GEARS and SHAKERS output, I assume then if it is OR'd that is what I would achieve?

 

I have a 3 LED configuration and as many of these are empty, I would like to simply combine the LO, and L outputs to my L flasher.  Likewise RO, and R to R flasher.

 

Finally I have an incandescent bright light I was hoping to combine STROBE and BEACON into.

[arngrim]

DOF is even more clever than that, suppose you have rom1 intensity32, rom2 intensity40, rom1 activated led1 = intensity32, then rom2 on = led1 i40, then rom2 off= led1 i32.

Layers are implemented like photoshop , you can define customize transparency for multiple rom events on led effects, the possibilities are amazing

For combining outputs in configtool, i don't know how configtool will react, did you try?

[Spektre]

Very nice implementation!

 

That would seem to work for what I have in mind.

 

As for the config tool, to the best of what I am seeing, it will not combine outputs like this and I will have to do it directly to the .ini file produced.

 

It would make for a nice enhancement though.  In the list for each channel you could simply add another channel.  You'd need to watch not to create circular references, and I don't know if anyone else is asking for this besides me.

 

So for example, you could define your left 3 blinker channel to be your left outside 5 blinker + left 5 blinker and so forth.

[swisslizard]

Hi

 

Here is a short explanation of the things which happen in DOF:

 

• The thread which sends and gets data from Pinmame is sending all data to the plugins of the B2S.Server (DOF is acting as such a plugin). In DOF all that data is immediately put into a queue and controll is returned to B2S.Server.
• In DOF the main thread will pop the received data from the queue and update a internal list of table elements (switches, lamps, solenoids and so on) whit those values. If the value of a table element changes, it will fire a event which calls one or several effects which are assigned to the table element (Table elements can have any number of effects, also 0, assigned).
• The called effects will call other effects or do some action on a toy. The possibility that a effect calls another effect, allows the combination of effects (e.g. if blinking and fading is combined, we get a slowly fading blinking). Have a look at the pics (and the text) on the following page to get a clearer idea: http://directoutput.github.io/DirectOutput/fx.html
  If a effect does no call another effect, it will likely talk to a toy and influence the toys state (e.g. set the color of a RGB led).
• The toys, which are as mentioned controlled by the effects, represent the hardware (RGB leds, contactors and so on) you have installed in your cabinet. Depending on their type, they offer different functionality. As a example the RGBA led toy  has extra functionality for the layer support which arngrim has mentioned. Have a look at the following picture for a clearer idea of the layer support: http://directoutput.github.io/DirectOutput/toy_builtin.html#use_DirectOutput_Cab_Toys_Layer_RGBAToy
  The toys are seting the values of one or several output objects (e.g. RBG leds use 3 outputs) to a value which depends on the toys state.
• Output objects do represent a physical output of a output controller (e.g. a LedWiz) in a cabinet. The outputs receive their values from toys to which they are assigned (kind of a software version of wiring a physical toy to a physical output).
  If a toy receives a new value, it will notify the output controller object to which it belongs.
• Last, but not least output controllers receive updates from the output objects and update their internal values based on these notifications. The output controller will send the new states to the connected hardware unit.
  In addition output controllers are typically having their own thread, which will handle all the "slow" communication with the real hardware. Like that even the slowest reacting hardware wont have any negative effect on the system performance.

When you use ini files for the config, DOF will translate the effect data in the files into series of stacked effects which are assigned to table elements as specifed in the files. If no cabinet config exists, DOF will also try (usually with good success) to configure the toys and output controllers automatically, based on detected hardware units (e.g. Ledwiz, PACDrive and Pacled64 can be auto detected) and also depending on the effect specifications in the ini files (e.g. if a effect specifies a color, the the toy it is talking to must be a RGB led or another toy supporting RGB).

 

All the best

 

Tom