APC in F-14

[Snux]

I'm having a bit more of thought about noisy switches.  As you know there are 3 locks in the F14, plus the up kicker.  If there are balls in the locks, and one of them is ejected, sometimes the balls in the other locks move a little and it can be enough to trigger a switch event.

This is different to debounce where you want to ignore multiple switch closures, in this case I want to ignore a switch closure if the switch release only happened a very short time earlier.  Is this something we could build into the base APC code, or shall I work out something in my F14 code?

[Black Knight]

I think this should be handled by the game code. The lock mechanisms of the various games are quite different and should therefore be treated individually IMHO.

What I did in BK and Pinbot code is:  
If a lock switch is triggered, set a lock flag (like PB_IgnoreLock) to ignore further events caused by the lock switches. Wait for 1 or 2s for the balls to settle. Then count the locked balls and compare this number with the expected amount of locked balls. If the number fits then process the locked ball and release the lock flag. If the number does not match then use the number of the counted balls as the new reference and come back one second later and check again.

[Black Knight]

For the F-14 this should be even easier because the lock cannot just be hit, but the diverter has to be controlled by the SW anyway. That means your code should know the status of each lock even without having to check the lock switches.

[Snux]

3 hours ago, Black Knight said:

For the F-14 this should be even easier because the lock cannot just be hit

In some ways easier, in some ways harder.  Every time you launch a ball, it has to go into a lock that may already be holding a ball.  It's all working fine, the code does know the status of each lock and the divertor knows where it wants to send the ball, it's just that sometimes odd/phantom switch closures trigger an edge case I hadn't planned for.  I'll rework it a little.

[Snux]

I had a little break but am back squashing a few bugs.  Last night I left the machine for quite a long time, and when I returned it had stopped with error 20.  I'm trying to understand quite what it means, I can see in the APC code it's something to do with a timer having a missing event but I'm not quite sure what that means or how it could happen.  Any ideas?  I've not been able to recreate the issue.....

[Black Knight]

Yeah, the overview table of error messages is still pending... 

However, error 20 means that the stored address to be called after a timer has run out is zero.

Is it possible that an ActivateTimer call occured with the EventPointer being zero like ActivateTimer(Time, Argument, ZERO) ?

What makes is a bit difficult to track down the problem is that this error does not occur when the ActivateTimer command is issued, but when the timer has run out and the call to the EventPointer is imminent.

[Snux]

It hasn't happened again since, and I can't recreate, so I'll leave it for the moment.  The error was 20, and then a 1 for the value of the variable 'c' which it displays too.

I was wondering if maybe there is a slight timing issue with a KillTimer being issued at the same time the main loop is trying to process that timer, but that's almost impossible to prove or check.  If it was that, I'd expect to see it more often I guess.

Anyway, I'm going to post an update on Pinside.  I have pretty much all the original rules done and (I think) all the bugs squashed, so it's time to start adding/changing the "second sortie" things

[Black Knight]

vor 47 Minuten schrieb Snux:

I was wondering if maybe there is a slight timing issue with a KillTimer being issued at the same time the main loop is trying to process that timer, but that's almost impossible to prove or check.

I never had an error 20, so I hope the timer handling is OK. When I designed the interrupt handling I also spent a lot of sweat and effort to avoid race conditions between the interrupt and the main program. 
In case of the timers I cheated a bit and introduced the BlockTimers flag which will cause the interrupt to just skip the execution of run out timers for one cycle.

vor 55 Minuten schrieb Snux:

Anyway, I'm going to post an update on Pinside.

I already found a bug

Zitat

A huge shout out to Black Knight (Ralf) on the flippertreff

bontango is Ralf 😉

I'm curious to see your video. If you decide to show and explain the LED stuff a bit then I'd like to post a link to your video on the Github page replacing the very old and basic LED video in the HW section.

[Snux]

9 minutes ago, Black Knight said:

I already found a bug

Oops. Bug fixed!

I will write some notes for my LEDs. Some of it is using my own commands and some the APC base stuff. 

[Black Knight]

I changed the LED handling again.  
The LED_Exp board does now support up to 192 LEDs. Switching off all LEDs by calling 

LEDhandling(0,0);

has also been fixed.

LEDinit();

will reactivate the LEDs. 

For this to work you have to update the SW of the Exp board also.

And now to something weird. 
I bought a string of LED to be used as GI (as you've mentioned here). It works basically but it appears that the red and green colors are swapped, so what is green with a normal WS2812 stripe is now red and vice versa.

Is this normal or is this some kind of chinese 'special edition'?

[Snux]

51 minutes ago, Black Knight said:

I changed the LED handling again.

Cool, I'll take a look.  I need to be a little careful because I handle the GI LEDs through my own code command, but it'll be good to bring your changes in so I can keep my Github in sync.

51 minutes ago, Black Knight said:

And now to something weird.

Yeah, that's normal.  In fact when you define the pixel string you define if they are RGB, GRB etc...

// Declare our NeoPixel strip object:
Adafruit_NeoPixel strip(LED_COUNT, LED_PIN, NEO_GRB + NEO_KHZ800);
// Argument 1 = Number of pixels in NeoPixel strip
// Argument 2 = Arduino pin number (most are valid)
// Argument 3 = Pixel type flags, add together as needed:
//   NEO_KHZ800  800 KHz bitstream (most NeoPixel products w/WS2812 LEDs)
//   NEO_KHZ400  400 KHz (classic 'v1' (not v2) FLORA pixels, WS2811 drivers)
//   NEO_GRB     Pixels are wired for GRB bitstream (most NeoPixel products)
//   NEO_RGB     Pixels are wired for RGB bitstream (v1 FLORA pixels, not v2)
//   NEO_RGBW    Pixels are wired for RGBW bitstream (NeoPixel RGBW products)

That works fine if each string contains the same type of LED, but in my case I have RGB and GRB in the same string, so I just need to take care of adjusting the colour values.  And how anyone makes a profit selling a string of 50 for so cheap I have no idea

Do you want the .stl file for the 3D printed clips I've been using for those GI lamps?  I don't have a printer so I sent it off somewhere to be done.  They're quite good.  I got the file from someone else, I forget who.  Look like this....

Bearbeitet 11. April 2022 von Snux