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

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?

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'

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?

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.

Is that C14?

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.

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

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.

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

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.

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

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!

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.

Finally had the time to finish the soldering.

20200412_002709 (resized).jpg

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

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?

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.

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.

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.

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

92952976_267749924262581_1664119674796769280_n (resized).jpg

93228453_2653362271457574_8599175394525970432_n (resized).jpg

93591922_222256769048155_2626677220843716608_n (resized).jpg

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.

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.

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.

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.

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.

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

#config_version=5

hardware:
platform: lisy

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.

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?

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).

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