(Topic ID: 239045)

Arduino Pinball Controller


By AmokSolderer

1 year ago



Topic Stats

  • 408 posts
  • 32 Pinsiders participating
  • Latest reply 1 day ago by buskimanu
  • Topic is favorited by 61 Pinsiders

You

Linked Games

No games have been linked to this topic.

    Topic poll

    “Are you using the APC and what's the reason if not?”

    • I'm using APC with MPF 3 votes
      19%
    • I'm programming APC natively 1 vote
      6%
    • I'm waiting for PinMame support 2 votes
      13%
    • I have an APC board, but I still have to populate it 2 votes
      13%
    • I would only use the APC if populated boards were available 8 votes
      50%

    (16 votes)

    Topic Gallery

    There have been 48 images uploaded to this topic. (View topic image gallery).

    989E9891-AFB6-4D75-91D4-6A2F553B0560 (resized).jpeg
    20200612_042150 (resized).jpg
    83A7645B-45D4-431C-A2DB-E31D696175C4 (resized).jpeg
    12F1FF58-9819-4B1F-B339-8BD8200B6C2E (resized).jpeg
    F3CB63D6-7F5B-4A95-9E56-CA83120B5FB1 (resized).jpeg
    Special switches (resized).png
    93228453_2653362271457574_8599175394525970432_n (resized).jpg
    92952976_267749924262581_1664119674796769280_n (resized).jpg
    93591922_222256769048155_2626677220843716608_n (resized).jpg
    20200412_002709 (resized).jpg
    20200407_142122 (resized).jpg
    20200327_015639 (resized).jpg
    90664882_670416317096916_7335818400859422720_n (resized).png
    Sys11c_display2 (resized).jpg
    Sys11c_display (resized).jpg
    89861870_618102045404449_5404839823707996160_n (resized).jpg

    There are 408 posts in this topic. You are on page 7 of 9.
    #301 3 months ago

    ok, I have 2 Dues. I updated both and tried MPF with the generic APC config from the MPF site. This is what I get:

    2020-04-02 14:29:18,717 : INFO : Machine : Mission Pinball Framework Core Engine v0.53.3
    2020-04-02 14:29:18,717 : INFO : Machine : Command line arguments: {'no_load_cache': False, 'create_config_cache': True, 'bcp': True, 'configfile': ['config.yaml'], 'mpfconfigfile': '/usr/local/lib/python3.7/dist-packages/mpf/mpfconfig.yaml', 'force_assets_load': False, 'jsonlogging': False, 'logfile': 'logs/2020-04-02-14-29-18-mpf-Ares.log', 'pause': False, 'production': False, 'text_ui': True, 'loglevel': 15, 'consoleloglevel': 20, 'force_platform': None, 'syslog_address': None, 'mc_file_name': None, 'no_sound': False}
    2020-04-02 14:29:18,717 : INFO : Machine : MPF path: /usr/local/lib/python3.7/dist-packages/mpf
    2020-04-02 14:29:18,717 : INFO : Machine : Machine path: /home/mlatiolais/pinball/stranger_things
    2020-04-02 14:29:18,717 : INFO : Machine : Platform: linux
    2020-04-02 14:29:18,717 : INFO : Machine : Python executable location: /usr/bin/python3
    2020-04-02 14:29:18,717 : INFO : Machine : Python version: 3.7.3 (64-bit)
    2020-04-02 14:29:18,717 : INFO : Machine : Machine config file #1: config.yaml
    2020-04-02 14:29:18,718 : INFO : ConfigProcessor : Loading config from cache: /tmp/d7568d6f98feaa7123aa03a54368bc0d.mpf_cache
    2020-04-02 14:29:18,720 : INFO : Machine : Initialise MPF.
    2020-04-02 14:29:18,790 : INFO : lisy : Connecting to /dev/apc_board at 115200bps
    2020-04-02 14:29:19,397 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:19,899 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:20,401 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:20,904 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:21,406 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:21,908 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:22,410 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:22,912 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:23,414 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:23,916 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
    2020-04-02 14:29:24,139 : INFO : EventManager : Event: ======'machine_var_lisy_hardware'====== Args={'value': b'', 'prev_value': None, 'change': True}
    2020-04-02 14:29:24,140 : INFO : EventManager : Event: ======'machine_var_lisy_version'====== Args={'value': b'', 'prev_value': None, 'change': True}
    2020-04-02 14:29:24,140 : INFO : EventManager : Event: ======'machine_var_lisy_api_version'====== Args={'value': b'', 'prev_value': None, 'change': True}
    2020-04-02 14:29:24,142 : INFO : Machine : Shutting down...
    2020-04-02 14:29:24,143 : INFO : EventManager : Event: ======'shutdown'====== Args={}
    2020-04-02 14:29:24,183 : ERROR : Machine : Failed to initialise MPF
    Traceback (most recent call last):
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 684, in initialise_mpf
    raise init.exception()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 240, in initialise
    await self.initialise_core_and_hardware()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 236, in initialise_core_and_hardware
    await self._initialize_platforms()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 327, in initialize_platforms
    result.result()
    File "/usr/local/lib/python3.7/dist-packages/mpf/platforms/lisy/lisy.py", line 435, in initialize
    if self.api_version >= StrictVersion("0.9"):
    File "/usr/lib/python3.7/distutils/version.py", line 70, in _ge__
    c = self._cmp(other)
    File "/usr/lib/python3.7/distutils/version.py", line 170, in cmp
    if self.version != other.version:
    AttributeError: 'StrictVersion' object has no attribute 'version'
    2020-04-02 14:29:24,185 : INFO : root : MPF run loop ended.

    As far as I can tell, both boards respond the same. This is the config I used:
    http://docs.missionpinball.org/en/latest/examples/apc/index.html

    #302 3 months ago

    Looks like it fails to connect.

    You already had the USB connection working last week when you did your switch test. Does this setup still work with these two DUE boards?

    Quoted from ThatOneDude:

    I updated both

    Did you update them with V0.13? V0.12 won't come up in USB mode.

    #303 3 months ago

    Interesting. I was using my mac to update until I set up this system. It seems to write faster and give me more debug info. I updated the code to V00.13, and it initialized, then failed with an exception:

    Shutdown because of an exception:
    Runtime Exception
    Traceback (most recent call last):
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 765, in run_loop
    raise self._exception['exception']
    File "/usr/lib/python3.7/asyncio/events.py", line 88, in run
    self._context.run(self._callback, *self._args)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/events.py", line 102, in async_handler_done
    future.result()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/device_manager.py", line 113, in load_device_modules
    self.load_devices_config(validate=True)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/device_manager.py", line 177, in load_devices_config
    config[device_name] = collection[device_name].validate_and_parse_config(config[device_name], False)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/device.py", line 104, in validate_and_parse_config
    self.config_section, config, self.name, "device", prefix=debug_prefix)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 292, in validate_config
    validation_failure_info, k))
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 320, in validate_config_item
    validation_failure_info)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 757, in validate_item
    return self.validator_list[validator](item, validation_failure_info=validation_failure_info, param=param)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 477, in validate_type_machine
    6)
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 776, in validation_error
    item, msg), 5 if code is None else code, self.log.name)
    mpf.exceptions.config_file_error.ConfigFileError: Config File Error in ConfigValidator: Config validation error: Entry autofire_coils:ac_slingshot:playfield = "playfield" is not valid. Device playfield of type playfields not defined Error Code: CFE-ConfigValidator-6 (https://docs.missionpinball.org/en/0.53/logs/CFE-ConfigValidator-6.html)

    I'll dig into the config to see if something looks amiss. This is on a board unconnected to the APC yet. Is there a chance that this version of MPF(v0.53.3) isn't compatible with 00.13?

    #304 3 months ago

    Found the playfield error by comparing Rollergames to the minimal one. Now, I'm back at the StrictVersion issue.

    Shutting down...
    Event: ======'shutdown'====== Args={}
    Failed to initialise MPF
    Traceback (most recent call last):
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 684, in initialise_mpf
    raise init.exception()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 240, in initialise
    await self.initialise_core_and_hardware()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 236, in initialise_core_and_hardware
    await self._initialize_platforms()
    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 327, in initialize_platforms
    result.result()
    File "/usr/local/lib/python3.7/dist-packages/mpf/platforms/lisy/lisy.py", line 435, in initialize
    if self.api_version >= StrictVersion("0.9"):
    File "/usr/lib/python3.7/distutils/version.py", line 70, in _ge__
    c = self._cmp(other)
    File "/usr/lib/python3.7/distutils/version.py", line 170, in cmp
    if self.version != other.version:
    AttributeError: 'StrictVersion' object has no attribute 'version'

    #305 3 months ago

    Ok, so I figured out what I'm seeing, but I'm not sure why.
    If I get the system to connect once, if it has a config issue, it will halt. And then any subsequent attempt to connect with MPF will fail. However, if I load the sketch again via the IDE, it will work again. Is there some flash or EEPROM being set that will stop the sketch from loading again?

    #306 3 months ago
    Quoted from ThatOneDude:

    Is there a chance that this version of MPF(v0.53.3) isn't compatible with 00.13?

    I'm not sure, but I'd go for the DEV version of MPF.

    Quoted from ThatOneDude:

    This is on a board unconnected to the APC yet.

    Quoted from ThatOneDude:

    And then any subsequent attempt to connect with MPF will fail.

    Try to press the Reset button of the DUE.
    I had DUEs that wouldn't start automatically after powerup. Therefore the APC has a capacitor that generates a power on reset, but when you use the DUE without the APC board you might have to press Reset manually to make it work.

    #307 3 months ago
    Quoted from ThatOneDude:

    Is there a chance that this version of MPF(v0.53.3) isn't compatible with 00.13?

    I am on 53.2 and it required 00.13 to work correctly. I get that StrictVersion error randomly once in a while. If I cycle the USB connector it usually works after that.

    Quoted from AmokSolderer:

    I had DUEs that wouldn't start automatically after powerup. Therefore the APC has a capacitor that generates a power on reset, but when you use the DUE without the APC board you might have to press Reset manually to make it work.

    Is that C14?

    #308 3 months ago
    Quoted from RatShack:

    Is that C14?

    Yep.

    #309 3 months ago
    Quoted from ThatOneDude:

    File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 327, in initialize_platforms
    result.result()
    File "/usr/local/lib/python3.7/dist-packages/mpf/platforms/lisy/lisy.py", line 435, in initialize
    if self.api_version >= StrictVersion("0.9"):
    File "/usr/lib/python3.7/distutils/version.py", line 70, in ge__
    c = self._cmp(other)
    File "/usr/lib/python3.7/distutils/version.py", line 170, in cmp
    if self.version != other.version:
    AttributeError: 'StrictVersion' object has no attribute 'version

    Hi guys,

    That looks like an error in MPF. It might be caused by LISY but ultimately MPF should log something useful here. I will have a look and fix it.

    Jan

    #310 3 months ago
    Quoted from jabdoa:

    Hi guys,

    That looks like an error in MPF. It might be caused by LISY but ultimately MPF should log something useful here. I will have a look and fix it.

    Jan

    Thank, Jan. I was the one posting about the debian buster problem on the mailing list.

    So, this is what I have found. I have to unplug and replug the USB connection to allow MPF to communicate with the Due. Once I've done that, assuming that I have a valid config, the system will work. Not sure if it dies after the loss of the watchdog or something of that nature. It has to be something with the Due, since reprogramming it with the IDE also fixes the problem.
    Regardless, now that I can get that working, I'll be able to properly test the switch matrix. Then, I'll finish populating this board. I also have to build a couple more APC boards, and my fellow homebrewers are getting excited.

    EDIT: to clarify.
    When I first plug in the board or reprogram it, I can connect MPF to it. After that, I have to unplug/replug or program it to get it to talk to MPF. Doing a ctrl-c to kill MPF and then attempting another run will fail every time. Hitting reset doesn't help, either.

    #311 3 months ago

    I handled that case in MPF 0.54.0-dev.19. It only happens when LISY returns an empty API version to MPF which probably indicates some kind of communication error. In dev MPF will retry similar to the handling of resets failures. Not sure if this helps. At least not in case the hardware crashed or if USB has connection issues.

    Jan

    #312 3 months ago

    I was able to find some time to test the switch matrix tonight. Everything looks good. Going to finish this board and start testing in game.

    #313 3 months ago
    Quoted from ThatOneDude:

    I've already hacked pinmame to draw to a dmd using the raspberry pi gpio pins.

    Would you share the source for that hack ?

    #314 3 months ago

    Hi guys,

    we're currently facing one (hopefully) last problem with our PinMame implementation and I'd like to ask for your help to gather the required information to solve this.

    So far everything works well with PinMame controlling my Pinbot except for the music channel.
    Apparently PinMame distinguishes two sound boards (channels) and sends codes (bytes) to those. In case of the sound channel this seems to be quite straight forward and we were able to link every code to a sound to be played. This is already working quite well.
    However, in case of the music channel things are different as most of the codes being sent to this channel are not linked to a certain music score, but seem to be commands for the music board itself. At the moment this causes the APC to stop playing the current music file and complain about a missing music file instead.

    Alas, we havent been able to find any information about these 'command codes' for the music boards. For the APC we're mainly interested in the codes for Williams boards, but Bontango is having similar issues with Gottlieb https://pinside.com/pinball/forum/topic/gottlieb-system80b-soundboard-extended-sound-set , so any kind of information is welcome.

    #315 3 months ago

    I answered on Flippertreff too, but this might be the most useful link to some code in the FreeWPC repo...

    https://github.com/bcd/freewpc/blob/v1.2/include/system/sound.h#L30

    #316 3 months ago
    Quoted from AmokSolderer:

    Hi guys,
    we're currently facing one (hopefully) last problem with our PinMame implementation and I'd like to ask for your help to gather the required information to solve this.
    So far everything works well with PinMame controlling my Pinbot except for the music channel.
    Apparently PinMame distinguishes two sound boards (channels) and sends codes (bytes) to those. In case of the sound channel this seems to be quite straight forward and we were able to link every code to a sound to be played. This is already working quite well.
    However, in case of the music channel things are different as most of the codes being sent to this channel are not linked to a certain music score, but seem to be commands for the music board itself. At the moment this causes the APC to stop playing the current music file and complain about a missing music file instead.
    Alas, we havent been able to find any information about these 'command codes' for the music boards. For the APC we're mainly interested in the codes for Williams boards, but Bontango is having similar issues with Gottlieb https://pinside.com/pinball/forum/topic/gottlieb-system80b-soundboard-extended-sound-set , so any kind of information is welcome.

    WPC89 machines use a mixture of 8bit and 16bit sound commands. If the first byte is e.g. 0x7A the soundboard waits for a second byte. Maybe a look at the snd_alt.h helps.

    #317 3 months ago
    Quoted from lucky1:

    Would you share the source for that hack ?

    Sure thing. My fork of pinmame is here: https://github.com/mikelatiolais/pinmame_fork
    I update the dmd in wpc.c line 402. That's calling the code in src/oppa.
    Keep in mind that this is fairly old and had issues. I was in the process of moving it out to a thread based model when I decided to drive it with a smart matrix instead. I may have committed some broken code, so you might want to check out other revisions if you have trouble. Also, this was still using wiringpi, and I planned on moving to another gpio library.

    It's pretty straightforward. I just used the Vishay datasheet to make a quick function to take the DMD array and fill.

    #318 3 months ago
    Quoted from Snux:

    this might be the most useful link to some code in the FreeWPC repo...

    That's going to be an interesting read. Of course for us the major question is how much of this is also valid for System11 audio boards.

    #319 3 months ago

    Got the flipper board working. Was able to play through some full games without the insert lights. Running like a champ!

    20200407_142122 (resized).jpg
    #320 3 months ago

    Oh yeah. You have my vote for the 'master of breadboarding' challenge

    What do you plan to do next?
    V0.13 now features the WriteToHwExt command for controlling the HW extension port. This could help you to control the lamps, but up to now it's not documented.

    #321 3 months ago
    Quoted from AmokSolderer:

    Oh yeah. You have my vote for the 'master of breadboarding' challenge
    What do you plan to do next?
    V0.13 now features the WriteToHwExt command for controlling the HW extension port. This could help you to control the lamps, but up to now it's not documented.

    Next is assembling the lamp driver board. It decodes the lamp matrix into 64 discrete outputs and uses the existing lamp driver lines with new code.

    It's going to be a lot of work, that's for sure. At least it does it with half as many parts as the 80B driver!

    #322 3 months ago
    Quoted from RatShack:

    uses the existing lamp driver lines with new code.

    If you use 74HCT377 as buffers for 8 lamps each, you wouldn't even need new code IMHO. You could spare U3 and U5 of the APC and use the outputs of U6 to enable the new 74HCT377 ICs. Sel0 could still act as a clock for all of those.

    #323 89 days ago
    Quoted from AmokSolderer:

    If you use 74HCT377 as buffers for 8 lamps each, you wouldn't even need new code IMHO. You could spare U3 and U5 of the APC and use the outputs of U6 to enable the new 74HCT377 ICs. Sel0 could still act as a clock for all of those.

    Probably didn't need to change it, I fought getting the design to work, in true Gottlieb style my problem was inadequate ground between the light board and the Due. I wanted to eliminate the light dimming code at first while I got it running.

    I am using 74HCT377 as buffers for ROW and COL, and a 74HCT374 to buffer each group of 8 lamps, clocked by COL.

    #324 88 days ago

    Finally had the time to finish the soldering.

    20200412_002709 (resized).jpg
    #325 88 days ago
    Quoted from RatShack:

    I wanted to eliminate the light dimming code at first while I got it running.

    You mean the DimInserts setting? Yes, that doesn't make much sense in your case.
    Similar situation with the LampWait counter. You could either remove it or use it to specify a refresh rate for the lamps. The latter would spare a few cycles of processing power, but it's almost nothing.

    Quoted from ThatOneDude:

    Finally had the time to finish the soldering.

    If you face a problem during testing, please promise to keep your soldering iron holstered and give me a chance to guide you through the debugging process first.

    #326 88 days ago
    Quoted from AmokSolderer:

    If you face a problem during testing, please promise to keep your soldering iron holstered and give me a chance to guide you through the debugging process first

    Sure. I'll be building another one shortly, too.

    #327 85 days ago

    Ok, so when testing the switches I saw something odd.
    I set up 64 switches in a generic manner:
    s_00:
    number: 00
    s_01:
    number: 1
    ...
    s_64:
    number: 64

    I see a couple of problems. For example, s_00 is always showing as activated, and s_08 doesn't activate at all. The odd thing is, different combinations using those pins works, so this isn't a bad column or row.
    Anything I should be looking for?

    #328 85 days ago

    I remember you had tested the switches successfully with this APC board. That means we can exclude any board related issues, right?

    If you run

    mpf -b -v
    MPF will write a more detailed log into your logs folder. It shows the whole USB traffic between MPF and APC.

    Command 0x28 queries a specific switch and 0x29 returns the number of a switch that has changed it's state recently.
    Consult the Lisy protocol reference for details :

    docs.missionpinball.org/en/dev/hardware/lisy/protocol.html

    #329 85 days ago
    Quoted from AmokSolderer:

    I remember you had tested the switches successfully with this APC board. That means we can exclude any board related issues, right?

    I'm not going to completely rule that out, but given the fact that other combinations work, I'm going to start with the assumption that I've messed up the config file somehow.

    #330 85 days ago

    Update: I ordered some of the Siegecraft testing boards which are showing as "out for delivery" right now, so I'm going to do a more systematic switch testing this evening. This will also give me a chance to test the solenoids and lamps. I'll try to post my testing methodology for anyone that might need it going forward.
    I've gotten the Smartmatrix to display with MPF now, so I will be setting up a simple config that uses both platforms. This is my expected configuration for the custom games(though I am now thinking about using another APC board to control Jokerz! instead of repairing the original MPU. The problem is that I've never played Jokerz!, so I don't actually know the rules...). The second thing I'm doing is going back to my pinmame work and moving from a direct gpio based DMD drive to the Smartmatrix, so that I can migrate that into the pinmame->APC project.

    #331 85 days ago
    Quoted from ThatOneDude:

    I'll try to post my testing methodology for anyone that might need it going forward.

    That could be quite helpful.

    Talking about Jokerz!
    I just learned that this machine uses a unique audio board which is able to generate stereo sounds. I was not aware of that and it has some impact on the use of the APC. The HW of the APC is able to generate stereo sounds, but the speakers must be connected with caps (DC-blocks) in this case. I have to include a warning about this in the documentation. Also the SW is only able to deal with mono signals at the moment.
    So be careful when connecting your Jokerz! speakers to the APC.

    #332 84 days ago

    Ok, quick escape to the project during lunch. Since the switch matrix responded to s_01 where I expected it to activate s_00, I went ahead and deleted s_00 and added s_64. Then, I tested each combo. Again, switch 8 is unresponsive, but all other switches seem to be working. I would expect to see every eighth switch be unresponsive if it were an entire column or row. So, this is a slight mystery. I'll do a more in-depth test tonight. jabdoa, is there something in MPF or the APC platform that could explain this?

    I also have the special solenoid driver and a solenoid tester, so I'll be testing all of the solenoids tonight. I'll take some pictures of the setup, and maybe a video. Depends on how ambitious I get tonight.

    #333 84 days ago

    In case anyone is unfamiliar with the testing tools I mentioned.

    92952976_267749924262581_1664119674796769280_n (resized).jpg93228453_2653362271457574_8599175394525970432_n (resized).jpg93591922_222256769048155_2626677220843716608_n (resized).jpg
    #334 84 days ago
    Quoted from ThatOneDude:

    is there something in MPF or the APC platform that could explain this?

    Probably a typo in the config file. A missing space or a tab instead of a space - something like this in the definition of s_08. MPF is very picky with the syntax.

    #335 84 days ago

    No, I rewrote it and even copied s_07 and just changed the name and switch number with no change.
    Nevermind on the other stuff. That's the watchdog. I'll dig in more.
    ---
    Ok, took a few minutes to look at it more closely. I see no activity from the MPF side when I hit s_08.

    #336 84 days ago

    Actually, I just looked up the USB_SwitchHandler. It's basically a switch statement.
    It looks to me like switch 8 can't be activated as a normal switch:


    case 8: // high score reset
    digitalWrite(Blanking, LOW); // invoke the blanking
    break;

    Unless there is a reason not to, shouldn't this be treated as a normal switch in addition to the blanking? Catch the 8 in the default case and just add an if to do the blanking? I could fork it and send in a pull request if that sounds sane.

    #337 84 days ago

    Ooops, sorry - I should have remembered this.
    The High Score Reset is my blanking button. I use it mainly as an emergency stop which releases all coils and clears displays and lamps. And I use it when writing a new SW to the Arduino.
    The reason for the latter is that if you program the Arduino while the APC is running in your pinball, the SW is being stopped and the reset kicks in. But there is a delay between both events which causes the lamp and display matrix to stop for some ms at a certain position. Therefore the displays and lamps can produce a short bright flicker. This is not necessarily harmful, but they‘re not going to like it either.
    That‘s why I‘m pressing High Score Reset before I write a new SW to the Arduino.

    However, as you‘re using MPF there‘s no need for you to reprogram the Arduino, so you might as well comment out case 8 and use switch 8 for something different.
    But if the blanking is invoked once it can only be released by a system reset, so you have to choose whether you keep it as a blanking or use it differently.

    #338 83 days ago

    I tried out the special solenoid tester after adding switches 65 - 72, and it seemed weird. So, I pulled it off and ran a ground jumper on each pin. Not all of the pins responded. I believe 65 - 69, and they weren't in order(65 on first pin, 66 on next, etc). What's the expected pinout of the special solenoid switches?"
    Also, shouldn't these be causing the special solenoid pins to ground? I put the LED tester on the special solenoids, and none of them lit up. I thought that this should happen without MPF intervention.
    I'll add all of the solenoid outputs to the MPF config today and see if I can some responses.

    #339 83 days ago
    Quoted from ThatOneDude:

    What's the expected pinout of the special solenoid switches?

    The order of these switches is weird indeed, but it's still original.
    I have attached the corresponding part of a Williams Sys7 manual. The switch number is stated on the left, so pin 2 is for switch 3 and so on.

    The switches 71 and 72 are Special. 71 is the memory protect button and 72 is the Advance button.

    Quoted from ThatOneDude:

    Also, shouldn't these be causing the special solenoid pins to ground?

    No, the APC treats them as normal switches, so you have to define a 'Hardware Rule' in MPF to make the special solenoids respond to them.

    Special switches (resized).png
    #340 82 days ago
    Quoted from AmokSolderer:

    I have attached the corresponding part of a Williams Sys7 manual.

    I'm sorry, I should have thought to look that up. In my defence, I didn't get a chance to test until after midnight, so I was a bit foggy.
    All of the expected switches work. For some reason I had it in my head that 71 and 72 were on there are well.

    Quoted from AmokSolderer:

    No, the APC treats them as normal switches, so you have to define a 'Hardware Rule' in MPF to make the special solenoids respond to them.

    This clears up a lot. I'll set up rules for the solenoids to start testing.
    I also need to build a lamp matrix. Siegecraft was out of stock. EDIT: Nevermind, my idea about the 16 LED version wouldn't work.

    #341 82 days ago
    Quoted from ThatOneDude:

    I also need to build a lamp matrix

    You could still put it in your BK2K.
    Since your displays aren‘t working you‘d have to change the APC_defaults in APC.ino. If you change the second byte from 3 to 0 the system will come up in the BaseCode which cycles the lamps from 1 to 64 as some basic attract mode.

    In order to do this your APC_defaults have to look like this:

    const byte APC_defaults[64] = {0,0,3,1,0,0,0,0, // system default settings
    0,0,0,0,0,0,0,0,
    0,0,0,0,0,0,0,0,
    0,0,0,0,0,0,0,0,
    0,0,0,0,0,0,0,0,
    0,0,0,0,0,0,0,0,
    0,0,0,0,0,0,0,0,
    0,0,0,0,0,0,0,0};

    #342 80 days ago

    Working on testing the solenoids. I used a simple setup on MPF:

    #config_version=5

    hardware:
    platform: lisy

    lisy:
    connection: serial
    port: /dev/ttyACM1
    baud: 115200

    switches:
    s_left_flipper:
    number: 1
    s_right_flipper:
    number: 2

    coils:
    c_flipper_left_main:
    number: 1
    c_flipper_left_hold:
    number: 2
    allow_enable: true
    c_flipper_right_main:
    number: 3
    c_flipper_right_hold:
    number: 4
    allow_enable: yes

    playfields:
    playfield:
    tags: default
    default_source_device: None # use None in steps before 8

    flippers:
    left_flipper:
    main_coil: c_flipper_left_main
    hold_coil: c_flipper_left_hold
    activation_switch: s_left_flipper
    enable_events: machine_reset_phase_3
    right_flipper:
    main_coil: c_flipper_right_main
    hold_coil: c_flipper_right_hold
    activation_switch: s_right_flipper
    enable_events: machine_reset_phase_3

    (pinside mangles the spacing, but it's correct on the original)

    I expect to see one of my test LEDs light up, but I get nothing. The switches activate and deactivate as expected. Any ideas?

    #343 80 days ago

    I'm not sure which USB commands MPF uses to control these modern flipper fingers, but there's a good chance that it won't work with the APC. That's because all Williams games prior to WPC use a simple flipper relay.
    Therefore the correct way to enable the flipper fingers for these old games is:

    digital_outputs:
    game_over_relay:
    number: 25
    type: driver
    enable_events: ball_started
    disable_events: ball_will_end

    This will activate the Solenoids 23 and 24. You can take a look at the config of my Basic Rollergames Setup for the correct spacings.

    https://github.com/AmokSolderer/APC/tree/master/DOC/Software/MPF/Rollergames

    A simple way to trigger a solenoid is to add a pulse_event to it's definition:

    c_lock_diverter:
    number: 8
    default_pulse_power: 1
    default_pulse_ms: 2000
    pulse_events:
    balldevice_bd_lock_ejecting_ball

    #344 80 days ago

    This is still bench testing, so there is no machine. I wanted to verify that each solenoid output will pulse with an LED prior to plugging this into a machine.
    So, what I'm wanting to do is enable a bank of 8 solenoids that I can then activate with 8 switch events. Barring that, tying a single solenoid firing to a single button will do.
    I'll experiment with pulse_events today. Are these defined somewhere? I don't see balldevice_bd_lock_ejecting_ball being defined in your configs, so I assume that the naming convention is defined by MPF.

    #345 80 days ago
    Quoted from ThatOneDude:

    This is still bench testing, so there is no machine. I wanted to verify that each solenoid output will pulse with an LED prior to plugging this into a machine.

    Yeah, got that. That's why I suggested the pulse_event. It took my quite a while to find that in the MPF docs and I found it to be very useful for testing.

    Quoted from ThatOneDude:

    I'll experiment with pulse_events today. Are these defined somewhere? I don't see balldevice_bd_lock_ejecting_ball being defined in your configs, so I assume that the naming convention is defined by MPF.

    Oh, right. If you want to see the corresponding config you have to look into the V0.13 branch.
    I hope it's only a few days before I can do the new release. The current master branch is rather outdated.

    #346 80 days ago
    Quoted from AmokSolderer:

    Oh, right. If you want to see the corresponding config you have to look into the V0.13 branch.
    I hope it's only a few days before I can do the new release. The current master branch is rather outdated.

    I pulled V00.13 and this is the only reference I find:
    $ grep -R balldevice *
    Rollergames/config/config.yaml: balldevice_bd_lock_ejecting_ball: 0.5s

    How does MPF know what balldevice_bd_lock_ejecting_ball is? Does it parse the string and figure out that this is referring to the bd_lock ball device?

    #347 79 days ago
    Quoted from ThatOneDude:

    Does it parse the string and figure out that this is referring to the bd_lock ball device?

    Yes, that's it You can find the corresponding help page here

    http://docs.missionpinball.org/en/latest/events/balldevice_name_ejecting_ball.html

    BTW, I'm still an MPF noob myself, but I think I know how you feel right now. I remember that I was totally confused after completing the tutorial by all the events and devices. I was missing some kind of golden thread leading me through all of this.
    However, for me it got a lot better after I found out how much information is available in the 'Reference' part of the docs. Especially the 'Config File Reference' is most helpful, because you can see the events and options for a particular device.

    #348 79 days ago

    AHA! That's what I was missing!
    http://docs.missionpinball.org/en/latest/events/index.html

    I searched through that page for a while and couldn't find that index. Weird.
    ok, I'll spend some time today trying different things. I don't expect to see any weirdness with the solenoids, but I want to doublecheck before I start using it in my first custom machine. I am using Fadecandy for the inserts and Smartmatrix for the DMD, so my board will work fine as long as I have switches and solenoids working properly with MPF(and, eventually, pinmame. But I need to add smartmatrix support into it first).

    #349 79 days ago

    Possibly a stupid question, but the coils on APC are labeled numbers 1 to 24, correct?

    #350 79 days ago

    Yes, correct. But if you're looking for a particular solenoid to probe, you have to consider that the 'Solenoid Drivers 1' connector is in the middle. So the order of the pins might be different than you expect.

    Promoted items from the Pinside Marketplace
    $ 99.99
    Playfield - Toys/Add-ons
    Lighted Pinball Mods
    From: $ 9.99
    Eproms
    Matt's Basement Arcade
    $ 16.00
    $ 339.00
    $ 29.25
    Cabinet - Armor And Blades
    The MOD Couple
    $ 999.00
    Pinball Machine
    Mircoplayfields
    $ 7,399.00
    Pinball Machine
    Nitro Pinball Shop
    From: $ 19.99
    Eproms
    Matt's Basement Arcade
    $ 5.00
    Playfield - Decals
    Doc's Pinball Shop
    $ 65.00
    Playfield - Toys/Add-ons
    G-Money Mods
    From: $ 42.00
    Cabinet - Shooter Rods
    ModFather Pinball Mods
    From: $ 40.00
    Various Novelties
    Pinball Photos
    $ 5.00
    Playfield - Toys/Add-ons
    UpKick Pinball
    $ 5,899.99
    Pinball Machine
    Pinball Pro
    $ 154.00
    Cabinet - Toppers
    Id Rather Play Pinball
    $ 55.00
    Gameroom - Decorations
    Pinball Photos
    $ 109.95
    Cabinet - Sound/Speakers
    Pinball Pro
    $ 3.50
    Playfield - Protection
    Pinball Mod Co.
    From: $ 6.50
    Hardware
    Pinball Haus
    $ 45.00
    Playfield - Toys/Add-ons
    Docquest Pinball Mods
    From: $ 14.00
    Playfield - Toys/Add-ons
    ModFather Pinball Mods
    $ 999.00
    There are 408 posts in this topic. You are on page 7 of 9.

    Hey there! Got a moment?

    Great to see you're enjoying Pinside! Did you know Pinside is able to run thanks to donations from our visitors? Please donate to Pinside, support the site and get anext to your username to show for it! Donate to Pinside