Tuesday, July 19, 2016

Resolution of the problem!

Success!
The board is now running different voltages without any interference!

I swapped the P-Channel for a N-Channel on the 12V "rail" and pull-downs to pull-up's on the remaining P-Channel MOSFET's. No more weird double triggering.

As for ghosting;
There's unfortunately still plenty of it.

I'm thinking this is my fault when designing the board since rows and columns are operated on the same chain of shift registers. This means I cannot turn off rows and columns independently from each other but instead have to rearrange everything at once. I've also hardwired the OE (output enable) of the shift registers to permanently being on, which of course is a part of the problem.I don't expect this to be a big issue, but I'll have to see.

In case it is a major nuisance I can always add a few control lines and possibly OE as well.
I'm thinking OE would be most significant, as this would allow me to properly turn off the matrix while transitioning rows (and columns). 

Monday, July 18, 2016

Confirmation of the problem

Indeed it's the voltage that is the culprit, and there's a solution in sight.

I've created three example circuits;

Top - current and erroneous 12V circuit (should be off)
Middle - current and functional 5V circuit (is off)
Bottom - proposed and functional 12V N-channel circuit. (is on)

Example circuits

( No resistors in these circuits, but they don't affect the outcome here )

Ironically - a while back when transferring the lightboard from design to product, I found that I couldn't use N-Channel MOSFET's, and yet here it is saving me. I must have made some real booboo's on that breadboard when I deemed N-Channels nonfunctional for the lights, since there's really no reason for it not to work - it's all about which direction the current goes.

Weird Science

Ok, so I've found the problem with the lightboard after extensive search - When using two different power voltages (sources?) it doesn't work.

Why?
I honestly don't know.

I've double checked the hardware and rewritten the software, nothing seems to make a difference. I've done no change in the circuit, but simply removing the +12V and attaching a cable from the +5V input to the +12V makes it work perfectly. The both grounds are tied together as well and has always been. So the circuit itself should be alright, I guess?

My best guess now is that somehow power leaks into the "on-switch" of the 12V MOSFET since it's not connected to the same power chain as the rest normally, and therefor possibly allows the current to flow differently there. Putting diodes could possibly remedy it. But there's really no room on the board for extra parts, meaning some ugly Frankensteining of parts on top of parts etc.

I'll keep looking. Nobody wants weak 5V flashers... :C

Edit - 

Ok, I think I'm on to something here. And if so, it's a hardware error by design (by me). 
I'm connecting the gate to ground to keep it from floating, but that is how it's done for N-Channel MOSFET's, not P-Channel as those are active when grounded/low. So that'll have to change and will probably help a little with the ever so slight ghosting issue. 

Secondly; 
I thought the VGS value of a MOSFET was some kind of fixed requirement for turning it on. Well, it is - but it also depends on the load. So in this case when using logic level voltages (i.e up to 5V) the gate can be properly held shut by the shift register as the voltage is less or exactly the same as the gate voltage. In comes 12V and I'm suddenly short 7V to properly close the gate using my 5V, and the circuit is held open. Imagine closing a door standing in a river compared to closing a door in a shower, the pressure of the river is just to big to properly close the door and water will leak through etc. 

So I need to first fix the resistors from pull-down to pull-up, and then I guess add a N-Channel MOSFET on top of the P-Channel to act as a valve for opening/closing the P-Channel and thus the heavier load. I'm so glad I've moved the board to an easier to reach location!


1) Colors are off and the light numbers doesn't correspond with the correct channels yet, but you can clearly see there's no wrongful "double" triggering here.

Saturday, July 16, 2016

Balls Be Lockin'!

Well, soon enough at least!

This is what I've come up with so far.
Should be fairly easy to manufacture; Five sheets of 10 mm plywood/board with standard drilling/sawing at most and a couple of 2 mm aluminum details etc.

1) Left: Open state. The holder solenoid bracket is spring loaded against the main solenoid plunger, and once the main solenoid triggers and the plunger reaches the endpoint, the bracket pushes forward and locks it in place. Right: Closed state. The holder solenoid and main solenoid is inactive and springs are doing their thing together with physics. When it's time to open I'll fire the main solenoid briefly to release tension, hold the holder solenoid while the plunger drops and then release the holder solenoid.
There are a few eyeballers here, but overall it should be pretty correct. The "fork" itself is based on a couple of bolts I have (with the screw part sawed off in the design) and they are a little shorter than I would like them to be. I will also have to double check that the ball won't squeeze through the gap. In case it does, I'll have to drill new or bigger holes in the playfield since the captive ball posts where 2-3 times larger than these bolts.

