APC in F-14

[bontango]

vor 12 Minuten schrieb Snux:

I've removed my workaround and there is no unexpected coil activation at startup.

🙂

vor 13 Minuten schrieb Snux:

have to say I do not know what the patch was supposed to do, but my F14 still se

pinmame did update the internal solenoid table only each second blanking pulse.

With PROC this was changed to do it with each blanking pulse, now it is the same with LISY

[Snux]

I was thinking about the best way to mount the APC board in the F14 backbox.  I've seen photos of pieces of wood screwed together but wanted something a little neater.  Then I remembered I still have a few blank PCBs from the board I used to make that interfaced with the P-ROC.  I designed that board to use the existing mounting points that the Sys11 MPU used.  So drilled 4 holes in a spare PCB, mounted the APC to it with some short spacers and it fits in the backbox nicely.  You can also see some micro-SD extension cables I'm using so I can access the cards without needing to fight the cables.

Now I need to make a few extension cables for the Sys11 wiring as some of the connections are really tight.

[Black Knight]

Good idea.

Ralf has done something similar on the 3D printer for his System9 'Comet'.

vor 31 Minuten schrieb Snux:

You can also see some micro-SD extension cables I'm using

I'm suprised that you don't get any problems with those. Do you keep them away from 'aggressive' wires like solenoid drivers?

[Snux]

On 1/25/2022 at 5:36 PM, Black Knight said:

I hope that the results feels like an F-14, which would mean I could add this machine to the 'works with PinMame and sounds are available' list?

Yes, I played quite a few games over the last few days after adjusting a few switches.  I played a lot with the glass on, and then some with the glass off to cheat and get multiball / jackpot etc.  It 100% feels like F-14 should, which is great, and I think the exceptions code is handling the sounds properly now too.  Feel free to add the machine to the list.  You can put me as the source for the sounds.

There are a few little things between @Black Knightand @bontangothat could go on the "very low priority" list......

- Because of the hardware/switch rules that Pinmame is setting up for the special solenoids, they remain active when the game is over.  I don't think it matters, it just seems odd that the pop bumper and slings fire when the machine clears locked balls after the game.  On the original Sys11 MPU (and the board I built) the special solenoid switches only work if the flipper enable relay is active.  So if we want 100% accurate stuff, either pinmame should send through HW resets when disabling the flippers, or (probably best) APC should just ignore the special solenoid switch inputs when the flippers are inactive.  That would also be fairly simple to put in the pinmameexceptions code as an alternative.

- When in pinmame settings, you can hold down the coin door button to fast forward through the list of settings.  However if you do that you end up starting the APC settings routine.  It's not a big issue at all, but maybe we trigger APC settings a different way, at least when Pinmame is running?  Maybe have to hold down one of the coin switches while pressing the settings button or something.

- I think I might set up a HW rule for the left outlane kickback.  95% of the time it's fine, but on occasion a fast ball gets through before it fires.  Although probably on a real MPU that's possible too.  I'll maybe add something to the exceptions code to monitor the kickback lamp and set a rule if it's on, I remember putting something into pinmame once to set that up for P-ROC but in this case it'll be easier in the APC exceptions code. 

[Black Knight]

vor 21 Stunden schrieb Snux:

That would also be fairly simple to put in the pinmameexceptions code as an alternative.

Yeah, that would probably be the easiest way to do it. I think most people don't care about this, but those who do would have to change it in a PinMameException. I guess I should add some example code in the DOCs.

vor 21 Stunden schrieb Snux:

It's not a big issue at all, but maybe we trigger APC settings a different way, at least when Pinmame is running?

I thought about this, but didn't really come up with a good alternative. If you have something in mind just shoot.

However, there's a trick. The APC Settings are only triggered when the Advance button is pressed while the Up/Down switch is in UP position. That means if you browse the PinMame menu backwards you can keep Advance pressed as long as you like.

vor 21 Stunden schrieb Snux:

I'll maybe add something to the exceptions code to monitor the kickback lamp and set a rule if it's on

I did this in MPF for my Rollergames and I think after that the kickback was too fast on occasion, so you might have to introduce a certain delay. 
May be it makes sense to wait with this until I've introduced the Priority Timers for Kobza. Then you'd have a reliable time base which is independent from the system workload.

[Snux]

3 hours ago, Black Knight said:

but those who do would have to change it in a PinMameException.

I put this into my F14 exception code, seems to be working fine..

  case SwitchActCommand:                              // Check for switches
    if (Command > 64) {                               // If special solenoid switch
      if (QuerySolenoid(24))                          // Check if the flippers are active
        return(0);                                    // If they are active then permit the switch
      else
        return(1);                                     // otherwise block it
    }
    else
      return (0);

 

Bearbeitet 28. Januar 2022 von Snux

[Black Knight]

Looks good. I'm going to put this into the DOCs and reference to your exceptions when I add them to my code.

