APC in F-14

[Snux]

I narrowed this down, it's something to do with the buffer for the LEDs, my guess is we are going over some array boundary and putting garbage somewhere.  To change my GI colour I'm running this code

    for (int i=65; i < 102; i++) {
      LEDchangeColor(i);
    }

That crashes with the error code 3.  If I only run from 65 to 70 then the first few GI LEDs change colour (as you'd expect) and no crash.  If I change 70 to 71 (so from 65 to 71) it seems like we hit a limit and it will crash.

I know there is a buffer size limitation which means I might need to change the colours a few at a time with a short timer in between, but I guess it shouldn't crash if we exceed the buffer.

Bearbeitet 5. März 2022 von Snux

[Black Knight]

vor 27 Minuten schrieb Snux:

I guess it shouldn't crash if we exceed the buffer

No it shouldn't, but I have to admit that I didn't pay attention to these side effects yet and we can be sure that this will exceed the buffer size.

vor 35 Minuten schrieb Snux:

I might need to change the colours a few at a time with a short timer in between

Yeah, this would be one way to do it. The other would be to change the color and turn on the corresponding LEDs for 40ms, but that'd result in a short flickering.

May be I should add a mode which changes the color of the selected LEDs without turning them on?

[Snux]

1 hour ago, Black Knight said:

May be I should add a mode which changes the color of the selected LEDs without turning them on?

I'm not sure if that helps in my case, as the lamps are already on, I just want to change the colour.  I'll put a short loop with a timer in place, I was kind of expecting that might be necessary anyway.

 

[Black Knight]

It would probably be easier to switch to Mode 0, issue the color change command and then turn off the GI LEDs, wait 20ms and turn them on again in the new color.

Actually mode 2 is meant for changing the color of several LEDs at once, but I think I have to change the handling to make it more comfortable.

Bearbeitet 5. März 2022 von Black Knight

[Snux]

So I call this routine with a starting value of 65 and my GI changes colour.

void F14_GIChangeColour(byte Lamp) {
  LEDchangeColor(Lamp);
  if (Lamp < 102) {
    ActivateTimer(17,Lamp+1,F14_GIChangeColour);
  }
}

With some experimentation 17ms is the lowest I can get the timer without blowing the buffer.  That gives me a total of just over 600ms to change them all, which is a noticeable "ripple" around the playfield.

A solution might be to have something like a LEDchangeColorRange(FirstLED, LastLED) command and have the APC_LED code process that.  Then I could just send LEDchangeColorRange(65,102).  

8 minutes ago, Black Knight said:

It would probably be easier to switch to Mode 0, issue the color change command and then turn off the GI LEDs, wait 20ms and turn them on again in the new color.

That would probably get close although I have a few LEDs blinking or being turned on/off on the playfield that might catch the wrong colour for a short time.

Anyway, not urgent, I've got plenty of other things to work on

Bearbeitet 5. März 2022 von Snux

[Snux]

Quick question - is there a reason that the number of balls per game is a system setting instead of a game setting?  I'm starting to add some additional game settings and wondered why balls per game is in APC.....

[Black Knight]

At the time the idea was to only have the game specific stuff in the Game Settings and the general things in the System settings.
From today's perspective with most people using the Remote Control mode things look a bit different, because the number of balls is then handled by PinMame/MPF so this is somehow an unused setting. 'Free Game' is even worse, as even my own code for BK and Pinbot is not bothering with counting coins.

Therefore I'd be OK with removing 'Number of balls' and 'Free Game' from the System Settings. The main question would be if we replace them with 'Unused' settings or delete them. The latter would require everyone to reset the System Settings.

[Black Knight]

I've reworked the LED modes as well as the documentation.  
Now it also contains a method to use the color modes to change the color of multiple LEDs at once - might come in handy for your GI.  
Please give it a read and feel free to change it where necessary.

Using the new modes will also require updating the SW of your Nano.

I'd also like to give an example how to add own LED commands and I thought your radar sweep would be perfectly suited for that. Have you been able to dig up your old code or do I have to come up with something?

[Snux]

2 hours ago, Black Knight said:

I've reworked the LED modes

That looks like it should work for my GI

2 hours ago, Black Knight said:

Have you been able to dig up your old code or do I have to come up with something?

Yes, I found the code.  I'll look at putting that on my LED board in the next few days.

Do you have any preference about the command numbers?  I see you have 64-68 as modes, so I can stay clear of "the 60s".  Then you have 170, 192 and 195 as commands.  Is there some logic for the command numbers that I should follow?  I'll need either 2 commands (sweep on, sweep off) or 1 command (sweep) with an additional byte for the on/off info.  Actually 1 command with an additional byte might be better, then I can use that extra byte to pass things like direction, speed, colour etc

[Black Knight]

I have already added a basic sweep as an OwnCommand to the Exp_board. It doesn't look very good, but it might fit as a reference for you because I didn't add any documentation about OwnCommands yet.

vor 18 Stunden schrieb Snux:

Do you have any preference about the command numbers?

When I started the LED_exp board I didn't have a logic analyzer at hand, so the first command numbers were chosen according to their bit pattern. As the communication seems to run stable this is not necessary any more and you can choose whatever you want. In my example I have chosen 100 to start the sweep and 101 to stop it. You can also work with an additional command byte if you like, but having two different ones is a bit simpler so I'd suggest to start with this and refine later.

It's a bit tricky to find the right spot in the code to let your sweep run once per refresh cycle. Hence, I've marked it with a comment, so look for this line

      if (!Sync && OwnCommands) {                       // a good place to let an own command run once per refresh cycle

and replace the part below it with your code.

[Snux]

Sounds good, will work on it next week.  Before you posted the new code I managed to get a basic sweep running just by checking millis() and calling my routine after a fixed period elapsed.  Your technique is probably safer though.  I will look to see if my more "pretty" sweep routine can be moved in.

[Snux]

I got the nicer sweep code in place.  By default the sweep is on so it does something when booting up.  I'm using the commands 100 and 101.  After 101 is issued, the ring goes back to basically being a large flasher - the LED code on the Nano watches one of the pixels and copies the colour to the other ones on the ring, so from my F14 code I only need to turn on one of the LEDs and the others follow.

I didn't play with the colour changing yet, I'll try that later today.  This video shows the attract mode at the moment with the rotating ring.  The camera is showing the ring as really bright, in reality it's much darker and nicer, I got close at the end of the video which shows it a little better.

 

[Snux]

The new mode 4 works really well for changing the colour of my GI.  Again my phone is making a mess of the colours, the GI is actually changing between 100% each of Red, Green, Blue.  Looks great on the machine in person.

 

[Black Knight]

Looks great. Do your LEDs fit into the GI sockets?

These new modes are also great for gradual color transitions. Keep your LED pattern and just change the color and every selected LED will change.

[Volley]

Which Kind of LED do you use for GI? Link?

[Snux]

38 minutes ago, Volley said:

Which Kind of LED do you use for GI? Link?

49 minutes ago, Black Knight said:

Do your LEDs fit into the GI sockets?

 

I use strings of LEDs like these

https://www.aliexpress.com/item/4001171502544.html

They are really cheap, and they push really well and quite tight into the GI holes on the playfield (where the sockets used to be).  I've also got some 3D printed clips for them which some other pinball person sent me the file for.

The only downside is that the LEDs are quite close together, so if you have a longer gap between GI in your machine, you either need to cut the wires and extend them, or you just have some extra lamps underneath your playfield in some strange places.  I have both of those situations

Bearbeitet 14. März 2022 von Snux

[Snux]

For the playfield inserts I use these from FAST pinball. I really like the form factor.

https://www.fastpinball.com/product/fast-rgb-led-insert/32?cs=true&cst=custom

[Black Knight]

I think I need some of those, too.

I have a space station here with a very gloomy GI, so almost no 'condition green' visible. I guess that would be a perfect candidate and the F-14 get's an LED_exp board anyway ...

Do you use an extra 5V supply or do you just rely on the old power board being overdimensioned enough? 😉

[Snux]

Originally I had a PC power supply in the cabinet and was using that for plenty of 5v, however at the moment I'm just using the original power board and it seems to be quite happy.

[Snux]

I need to look into the GI color change more carefully.  If I'm playing a lampshow at the time (using a different LED pattern) then the LEDInit is stopping that and none of them get included in the show any more (in the video above none of the LEDs on the playfield inserts are active, I only just noticed).  I've changed the code to set the LEDpattern back to whatever was in place before the colour change, so the LEDs in the show are back on again, but I have an array of different colours, so the GI colour change is doing something strange.  Probably just a timing thing, I might need to interrupt my lampshow briefly before changing colours.

Something else I've done is slave another Arduino Nano to the APC_LED board.  I'm passing all the "own command" type stuff to this second one (it's only 6 or 7 lines in the LED code and is not causing any issues).  This second one has a small TFT display which eventually I'll mount on the apron and use to display game information which will get passed over.  I can probably also run countdown timers on there (the APC led will just pass a command to start and one to stop, so the processing is all on this second Nano).

At the moment just as a proof of concept it's displaying the last value it received, so only changes between 100 and 101 at the moment.  But it works .  I'll extend it with some basic debug/status information as I haven't really worked out what else to put on it yet.

Bearbeitet 20. März 2022 von Snux

[Black Knight]

Yeah, changing the Gi color and playing an unrelated lampshow at the same time will lead to interference. 
In this case it's probably better to handle the color change by an OwnCommand. This will run completely independent and won't interfere with your lampshow.

Am 20.3.2022 um 11:57 schrieb Snux:

I'm passing all the "own command" type stuff to this second one

How do you connect them, via USB?

I never really looked into this, but I guess you could also use the second USB port of the DUE for this.

[Snux]

I fixed the GI, in my F14 code I just set a flag if I'm changing GI colour and check that when updating show lamps.  That plus setting the mode back to zero (not 1) fixed it nicely.

23 minutes ago, Black Knight said:

How do you connect them, via USB?

Normally you'd just connect TX -> RX and RX -> TX and use Serial.write and Serial.read.  However on the APC_LED board the standard TX and RX pins are being used as part of the 8 bits that come from APC, so I've used SoftwareSerial.

https://www.arduino.cc/en/Reference/softwareSerial

Means I can define 2 unused pins to be TX and RX.  I also used SoftwareSerial on the TFT Arduino because I want to use the normal (USB) serial monitor for debugging at the moment.

For the APC_LED code you can see the changes are very small.  I had to change the read of PINB to just digitalRead(8) as it was getting the way of me using pin 9, then add the open of the software serial port and the write statements.  Basically all it's doing is passing all command codes (except the 170 sync as too many of those) through to the TFT Arduino.  That Arduino then decides whether to ignore it or do something with it.  I'm sticking with commands over 200 to keep clear of everything else.  The APC LED board ignores the 200s completely other than passing it to the TFT board.

https://github.com/Snux/APC/blob/SnuxPrivate/DOC/Hardware/APC_LED_exp/APC_LED_exp.ino

The TFT code is pretty simple at the moment as it's just proof of concept

https://github.com/Snux/APC/blob/SnuxPrivate/DOC/Hardware/Arduino_TFT/Arduino_TFT.ino

[Snux]

Eventually I'm planning to show things on the TFT like progress in new modes, ammunition / altitude or something if I can think of a way to include in the game play.  Bigger font though

But now that as a proof of concept it's working I'll go back to focussing on the main game play.

Bearbeitet 21. März 2022 von Snux

[Snux]

The other reason I prefer SoftwareSerial in this case is that it's non blocking, there is no handshake or ack.  So there is a risk you can use data at high speed, but I've kept the speed on this low.  As it's non blocking, if the Arduino running the TFT isn't connected it doesn't matter.  If I was using hardware serial, it would hang when the buffer filled up.

[Snux]

On 3/21/2022 at 4:35 PM, Black Knight said:

I guess you could also use the second USB port of the DUE for this.

Possibly, but while I'm OK with making some small changes to the APC_LED code I really don't want to start playing around with the APC Due code especially with things that might interfere with timings and interrupts.  I prefer to leave that alone