Using sw_flip_events on a flipper config doesn't allow you to override pulse time.

[kaydeeH]

Given the example config below:

coils:
    c_flipper_a_hold :
        number: 1616_2-11
        default_pulse_ms: 40
        default_hold_power: 0.7
        tags: coils
     c_flipper_a :
        number: 1616_2-12
        default_pulse_ms: 21
        tags: coils

flippers:
    flipper_a:
        main_coil: c_flipper_a
        hold_coil: c_flipper_a_hold
        activation_switch: s_flipper_a_button
        enable_events: e_active_event
        disable_events: e_inactive_event
        sw_flip_events: e_special_condition_flip
        sw_release_events: e_special_condition_deflip

When the e_special_condition_flip event is received, the flipper only pulses the main coil for the coil's configured default_pulse_ms time, which may not be enough "juice" to get the flipper to actuate enough for the hold coil to grab it, resulting in a non-flip (though the flipper buzzes like it's trying until the e_special_condition_deflip event is received). It would be ideal if you could configure an override pulse time for sw_flip_events. Perhaps like the following:

flippers:
    flipper_a:
        main_coil: c_flipper_a
        hold_coil: c_flipper_a_hold
        activation_switch: s_flipper_a_button
        enable_events: e_active_event
        disable_events: e_inactive_even
        sw_flip_events: e_special_condition_flip
            main_coil_pulse_time_ms: 500
            main_coil_pulse_power: .7
        sw_release_events: e_special_condition_deflip

It may also be worthwhile to be able to specify hold settings along with main coil settings, but this doesn't seem to be the core of the issue as the hold coil's default settings are likely not an issue in this use case.

I tried getting around this with coil_player and that worked great on the virtualized hardware, but it has limits on pulse time on actual Fast hardware (see #1923) so that didn't work.

The only way I could get this to work was to use enable_events and disable_events on the main and hold coil configs directly combined with allow_enable=true, which force pulses the coil at full power until the disable event is received. It's not an ideal workaround, but it gets the job done.

But, without being able to specify a main coil pulse time override for the sw_flip_events config on a flipper, I'm not sure there's a lot of practical use for that feature.... unless I'm missing something.

[bosh]

I haven't used this feature myself, so maybe it does not solve your problem -- does your proposed feature function differently than main_coil_overwrite?

[kaydeeH]

When I added the following to the flipper config it had no effect. The coil still pulsed at the default pulse time defined for the coil. I'm less confident I used it right, but that may be another bug on its own.

main_coil_overwrite:
    pulse_ms: 1000

I forgot I had tried this when I wrote up the bug, and thus forgot to mention that if it worked it would probably negate the need for my suggested changes.

[bosh]

It looks like sw_flip_events bindings (handled by flipper:event_sw_flip

mpf/mpf/devices/flipper.py

Line 271 in 7958c06

if self.config['hold_coil']:

) do not look up the overwrite values when sending pulse+enable . You could probably reuse how the other functions look up overwrite values, like

mpf/mpf/devices/flipper.py

Line 156 in 7958c06

pulse_ms = self.config['main_coil_overwrite'].get("pulse_ms", None)

to improve the calls being made to mail/hold_coil.pulse(), which looks like it would accept the values already

mpf/mpf/devices/driver.py

Line 332 in 7958c06

def pulse(self, pulse_ms: int = None, pulse_power: float = None, max_wait_ms: int = None) -> int:

I'd be happy to help if you get a PR most of the way there

[kaydeeH]

Thank you for finding the root of the issue. Unfortunately I don't have nearly the confidence in my python coding skills (beginner at best) to get in and monkey with this, nor am I set up for submitting PRs. I know it's kind of a weak excuse, but I'm not the right person to be making a change like this.

[bosh]

I think you'll surprise yourself if you do give it a shot! The hardest part will be the automated tests, which you can ignore to start, since you have a physical implementation to test with. (And I can help fill in the code tests later).
As for pull requests, you're actually most of the way there just by having a github account + already knowing git commands; the rest is just pressing the Fork button on the MPF repo page and adding your fork as a remote (all explained in this guide: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo?tool=webui#forking-a-repository ). Then the pull request feature pops up on github UI whenever you push a branch with changes to your fork.