Difference between revisions of "OPP Autofire Workaround"
Tfulenwider (talk | contribs) |
Tfulenwider (talk | contribs) |
||
Line 29: | Line 29: | ||
==== Example: ==== | ==== Example: ==== | ||
− | Check here for an example config with dummy devices: | + | Check here for an example config with dummy devices: [https://github.com/cobra18t/CobraPin/blob/main/Errata/OPP_AutoFire_Workaround.yaml OPP_AutoFire_Workaround.yaml] |
Revision as of 00:30, 20 December 2022
Under Construction... stand by for greatness.
Contents
Issue:
A bug was introduced in OPP firmware version 2.3.0.0 and persisted through 2.3.0.5. Under certain conditions, when you reconfigure an autofire coil, the coil can get stuck on.
The most common instance of this bug is when a dual coil flipper is configured with 100% hold power. If the flipper button is held while the ball drains, the flipper autofire device is disabled and the state of the flipper is frozen instead of reset to off. So after a drain, the flipper remains on even after the flipper button is released. When the next ball starts, the flipper device is re-enabled and all goes back to normal.
Similarly, if you have single coil flippers with 8% hold power, you have an 8% chance of seeing the bug if you hold the flipper button as the ball drains. While less likely than the dual wound case, this single wound condition is much worse since a coil intended for an 8% hold could get stuck on at 100% power. This will likely blow a fuse, transistor, coil, etc.
Options:
A) Flash new OPP version 2.x.x.x
A new firmware fix is currently in the works, but in the meantime, consider one of the other workaround options.
B) Add Dummy devices in MPF:
If you can prevent disabling an autofire device, you will not see this bug. One method of doing this is to setup a dummy autofire device in MPF. This method requires one unused direct input (two if your autofire devices span across both STM32 processor boards). You must create a dummy autofire device for each autofire device in your machine but all the dummy devices can use the same switch.
Pros:
- No firmware flashing
- Simple MPF config change
Cons:
- Requires an unused direct input (potentially two if your autofire devices span across both STM32 processor boards)
- Requires user to account for each autofire coil so the user could accidentally miss one in the MPF config
- Could unintentionally fire coils from the dummy device if you accidentally connect the dummy switch to something
- There could be a form of config where this does not protect the bug from appearing
Example:
Check here for an example config with dummy devices: OPP_AutoFire_Workaround.yaml
C) Revert to OPP version 2.2.0.0:
This bug did not exist in OPP version 2.2.0.0. Consider flashing 2.2.0.0 to your STM32 processors if you do not use the following features that were introduced after 2.2.0.0:
- Coil pulse power (kick PWM)
- RC servo support
- SPI LED support (APA102, SK9822, etc.)
Pros:
- Regression tested version
- No config changes or vulnerabilities
Cons:
- Flashing new firmware requires an STM32 programmer, STLINK software, and python 2.7 setup to run OPP configuration
- No longer have the most recent firmware features
Instructions for loading firmware:
Be sure to use the OppStm32.2.2.0.0.hex file from here: Gen3Images
There are a couple versions of these instructions: