We meet again, Captain Setback!

I was having a great time soldering new light cables and everything went smoothly... I thought.

1) I was happy. Until I tested the circuits...

Introducing, in the red corner - The Problem.

2) A typical layout with two power lines and two ground lines.

In the picture above, connecting Power 1 and Ground 1 should light up Lamp 1. The problem is that since I don't use LED's, which are single direction only, but lamps/bulbs in most locations, powering that line will also light up Lamp 2, 4 and 3 (in that order). Basically it's a grid of interconnected lines so "everything" lights up simultaneously. Doh.

...and in the blue corner - The Solution(s).

I planned the matrix layout based on LED's, so the easiest solution would be to simply replace all bulbs with LED's instead. That is rather expensive however and I really want to keep it "lamp-agnostic" in order to use whatever lamp suits the most.

Another possible solution would be to use current restricting diodes on each ground and power line. Slightly less expensive and should be quite easy.

The third - and here's where my hope lies - possibly solution: Using the light board's built in current restricting diodes on each ground and power line. However I'm not fluent enough in electrics to know if a single diode at the end / start of each line would be enough to keep current going in the right direction all over the playfield. I only know this once everything is hooked up, and I have roughly half of the ground cables left to solder, and in case I need to adjust something I'd rather do it now than retrace my steps later.


The million dollar question: 
Is it enough to "correct" the current direction at the start and end of each line, even if the cables are not drawn in series, but rather branch out every now and then? Would the, say, blue chain above benefit from a diode between Lamp 2 and Ground 2? Would the diode stop that from happening since that line is still connected to the diode?

Or would the current pass on from Lamp 2 to Lamp 4 regardless?

Edit:
I've found a great tool online to troubleshoot circuits. Using this (which I assume is rather correct) I can see that it won't work with a single diode. The current would still pass in the other "legs".
I will see what the best solution would be, but right now I must say changing to all LED's would be preferable... :/

Check for yourselves here:
Lamp/Bulb based:  http://tinyurl.com/jk38dwm
LED based: http://tinyurl.com/gvbssy2

I'm not alone!

It turns out I'm not alone in this world building a custom pinball machine!

*insert shocked audience reaction here*

Not that I ever believed that, but now it's easier than ever to keep track on the projects that are out there. With Pinball Makers website and all the great custom games that are currently in progress. :)
Head on over and see what the fuzz is about: http://pinballmakers.com/wiki/index.php/Custom_Games

I specifically like this Nightmare Before Christmas table by Mark Incitti.
Looks really solid and seems like a very fun table - and you can play it today using Future Pinball!

Btw, this is totally not an ad.Even thou it sounds like it. ;)

Btw 2 -
I'm considering rewriting all game rules from scratch.... :O 

Love shine a light....

Almost done with all power/row connections now. :) 

It looks like crap, but works - and that's most important right now!

I found out that I'm short eight light ports, so I had to combine a couple of GI ports (again) in order to have enough for all the important lights. Silly me to forget that 8 of the ports on the flasher-row wouldn't be usable for the other lights...Thumbs up on that one.

The lights are grouped in big colored chunks, making it quite easy to visually debug or trouble shoot faulty cables. This combined with the maintenance mode and on-board LED visualizer will make light problems a breeze to handle in the future. 

It's nice to have a little progress at last! 

1) Cables that only a father could love...

Stuck in the wasteland...

Long time no update, sorry about that.

I've been, as some of you have guessed, completely sucked into the world of Fallout 4. Pretty nice game and much better than Fallout 3 in my opinion. (However, dragging way behind Fallout 1 and 2...). Playing the game on a projector and gamepad gives the wasteland it's proper dimensions. #nice

Other than that -
I'm at this stage of building were it's really tough to keep going and feel that unless I got a full day to spend on the machine, I don't bother at all. Will try to change my attitude regarding this so that "a cable a day keeps the doctor away". It's taken me much longer than expected since I'm kind of a perfectionist when it comes to details. I'm never really happy a long time with the results which is why I tend to remake stuff all the time. :)


But it's getting closer to completion and once all new light cables are in place the "Version 1.0" coding will commence.

Thanks for your support!
It means a lot and takes me through the rough patches! :)

...Chop-shop!

I've gone ahead and started butchering the light cables.
And I only killed seven switches in the process...

Man, it kinda hurts...but it will be all worth it when finished! :)
I will be able to say "light #5, that's red/blue" and see if the problem is the bulb, the board or MOSFET's etc. Troubleshooting will be a lot easier!

1) Old cables removed and the new ones await installing!

