next topic »

[Reply #15 on:]

Seems to be OK. A few "cosmetic" changes
loop() gets called continously. Thus the while(1) { ... } construct is totally superflous.
The brackets around the return value are not needed. http://arduino.cc/en/Reference/Return

In your main loop, instead of lots of if ( ret == n ) do something ; use the switch. Same functionality, code more clearly states what is happening (code readability).

Code:

void loop()
{
  switch( scansw() ) {  // omitted the "ret" variable, too. (Optional)
    case 0: continue; break ;
    case 1: DrainPitSwitchClose() ; break ;   // Drain Pit Switch closed
    case 2: Othercall() ; break ;
    case 52: digitalWrite(13,HIGH) ; if (Counter>10) FlashBonus() ; break ;
    case 21: somethingelse() ; break ;
   default: Serial.println("Something wrong - impossible value") ;
  }  // end switch
}

Note that case do not have to be in order, the default case is optional (but usefull); you can just call a procedure, but any sequence of statements is OK in a case (including a nested switch) - and most importantly : remember to end each case with a break

[Reply #16 on:]

Thank you, Msquare.

loop() gets called continously. Thus the while(1) { ... } construct is totally superflous.

I used while(1) to be able to use break/continue.

I used if statements instead of switch in order to get a new switch - electric switch, that is... - scan as quickly as possible if no swicth was activated in the last scan. Not that I know if it makes any difference since I don't know how long it takes for each instruction to be executed. A switch statement may even be faster than 20 if statements, I don't know.

The brackets around the return value are not needed.

I didn't know that. Thanks again!

 - - -

The Multiplexer board for scanning the switch matrix is ready now. Just have to restore some connections to the switches on the playfield, some disconnected by previous owner, some hacks made by me when I didn't realize how easy it (hopefully) is to scan a matrix, especially using an Arduino! Then it's time to test if it rellay works, not just in theory. Exciting!

[Reply #17 on:]

Allright then. Time to find out if the theories work in practice.
To the left: my Arduino Uno board.
In the middle: my homemade mulitiplexer for the playfield switch matrix.
To the right: the original multiplexer/driver board. I'll probably use only the solenoid drivers there.

I have a feeling it won't work. First, there were separate grounds for the playfield and the logic. Maybe that have to be kept apart or the electronics may be interfered? Also, that are many chances to make mistakes, even though I think I've doublechecked every connection.

I'll give you a report in a couple of hours.



/SimLego

[Reply #18 on:]

What are you worried about - noise on signal lines (causing the wrong signal to be read/sent) or a voltage spike (all those heavy solenoids) ruining you electronics or a fatal short (like getting 24V on a 5V line)?

The ground has to be common - else there is no meaning to voltage levels. This is true also with several power supplies.

Unless you choose to galvanically seperate the two, in which case all signals have to go through optocouplers, and of course you have seperate power supplies.

The spikes should already been absorbed by diodes (the driver board contains electronics I see). Spurious signal on the input side can be compensated for in the software, it is akin to debounce a switch. To guard against a fatal short you need galvanic isolation, but if you have nothing more than 24V then you "only" need to replace the AVR microchip (or some driver chip you may have) in "the unlikely event" of disaster

[Reply #19 on:]

Total failure. Nothing works, and I have no idea why. This means debugging all night...

[Reply #20 on:]

I hate it. Now I stripped down everything to pin11=output, pin12=input(pullup), and pin13 as LED output (using only the built in LED).
On pin11 I sent a 1Hz signal; 500ms low and 500ms high. Pin13 displays the reading from pin12. Everything else is completely unplugged.



Now, with nothing conneted to the board, the LED stays lit all the time. Just as it should.
With a diode connected from pin12 to pin11, the LED flashes at 1Hz. Just like it should.
But with pin12 and pin11 connected to an open circuit on the playfield - totally open, not even several megaohms - the LED flashed occationally. I don't even touch the machine, and like I said, nothing else is plugged in.

What can it be? The only thing I can think of, is that the quite long parallell wires become some kind of capacitor that discharges or something. Or the unshielded wires make some kind of hum like the one you can hear from a microphone line that's lost its ground shield.

Any suggestions I may try? Some kind of software or hardware filter? Some more puul-up? Or pull-down?

[Reply #21 on:]

I found a potential solution. In my desperation, I thought that maybe the little transience when wires connected pin11 goes from high to low could effect the wires connected to pin12. So, as much as you all discourage delays, I added a one ms delay between writing to pin11 and reading pin12. And yes, it seems like it made the trick. At least in this very stripped off test.

Code:

  digitalWrite(11, HIGH);
  delay(1); 
  if(digitalRead(12) == LOW) 
  {
    digitalWrite(13, LOW);
  }
  else
  {
    digitalWrite(13, HIGH);
  }

This time, the LED only flashes when the switch is closed, just as I excpected.

Well, that's all for tonight. Tomorrow I hopefully will get the time to test this scanning the whole switch matrix.

EDIT: The downside of this solution (if it even works) is that it adds 6 milliseconds to every complete switch matrix scan performed.

[Reply #22 on:]

Post the whole sketch - the one you had where it "triggered" even though the switch was open. The fragment you showed gives no clue why it should flash, even though that is what you wanted/expected. So there may be other things "lurking".

An Arduino input pin is High Impedance, meaning that a long attached wire (and no defined voltages) results in "random input". So you must have a pullup or down, and the closing of the switch pulls it in the opposite direction.

[Reply #23 on:]

Ok, here's the erratic code:

Code:

void setup()
{
  pinMode(11, OUTPUT);
  pinMode(13, OUTPUT);
  pinMode(12, INPUT_PULLUP);
}

void loop()
{
  digitalWrite(11, HIGH);
  if(digitalRead(12) == LOW) 
  {
    digitalWrite(13, LOW);
  }
  else
  {
    digitalWrite(13, HIGH);
  }

  delay(500); 

  digitalWrite(11, LOW);
  if(digitalRead(12) == LOW) 
  {
    digitalWrite(13, LOW);
  }
  else
  {
    digitalWrite(13, HIGH);
  }

  delay(500);
}

When pin11 is LOW, that "line" of switches is scanned. When HIGH, another line of switches is scanned. (In this test sketch, I have stripped off all other lines and use just one switch to isolate the problem.) And the problem was that even though pin12 wasn't connected to a switch closed to LOW and it was pulled up, it still returned LOW occationally.

But here's the working code:

Code:

 
void setup()
{
  pinMode(11, OUTPUT);
  pinMode(13, OUTPUT);
  pinMode(12, INPUT_PULLUP);
}

void loop()
{
  digitalWrite(11, HIGH);
  delay(1); 
  if(digitalRead(12) == LOW) 
  {
    digitalWrite(13, LOW);
  }
  else
  {
    digitalWrite(13, HIGH);
  }

  delay(500); 

  digitalWrite(11, LOW);
  delay(1); 
  if(digitalRead(12) == LOW) 
  {
    digitalWrite(13, LOW);
  }
  else
  {
    digitalWrite(13, HIGH);
  }

  delay(500);
}

The only difference is the two "delay(1);" lines. It seems one millisecond is enough to settle down the induction or whatever that pin11 may have caused while going LOW.

Next step is to see if it still works when I remove the "delay(500);" lines. But I can't do that tonight, I'm busy with other stuff.

[Reply #24 on:]

OK, let me paraphrase your situation. You have 4 combinations and have only reported on two.

You send a signal from pin11 to pin12, and use pin13/LED to verify it comes through. This works if the connection is very close (Why did you use a diode? What do you think happens if you reverse the diode? I think it will "fail"). You do not say if things work as expected if you do not connect the two.

This fails if you have long wires which go "somewhere", claiming there is a connection although your Ohm meter says they have no connection. (Somewhere is a switch matrix, or circuit or ?) Does it work as expected if the switchmatrix-circuit-whatever is closed?

The observation that if you wait "delay(1)" between setting pin 11 and sampling it on pin 12, it yields correct result (you only say on the open, not the closed state). Have you tried delayMicroseconds(100), (50), .. (four is the minimum)?  You code without the delay will turn the pin on and sample it on/off the other approximatly 300-500 nanoseconds later (I have not worked out the precise timing) or 15 meters at lightspeed. Any capacitance/inductance will drastically reduce the speed. The pinball components work in deci or centiseconds for most stuff. Your Arduino is working in sub-microseconds.

Lastly what makes it "scan one set of switches on LOW and another on HIGH"? A circuit? Diode? Relay?

Good luck on the continuing bug-hunt

[Reply #25 on:]

Good luck on the continuing bug-hunt

Thanks. I hope we solved it with that delay.

OK, let me paraphrase your situation. You have 4 combinations and have only reported on two.

You send a signal from pin11 to pin12, and use pin13/LED to verify it comes through. This works if the connection is very close (Why did you use a diode? What do you think happens if you reverse the diode? I think it will "fail"). You do not say if things work as expected if you do not connect the two.

This fails if you have long wires which go "somewhere", claiming there is a connection although your Ohm meter says they have no connection. (Somewhere is a switch matrix, or circuit or ?) Does it work as expected if the switchmatrix-circuit-whatever is closed?

Sorry. With nothing connected, the LED doesn't blink. Just as expected. With the pinball wires connected and the switch closed, it blinks as expected. At least when it's the first switch to be tested. If not, the first switch which is open sometimes yields a "closed".

The reason I used a diode is because there has to be a diode connected in series with every switch in the matrix, or else the matrix will let through false positives. And I wanted to simulate the connection as faithful to the original as possible. I didn't believe it, but I though that maybe, maybe the voltage loss over the diode would be enough to keep the input of pin12 HIGH.

A reversed diode on the stripped down test will only lead to fail to let the signals through form pin11 to pin12.
A reversed diode in the switch matrix would lead to both fail to let through the correct signals and let false signals go to backwards through a closed switch and thus yield false positives while testing some of the other switches in the matrix.

Have you tried delayMicroseconds(100), (50), .. (four is the minimum)?

No, that's a new keyword for me. I will keep it in mind for the final fine-tuning.

You code without the delay will turn the pin on and sample it on/off the other approximatly 300-500 nanoseconds later (I have not worked out the precise timing) or 15 meters at lightspeed. Any capacitance/inductance will drastically reduce the speed.

Wow! That's totally amazing. Really hard to believe. (But of course I do believe you!)

Lastly what makes it "scan one set of switches on LOW and another on HIGH"? A circuit? Diode? Relay?

Originally, it was a 7445 BCD To Decimal Decoder. But it is fried, so I built a new multiplexer. While hunting the bugs, I even skipped that one to eliminate potential error sources. (The bug persisted anyway, because it appears to be due to the long wires in combination with the speed of the Arduino.) But I just decided to skip the home-made multiplexer anyway; the Arduino Mega will have more than enough pins to handle that multiplexing itself.

Thanks again for all the input, hints and encuoragement.

/SimLego

[Reply #26 on:]

Yes, it works now! I tested with 5 switches from two different lines, the pin13 LED indicated in just the expected patterns for the different inputs. Even though I haven't tried input from all switches, I strongly believe it will not add any big problems.

So, my work plan looks something like this:

1. Interacting with the playfield.
1a. Input from the Switch Matrix - check!
1b. Output to Bonus Lamps.
1c. Output to other Lamps.
1d. Output to Solenoids.
2. Top Box.
2a. Output to Ball in Play, Tilt, and Game Over Lamps.
2b. Output to Free Game Number LEDs.
2c. Output to Score Table. (That will be the by far most diffucult task.)
2d. Keeping High Score somehow.
3. Cabinet.
3a. Input from Tilt, Slam Tilt, Door, Play Switches. (more?)
3b. Output to In Play Relay.
3c. Sound Effects.
3d. (Mostly Playfield, but I put it here) A Startup Sequence for the lamps would be cool. And Display Mode.
3e(?) Maybe some reset or at least inhibit coils during startup. If needed.


I wonder what year this project will be finished...

[Reply #27 on:]

Driver card modified/fixed. Took me all day. Hopefully I will not have to remove it again for a long time.

Time for a coffee, and then back to programming the Arduino.

[Reply #28 on:]

There we go. All is set. Will it work? (Probably not...) I'll keep you informed.

Update: Most of the features work, after I corrected a fatal mistake that cost two digital input pins on my Mega.
It may have caused more damage, since there are two strange minor misbehaviours that are really hard to explain.

[Reply #29 on:]

After frying four or more input pins, I decided to use a 74LS08 as a quad buffer for the inputs, in an IC socket so it's easily replaced. (I have got plenty of 7408's but only one Arduino Mega...) Don't know why the Arduino inputs were fried, I see no reason, don't know why the 74LS08 can (at least so far) take those blows...

But at least it works now. Finally I'm done with the interfacing to the playfield. Everything works just as I programmed it to do, although it's much more of "debug mode" than playable rules. Programming the rules will be the easiest part I guess, apart from I have to guess a lot of the gameplan.

I don't know if you would have any interest in watching a video clip using my very cheap digital camera. It's not even a video cam, just an ordinary camera with some video fuctions. I could do that if anyone's interested.

SimLego