Speaking of exceptions:  
I just added priority timers to the V00.23 branch. They're mainly intended for Kobza's roulette wheel, but they might come in handy for your kickback also. Hence, if you should find out that you need a certain delay between the kickback switch being triggered and the coil kicking in then use ActivatePrioTimer instead of ActivateTimer for this. 

Note that these timers should only be used for small tasks which really need the high accuracy.

[Snux]

4 hours ago, Black Knight said:

I'm going to put this into the DOCs and reference to your exceptions when I add them to my code.

Sounds good.  I found one missing sound file today which I've added to my zip file.  I played some more today and the kickback worked fine all the time, so I don't think I'll bother with any exception code for HW rules for it.  I can always revisit that later.  If all continues to play well I'll send you over the updated sound zip and also the .ino code for F14 exceptions.  Any future exception code is going to be very specific to "my" F14 with the LEDs so I don't think anyone else will be too interested.

I'm putting together the LED board (using a Nano as that is what I had laying around and it should handle the Neopixel library fine).  One question - how critical is the value of capacitor C2?  I only seem to have 100nF caps in my spares at the moment, can I use one of those (like C1 and C3) instead?

[Black Knight]

vor 12 Minuten schrieb Snux:

One question - how critical is the value of capacitor C2?

Well, if you only have 100nF then just give it a try. The worst thing that might happen is that your communication gets distortet and your LEDs flicker.

[Snux]

Found someone selling caps on ebay, 10 for £1 including post 🙂

[Black Knight]

Almost done with the LED rework.

LEDs are working fine, but now the matrix lamps do not work any more.🤬

I'm going to call it a day. May be I'm better with beer than with code.

[Snux]

3 hours ago, Black Knight said:

Almost done with the LED rework.

LEDs are working fine, but now the matrix lamps do not work any more.🤬

I'm going to call it a day. May be I'm better with beer than with code.

Sometimes beer and code together works well. At other times it's not a good combination! 

[Black Knight]

Found my bug - Lamps and LED are working together now. Version is not yet uploaded though.

Now I want to add some reasonable commands to control the LEDs. My first thoughts are:

• TurnOnLED(byte LEDnumber)
• TurnOffLED(byte LEDnumber)
• LEDchangeColor(byte LEDnumber, byte Red, byte Green, byte Blue)  -> change the color of a particular LED
• LEDallColorMode(byte Red, byte Green, byte Blue) -> all LEDs being turned on afterwards get this color
• LEDallColorModeOff -> turn off the mode above - LEDs keep their color

What do you think, something missing?

[Snux]

30 minutes ago, Black Knight said:

What do you think, something missing?

I think that would be a great starting point to get things moving, maybe we think of something else later.  That would certainly be enough for me to add exception code for Pinmame to drive my LEDs in the playfield and the GI.

My APC_LED board isn't looking as nice as yours, but it seems to be working, the Nano I'm using seems quite happy.  I just set the existing APC version to LEDs on for all lamps and connected a string of LEDs that I have spare.  In attract mode the colour changes sometimes which is strange, but is probably either because I don't have a C2 at all on my board at the moment, or else because I have it connected to the APC with a 2m ribbon cable .  The video is F14 attract mode, if you can't work that out yourself 😁

 

 

[Snux]

Actually, maybe we need BlinkLED too, like for lamps...

[Snux]

My code for disabling the special solenoids when flippers are off broke something   I found that I could only enter test mode when the game was running, so the correct code is this (check Command is also less than 72, not just greater than 64!)

  case SwitchActCommand:                              // Check for switches
    if (Command > 64 && Command < 72) {                               // If special solenoid switch
      if (QuerySolenoid(24))                          // Check if the flippers are active
        return(0);                                    // If they are active then permit the switch
      else
        return(1);                                     // otherwise block it
    }
    else
      return (0);

 

[Snux]

22 hours ago, Snux said:

In attract mode the colour changes sometimes which is strange

Fitting C2 (with the correct value) has fixed the colour glitching and some flickering I was getting.

[Black Knight]

 

The video is F14 attract mode, if you can't work that out yourself 

Well, completely obvious.

 

Actually, maybe we need BlinkLED too, like for lamps...

Good idea, we could even use the existing BlinkLamps environment for that. It just has to learn that lamp numbers > X (probably 64) are LEDs.

 

My code for disabling the special solenoids when flippers are off broke something

Yeah, the nasty side effects.

 

Fitting C2 (with the correct value) has fixed the colour glitching and some flickering I was getting.

Until now I didn't include any SW measures to prevent misclocking. That was done intentionally to check the reliability of communication via ribbon cable, but it means that depending on the position and environment of your ribbon cable the problems might come back. 
However, in the next SW version of the Exp_board I plan to include a simple countermeasure, but I'd be interested to know how stable the connection is without it.