2) They don't look much, but will mean the world to Mr Bubbles!
I might need to order another batch of cables thou - apparently 60 m isn't enough ...

Hmmm-stable? Unstable?

So, long story short -
I've struggled with random crashes and potential memory corruption scenarios for a while. But now I believe I've nailed down all bugs, starting from the String library and ended with the sound card serial commands... 

1) This is what most of my evenings look like nowadays. Can't say I'm not enjoying programming the machine, but a proper debug mode with breakpoints would be nice...

What I have done lately:

+ Rewritten most of the core
+ Written tons of rules
+ Changed switches, solenoid and rendering to interrupt driven updates on Timer3 (tried Timer5 as well, no difference)
+ Added a large const array of animation information. (tried to cut it in half, made no difference for the crashes)
+ Added communication over Serial1@57600 to wavTrigger and Serial3@250000 to Arduino Mega2560
+ Added softPWMServo instead of hardware servos
+ Added EEPROM reading/writing of highscores and settings
+ Switched to dynamically allocated data (this was AFTER the crashes were observed, and it's never deleted/recreated - only once during startup)

I've switched all String's to const char* and...ta-ta - const Strings (sorry Majenko!) as well as some generic safety precautions. I've measured RAM during idle and play and it does indeed stay fixed now. If I do a "new" without delete the available RAM ticks down and once low enough it crashes, so the RAM function seem to work. There were just too many functions and special occasion that I needed to replace, and by doing so I'd most certainly would have ended up with an even buggier version of the machine. So once I saw that RAM usage was static, I moved on.

I've also implemented the hardware watchdog so in case it does crash it will reboot and it won't start burning (tried that, wasn't pretty). Works pretty great too! A peculiar thing thou - if the watchdog was held alive by an interrupt, the main loop could crash and the interrupt continue. Don't ask me how, but it did. I did a divide-by-zero on purpose and all game loop and switches etc froze, but the rendering kept going. So the watchdog seems like it must reside in the main loop to have a proper effect.

Lastly, what still caused crashes after everything else was fixed was actually the sound card, a Wav Trigger.

If I sent "too many", i.e more than a few request per 10-15 millisec it would eventually crash. I'm not sure which end causes the problems, but I do know that I can crash the machine by sending a faulty command to the sound card. (RobertSonics, if you're reading this - there could be something wrong with the latest firmware. It shouldn't crash if the command is formatted correctly but unknown...But then again - Chipkit shouldn't crash if the sound card crashes either...)

What I've done is to simply add a cooldown on each command sent to the sound card so that it will sit and wait for it's turn and then send the command. This works and no sound is every skipped/missed, but the implementation is not nice as everything except for solenoids and rendering is stalled in case there's lots of audio. Realistically there's probably only ever gonna be 3-6 samples being started every 300 ms during play, so perhaps I can add the cooldown only after a certain amount of active tracks instead of every time, for instance.

On top of this I've added animation, sound and rules to most standard switches now. I'll try to get this down in a video soon as it's looking pretty good, if I may say so myself. :)

...

Well, hello there, Mr Big-pile-of-cables...
Should we get you all soldered up?

Time flies!

Apparently I'm using a really really old version of MPIDE to compile the code with....
The servo-problem was solved a while back:

  12/21/2013 <BrianSchmalz>:
    * Fixed bug that caused glitches every 107 seconds.

The question is - do I dare to update the core software, considering the numerous changes I've made to the stock libraries? Can't say I recall exactly what I've changed and where.

But I suppose I need to do this someday anywho since the laptop I'm using is a very old one and can't even compile the code with optimizations active. For the release version I'm pretty sure I want to use compiler optimized code. :)

Also, a programmer called Majenko suggested that the Arduino cannot reliably communicate over serial at higher speed than 9600 baud. I'm not sure what to believe here, since I've used much higher speeds - but still, Majenko is a great programmer and has supplied a lot of libraries and corrections, so I figure he/she knows better. If the serial interface used to program the device is different than the actual interface the MCU is using for the pins inside sketches this might explain why the sketch is running great connected to my computer while failing connected to the MCU.

"The Arduino is unable to communicate reliably at higher baud rates due to the clock being unable to accurately divide down to the right kind of values, but the chipKIT boards, because of the higher speed master clock, can do it more accurately. As a result the Arduino sometimes can't communicate through serial with the chipKIT boards. Try running at a lower baud rate (9600)." [Chipkit forum]

9600 baud could possibly be enough for my needs, but I'm not sure what the "damage" to SD-reading and frame building would be. Still, it's something that can be investigated in the future.