Should shit hit the fan, I got a couple of blue steel ramp flaps that can be placed on the playfield "floor" to cover up any unwanted holes. But I really hope it doesn't come to that! :)

Wednesday, July 13, 2016

This One's For You!

Woohoo, an update! ;D

Finished all diodes (I think) today, and got plenty of work done on the machine. For starters I moved the entire light board to the playfield for easier access and debugging/status checking. Unfortunately I realized that there appears to be some kind of error with the 12V line, as these are always active when one of the 5V LED's in the same column is active. I believe this to be a software issue as I cannot reproduce the error by powering rows/cols manually. Had there been any kind of short circuit that would have shown, I think.

The downside is that my programming environment is a very old laptop and for some reason I cannot compile code for Arduino anymore, so I'll have to use my desktop computer. It's quite cumbersome to setup so I'll put that to side for now.

Edit:
Actually, the row-MOSFET's are active when held low, so it's not entire impossible for the 12V MOSFET to be wrongfully and constantly grounded and therefor constantly active. In the schematics all rows circuits are the same and only the voltage differs. But maybe I connected something to ground "just in case" and since I've previously only connected the 5V line while testing the board, the problem could have been there from the start. I will investigate this.

Edit 2: 

Nope, that's not it. The board follows the schematic (who knew?!) and they're all connected identically. I cannot measure any differences between the functional rows and the erroneous either, so it's gotta be something in the code. Probably a clock pulse in the wrong place or something like that. Let's dive into manuals, yeay!  




1) Cluttered cable mess and the installed lightboard. The board sits on rubber pads and has extra support on the edges to prevent it from falling down, should it ever vibrate loose (not visible here).

2) Dimmed global lighting and example lightshow running. Note the erroneous red row that aligns with the green lights. No actual light has been plugged in at the moment since I need to work out the issue with the programming/board before applying real voltage across the playfield, but even then it's just 20 cables that needs to be soldered. Not a big deal at all.

Then I finished the one-way gate with double switching, meaning that it blocks shots from the front but registers hits, while letting balls from the bumper area pass through and still register hits. This allows for a greater range of options for game rules etc. I'm quite happy with how it turned out, even if the final form of the switchblade had to be reshaped ad-hoc since the nut was placed differently than in my "test rig".

3) More or less the player angle of the switch area. It's got a bit "last minute" to it, but hopefully it'll play alright and the benefits are far greater than the possible visual aspect of it. But honestly, I think the Quadtych deserves to be a visible part on the playfield - and now it is.
4) Birds view of the switch area. The metal rail in the bottom (i.e playfield right) was bent with a nice fit. The original part was just too short and I was tempted to put a pole between the bumper and the rail, but then I found a slightly longer rail in my "box of random parts" which worked perfectly. Guess I've been racking up some karma points at least... :) 

5) Switch close-up. Took a bit of fiddling to get right, but it works great. Hope it keeps running smoothly in the future too.

 Lastly, I've begun work with the ball-lock / up-post thingy.
At the moment all I've done is removing the old captive ball and modifying the plastic overlay slightly to better show the locked ball.

Next I plan to construct the actual ball lock device itself, where the problem today is two fold;
Firstly there's the issue of attaching the holder solenoid to the main solenoid. I need to find a good material that I can process without heavy machinery. I'm thinking a thin(isch) sheet of aluminum should work. Plan B is to construct a plastic placeholder while I think of something else. I'm refraining quite severely from purchasing new parts at this stage, but if I have to; well, I have to.

Secondly, the "fork" I was planning to use to hold the ball was of a wood screw type and is unfit for mechanical use, so I'll have to find an alternative for that. I don't think I can use an official Stern (or similar) ball lock as the space is very limited where I'm installing it. At least in the blueprints I've looked at it looks too big.

Well, that's all for now. Hopefully I'll have functioning lights and a ball lock next time! :) 



Tuesday, June 28, 2016

Shame! Shame! Shame!

My plan failed - I have not been able to work on the pin as much as I wanted to.
Music, life, family and a lot of other cool things has simply been taking all my time.
But fear not; Soon the new workflow shall rise from the ashes of the old! ;)

Also; Game of Thrones.
Last two episodes were killer! \m/

Sunday, May 8, 2016

Vacation's up!

So, back from my mini-vacation!
Been doing nothing but enjoying the weather, visual pinball 10 and life in general. #thumbsup

Starting this Monday I'll begin working on the machine on a schedule.
Figure it's time to get it up and running, right? :)