BTW, in KiCad the value of C2 is 10nF. I guess I have to check my board to find out what value I had actually installed.

Bearbeitet 1. Februar 2022 von Black Knight

[Snux]

16 hours ago, Black Knight said:

BTW, in KiCad the value of C2 is 10nF

Odd, in this schematic it has 33nF... https://github.com/AmokSolderer/APC/blob/master/DOC/Hardware/APC_LED_exp/APC_LED_exp.pdf

16 hours ago, Black Knight said:

It just has to learn that lamp numbers > X (probably 64) are LEDs

Or maybe do that with all the existing lamp routines (TurnOn, TurnOff, Query, Blink etc).  Have them assume that 1-64 are matrix, anything higher is LED with number 65 being the first LED.  That would of course still leave the colour handling calls to be implemented but they could just ignore anything lower than 65 to keep them a little more generic.  At the moment the LED handling also assumes 64 LEDs, maybe we need to have configured how many there actually are (and pass that to the LED Arduino) so we don't pass data for 64 when we might only have 10 or 20.

16 hours ago, Black Knight said:

I'd be interested to know how stable the connection is without it.

Seems OK so far, I need to think about where to put the LED board.  At the moment I have a Fadecandy mounted under the apron connected with a long USB cable but I think the APC board will be better in the backbox (instead of running a 2m ribbon cable under the playfield).  That will make the distance to the first LED in the chain longer, but I think it'll be OK.

Bearbeitet 2. Februar 2022 von Snux

[Black Knight]

vor 6 Stunden schrieb Snux:

Odd, in this schematic it has 33nF

I have 10nF on my board so it's my bad.

 Apparently I changed the cap to 10nF, but didn't export a new schematic from KiCad.

vor 7 Stunden schrieb Snux:

Or maybe do that with all the existing lamp routines (TurnOn, TurnOff, Query, Blink etc).

Done.

No color commands yet, but all the above lamp commands with lamp numbers > 64 will affect the LEDs.  
For this to work the setting 'LED LAMPS' must be set to 'ADDITIONAL'

[Snux]

Nice, I can see the updates on v23 Github.  I'll pull them down and give it a try in the next day or so, I need to disconnect my Fadecandy and sort out the wiring to connect to APC.

[Snux]

If you read my stupid post about the lamp matrix, I've removed it.  My lamp strobe connector was 1 position off

Bearbeitet 3. Februar 2022 von Snux

[Snux]

Awesome, it works fine!  The synchronisation between the matrix and RGB is really good too but I'll do some more checking.

In the pinmame exception code I'm catching the lamp commands for the positions in the matrix where I have my RGB lamps and then issuing lamp commands for the actual RGB (above 65).  I'm also catching the GI relay activation and issuing lamp commands for the all the RGB lamps I have in my GI.

I hacked the wiring some to prove it all worked, so now I need to tidy that up and also add back in the RGB ring I have under the central insert.  Once that's all done I'll take some video.  It will be interesting to see how the serial LED chain holds up as the first LED will be quite a long way from the driving Arduino.  I can bring it closer if I have too but it'll be a bit of a fiddle.

I do have one request, if you think it's a good idea.  Could we also have the possibility to handle some kind of initialisation in the pinmame exceptions code?  Let me explain why.  In a normal F14, the GI is all controlled via the GI relay (solenoid 11).  When deactivated, the GI is on.  If you activate the solenoid, the GI turns off.  In my machine, the GI is all RGB which by default is off.  So my GI doesn't actually turn on until the machine has turned it off and back on for the first time.  I've worked around it by catching the very first  lamp activation that happens and switching the GI on from that and that works fine, but it's not very pretty.

If there was a call to a game specific initialisation routine (or the existing code just got called with a different "Type") then if anyone wanted to do some setup they could.

Bearbeitet 3. Februar 2022 von Snux

[Black Knight]

vor 3 Stunden schrieb Snux:

If there was a call to a game specific initialisation routine

Well I guess EX_Init is what you're looking for. 
This routine is called once in the beginning and looks for the game number selected in the 'Game Settings'. In most cases only the PinMameException pointer is set here, but you could add all kinds of code also. 

[Snux]

16 hours ago, Black Knight said:

I guess EX_Init is what you're looking for

I should have thought about that really, since I already modified it to add game number 44

Just an FYI, I think I'm going to end up modifying the APC_LED Arduino code a little.  I actually have a little over 64 LEDs (I think about 68).  The last 16 of them are a ring of pixels underneath that big flasher insert in the middle of the playfield.  Rather than extending APC to handle more than 64 (which I think nobody else will need) I think I'll just adjust the LED_APC code to spot when the first in the ring is addressed and do the other 15 too.  Previously I've also had some effects running on that ring (like a "radar sweep") that would be really difficult to handle from APC directly.  I'm not sure if I'll reimplement that or not, but the LED Arduino would be the proper place to do that I think.