All Activity

OK, that's good. The problem for me is that the required buffer size depends on how fast the SD card can open a file. The standard buffer size for the DUE is 128 byte which is enough for my SD cards, but if Kobza got a slower one then he might have to increase the buffer size manually. Means I have to add a description how to to it. Of course I want to have the files and I'd be glad to add your exceptions to the next SW release. How large is the ZIP file, can we transfer it by mail? And what's your overall impression? Are you satisfied with the result? Anything mssing in the DOCs?

Hallo. Vielen Dank für den guten Tipp. War heute nachmittag am Gerät und der Fehler wurde gefunden. Das war ein fieses, verstecktes Ding. Bin wie empfohlen vorgegangen und konnte dann auch die Abtastspinne auf der Player Up Unit lokalisieren. Siehe dazu auch Foto. Die Kabelverbindung hin zur Spule an Score Reel Player 1, 1 K Scoring war jedoch einwandfrei. Letztlich stellte sich heraus, dass irgendwie der Strom nicht mehr richtig floss von der Stelle, wo das Verbindungskabel auf die Pertinax-Platte der Player-Up-Unit angelötet ist. Erst durch Zuppeln daran behob sich der Fehler. Unglaublich, weil es optisch einwandfrei aussah. Das sind natürlich die Fehler, die einen endlos suchen lassen. Wie auch immer: läuft wieder einwandfrei und wieder was dazugelernt. Gruß von Gorgar....

So, I'm also almost done with the sounds for F14 for pinmame. Manually edited each file to trim out some random noise at the start of each one and the exceptions file is 90% done to handle the few looping music tracks and suchlike. I also smoothed out a little the volume commands that are coming in as all values from 96 to 111 seem to be used when fading on F14..... else if (Command > 95 && Command < 112) { // music volume commands 0x6x MusicVolume = (Command - 96) / 4;} Finally played a couple of games without some odd sounds happening. @Black Knight do you want to PM me an email address? I have a zip file for you When I have the sounds exceptions finalised I can also email you that code too for pasting into your Github.

The only time I see that is occasionally when I press the button to gracefully shutdown Lisy. I guess that could be expected though because it might only send a partial and/or corrupted command when closing down. I've not seen that at any other time.

Good point. I also see something like this with my Pinbot, but as only flashers are affected in my case I never paid much attention to it. @bontangoDo you think that Lisy can prevent these first solenoid activation commands from being sent? Otherwise we would have to come up with individual Exceptions for each machine.

That's why I have removed the power switches on some of my Arduino boards. That means I can power my laptop and my pinball independently without any interference. I just got the info from Kobza that he sometimes sees an 'Unknown command' message in his pinball display when the game runs in PinMame and he's working with sounds. That would mean that the communication between Lisy and the APC is out of sync whic usually happens due to an overflow in the serial receive buffer. Do you also see something like this?

Klasse! An den einfachsten Fehler hab mal wieder nicht gedacht... Gut gemacht!

I worked around the coils firing on Lisy startup with a few extra lines in the exception code. Lisy is always firing the same coils (9 to 16), so I just stop all coil activation until I've seen 16 for the first time.. byte EX_F14Tomcat(byte Type, byte Command){ // Exceptions code for Tomcat static byte waiting_for_reset = 1; // At the moment Lisy is activating coils 9 to 16 immediately on startup // related to PIA initialisation in a real SYS11 MPU. We want to ignore // those so we'll wait until Lisy is reset properly switch(Type){ case SolenoidActCommand: // activate solenoids if (!waiting_for_reset) { // if we have already seen the reset, just permit the coil activation return(0); // by returning 0 } if (Command == 16){ // Coil 16 being activated for the first time is enough to know waiting_for_reset = 0; // that we can permit future coils, so unset the flag } return(1); // return 1 to prevent that coil activation

Läuft wieder! Ich habe einfach konstant Masse an die Fassung angelegt und konnte so feststellen, dass es lediglich die Fassung selbst war. Board wieder zwischengeklemmt und die Lampe dimmt nun kontinuierlich rein und raus.

Q1: 2N4403 Q2: 2N6348A C2: 0,1 uF 10% 100V (.1K100) C4: 0,47 uF 10% 100V (474K 100V)

Und ich habe mich bereits die ganze Zeit gewundert, warum es hier keinen Dateneingang von MPU oder anderer Stelle gibt. Also nur eine Dimmerschaltung? Und die läuft dann wahrscheinlich kontinuierlich. Die Komponenten sehe ich später nach...

Hört sich für mich nach Kabelbruch/Kabel ab an! Ich würde auf Spieler 2 schalten und dann hinten das 1000er Relais mit der Hand betätigen. Gleichzeitig dann mit einem Blatt Papier immer einen Wiper an der Player-Up-Unit isolieren bis ich weiss über welchen Kontakt die 1000 Punkte laufen. Dann schauen auf welchen Seitenanschluss dieser Kontakt bei Spieler 1 steht. Dann kannst Du von da mit einem Krokoklemmen-Kabel eine direkte Verbindung zur 1000er Spule bei Spieler 1 herstellen. Wenn das dann funktioniert hast Du einen Kabelbruch oder ein Kabel ist ab! Die Reset Relais benutzen einen anderen Strompfad! Deswegen funktioniert der Reset!

Wenn ich es richtig im Gedächtnis habe, wird der Flasher nicht angesteuert, sondern wird immer hell und dunkel gedimmt. Dafür spricht auch das weder beim Lampdriver noch beim Spulentreiber der Falsher als Ausgang angegeben ist, und auch das es nur 3 Anschlüsse gibt: 2x Stromversorgung und 1x Lampenausgang. Der LM339 ist ein 4xKomparator mit dem man solche Dimmerschaltungen realisieren kann. Wenn der Strom am Flasherboard ankommt, wird entweder die Lampe/Fassung defekt sein oder der LM339 bzw der fette Triac (?) mit dem Kühlkörper. Kannst Du mal nachsehen was bei Q1, Q2, C2 und C4 verbaut ist?

Nachbrenner: Auf ALLEN anderen Zählwerken funktioniert das gesamte Scoring einwandfrei!

Hallo zusammen. EIGENTLICH....sollte das ein einfaches Problem sein, doch einfach ist manchmal schwer oder was auch immer. Auf jeden Fall hänge ich fest. Fehler trat vollkommen unvermittelt auf, nachdem ich das Gerät länger nicht bespielt hatte (einige Wochen). RESET sämtlicher Spieler auf Null funktioniert einwandfrei - so auch Player 1 in Gänze. Was nicht mehr geht ist die Ansteuerung des Score Reels für Player 1, 1000er Scoring (3. Score Reel - hinten von links betrachtet). Das Ding wird einfach nicht weiter geschaltet, wenn 1000 Punkte erreicht wurden. Weder erfolgt eine Weiterschaltung, wenn ich DIREKT irgend einen beliebigen 1.000 Kontakt auf der Spielfläche oder direkt am 1 K- Punkte Relais generiere, noch erfolgt eine Weiterschaltung, wenn ich über die Hunderter in den Tausender Bereich komme. Es ist dann jedes Mal so, dass das 1 K Relais dauerhaft anzieht, die Spule am 1 K Score Reel überhaupt gar nicht anzieht. Ich habe sämtliche Kontakte im 3er Kontakbündel gesäubert/geschmirgelt. Ich habe den großen, senkrechten EOS Kontakt losgeschraubt und mit 600er gut geschmirgelt. KEINE LAGEÄNDERUNG! Ich habe auf gelöste Kabel an diesem Zählwerk kontrolliert und teilweise nachgelötet. Ich habe an der Player Up Unit die Spinnen gesäubert und auch die Abtastflächen angeschmirgelt. Es ist vermeintlich banal, doch diese vermalledeite Zählwerk rührt sich nicht. Es kommt kein Impuls an diese Spule, wenn 1 K generiert wird. Das 1 K Relais ist dauerhaft angezogen und fällt erst ab, wenn ich den großen EOS manuell öffne oder das 1 K Relais mit Druck zurückdrücke. Soviel zunächst. Vielleicht könnt ihr es euch aus der Ferne vorstellen, wenn ihr EM-Erfahrung habt. Danke und Gruß.....

Der Flasher ist wie folgt angeschlossen: orange - 7.4 V AC vom Rectifierboard (J3-10 / GI-Bus) grau - Ansteuerung von der Flasherplatine (J1-4) Die Kontakte an der Flasherplatine: blau - (J1-1) vom Rectifierboard (J3-6 / Feature Lamp Bus) J1-2 Key grün - (J1-3) vom Rectifierboard (J3-1 / GI-Return) J1-4 (s.o.)

Moin Spezis, nachdem ich nun mein aktuelles Projekt wieder spielbereit habe, fehlt mir noch eine Lösung zum Flasher in der Backbox. Dieser funktioniert wahrscheinlich nicht. Das wahrscheinlich bezieht sich darauf, dass ich ehrlich gesagt nicht weiß, in welcher Spielsituation der überhaupt aktiv sein sollte. Im Selbsttest ist keine Funktion gegeben. Nun gibt es ja bekanntlich nicht mehr so viele der Iron Maiden aus 1982 und somit sind technische Informationen ebenfalls rar. Der Flasher wird über eine separate Platine (IM-100 A2117) angesteuert. Vielleicht eine Art AuxLampDrv Board. Ich glaube diese Platine wurde in sonst keinem weiteren Early Stern verbaut. Der Flasher selbst ist eine GE 1183. Hat jemand eine Idee, wie ich die Funktion prüfen oder simulieren könnte? Es folgen gleich noch Fotos...

I also found that the 'F6' approach to dumping the sounds from pinmame misses some of them. I've seen Pinmame requesting music tracks which I don't have from F6. I just assumed that these are some "odd" ones like I've seen mentioned in the Pinbot exceptions code, but actually those sounds will dump properly by F5. Looks like I need to record some more

Now that is *nice*. I hadn't bothered connecting Lisy to my WiFi as I didn't think it needed it, but this is very useful and indeed much better than fiddling with the SD card. Might be worth putting in how to connect Lisy to WiFi to save finding the Lisy Manual and reading through to page 42 :). It's only a few lines.... (I also had to change the country from DE to GB) Makes sense. I tend not to leave the Arduino connected to my laptop unless I'm actually going to program it. If the pinball machine is switched off, all the 5v stuff remains powered (Arduino, Pi, my F14 LED displays etc), which all source their power from the USB output on my laptop and I'm not sure if that is healthy. Works, but might be a bit more load than it should take. But a power cycle for the few times when I hit the button by mistake is fine

Makes sense. Does also make sense. I'm going to take a look at this. Yes and it's also a good idea to press it before programming new SW into your Arduino. This is because after the programmer has stopped the Arduino it still takes a few ms before the blanking is invoked. During these ms the current display and lamp columns can light up much more than usual. This is not a big deal, but I think it's better to avoid it by pressing High Score Reset first, which invokes the blanking manually. A power cycle is not necessary, you can also use the serial monitor of the Arduino IDE to trigger a reset. BTW, as you're working with the Lisy debug mode at the moment - there's a more convenient way to use it then fiddling with the SD card. I've already put a preliminary documentation here. Please take a look at it and tell me whether it makes sense.

I think I'll put pure technical stuff about APC/Lisy here, and link back from my Pinside thread, and keep the Pinside thread for game development. Still working on the sounds at the moment, like Pinbot there is some slightly weird things happening with a couple of sounds, but I'll get them into the exceptions code. I'm also going to make some extension cables because it's a real mess in my backbox! One thought for an improvement but not urgent... with pinmame running, if I long-press the door button I get into APC settings (for Game/System). It would be great at that point if we could ignore what's coming in over USB (at least for the displays). The displays for APC settings constantly get overwritten by what Pinmame is sending. Also - pressing the high score reset button inside the door invokes blanking and you have to power cycle to bring things back. I guess that was intentional as an "emergency stop"? @bontango- there is another piece of code I developed for pinmame/P-ROC/Sys11 that I think you should also use for Lisy/Sys11. Not urgent though. https://github.com/vpinball/pinmame/blob/master/src/wpc/s11.c#L244 Basically in a physical machine the PIA states are unknown on power-up, so the WMS code resets all the coils to a known state by driving them on and off. This doesn't normally fire them physically as the blanking signal is still active. Once things are in a known state, blanking goes off and the game plays. For the P-ROC blanking came off a lot earlier and I blew lots of fuses during testing because all the coils fired at the same time. So my code fix simply looks for the "all coils driven" state and ignores it. With Lisy I'm seeing in the debug log right after it loads the ROMs the solenoid handler fires all solenoids from 9 to 16 (but not *all* solenoids) in less than 1ms. Doesn't blow a fuse but makes a loud noise! This is from the log, you'll see the coils firing at the end. So if we can avoid sending that, it would be good. LISY basic DEBUG activ [126.537295][0.000016] LISY DEBUG timer set [126.537547][0.000252] Info: udp switch reader server for debug mode succesfully started [126.537575][0.000028] LISY APC Hardware init start LISY_Mini: HW Client is: APC Info: serial com successfull initiated [127.539176][1.001601] check if connected hardware is"APC" [127.540055][0.000879] connected HW is: APC Info: check ID for 'APC' returns 0 [127.541087][0.001032] LISY_Mini: Client has SW version: 00.22 [127.542013][0.000926] LISY_Mini: Client uses API Version: 0.10 [127.542588][0.000575] LISY_Mini: Client supports 65 lamps [127.543146][0.000558] LISY_Mini: Client supports 25 solenoids [127.543697][0.000551] LISY_Mini: Client supports 5 displays [127.544434][0.000737] Display no:0 has type:0 (Display index is invalid or does not exist in machine.) with 0 segments [127.545174][0.000740] Display no:1 has type:4 (SEG14,Fully addressable 14 Segment Display (with comma)) with 7 segments [127.545911][0.000737] Display no:2 has type:4 (SEG14,Fully addressable 14 Segment Display (with comma)) with 7 segments [127.546645][0.000734] Display no:3 has type:3 (SEG7, Fully addressable 7 Segment Display (with comma)) with 7 segments [127.547413][0.000768] Display no:4 has type:3 (SEG7, Fully addressable 7 Segment Display (with comma)) with 7 segments [127.547965][0.000552] LISY_Mini: Client supports 73 switches Switch Status 1..8;9..16;17..24; ...: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 advance: 0 UP/Down: 0 [127.589854][0.041889] LISY DEBUG activ for coils [127.594089][0.004235] Info: LISYAPC Throttle value is 120 for this game LISY_APC: we are emulating Game No:44 f14_l1 info: trying to parse: /usr/local/share/xpinmame/xpinmamerc info: trying to parse: /root/.xpinmame/xpinmamerc info: trying to parse: /usr/local/share/xpinmame/xpinmame-vid_lisyrc info: trying to parse: /root/.xpinmame/xpinmame-vid_lisyrc info: trying to parse: /usr/local/share/xpinmame/rc/f14_l1rc info: trying to parse: /root/.xpinmame/rc/f14_l1rc Info: internal Hardware revision is 122 LISY80_SIG_HANDLER: SIGUSR1 catched This is LISY (Lisy W) by bontango, Version 527 67 [127.890058][0.295969] Info: LISYMINI this game has AC Relais on solenoid 14 [127.890209][0.000151] Info_boot: System_ID: SYS11A_ [127.890250][0.000041] Info_boot: gamename: F-14 TOMCAT [127.890289][0.000039] Info_boot: S2 Setting: 44 [127.890325][0.000036] Info_boot: SW Version: 527 67 [133.893444][6.003119] LISY_Mini: no special hw rules found for game 44, setting defaults [133.893516][0.000072] LISY_Mini: HW Rule set for solenoid:17 and switch:65 [133.893563][0.000047] LISY_Mini: HW Rule set for solenoid:18 and switch:66 [133.893602][0.000039] LISY_Mini: HW Rule set for solenoid:19 and switch:67 [133.893639][0.000037] LISY_Mini: HW Rule set for solenoid:20 and switch:68 [133.893676][0.000037] LISY_Mini: HW Rule set for solenoid:21 and switch:69 [133.893711][0.000035] LISY_Mini: HW Rule set for solenoid:22 and switch:70 loading rom 0: f14_u26.l1 loading rom 1: f14_u27.l1 done [134.366845][0.473134] LISY_W_SOLENOID_HANDLER: Solenoid:9, changed to 1 ( AC is 0) [134.366928][0.000083] LISY_W_SOLENOID_HANDLER: Solenoid:10, changed to 1 ( AC is 0) [134.366969][0.000041] LISY_W_SOLENOID_HANDLER: Solenoid:11, changed to 1 ( AC is 0) [134.367007][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:12, changed to 1 ( AC is 0) [134.367045][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:13, changed to 1 ( AC is 0) [134.367094][0.000049] LISY_W_SOLENOID_HANDLER: AC-Relais changed to 1 [134.367132][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:15, changed to 1 ( AC is 1) [134.367170][0.000038] LISY_W_SOLENOID_HANDLER: Solenoid:16, changed to 1 ( AC is 1) [134.413571][0.046401] LISY_W_SOLENOID_HANDLER: Solenoid:9, changed to 0 ( AC is 1) [134.413623][0.000052] LISY_W_SOLENOID_HANDLER: Solenoid:10, changed to 0 ( AC is 1) [134.413662][0.000039] LISY_W_SOLENOID_HANDLER: Solenoid:11, changed to 0 ( AC is 1) [134.413835][0.000173] LISY_W_SOLENOID_HANDLER: Solenoid:12, changed to 0 ( AC is 1) [134.413876][0.000041] LISY_W_SOLENOID_HANDLER: Solenoid:13, changed to 0 ( AC is 1) [134.413914][0.000038] LISY_W_SOLENOID_HANDLER: AC-Relais changed to 0 [134.413951][0.000037] LISY_W_SOLENOID_HANDLER: Solenoid:15, changed to 0 ( AC is 0) [134.413988][0.000037] LISY_W_SOLENOID_HANDLER: Solenoid:16, changed to 0 ( AC is 0) LISY80_SIG_HANDLER: received SIGUSR1 LISY80_SIG_HANDLER: initiated shutdown of xpinmame LISY Mini graceful shutdown initiated

Ich habe mal einen ersten Versuch zum Thema Schrittmotor gemacht. Das Prinzip ist auf dem Bild zu sehen und der vorläufige Code sieht so aus: void EX_StepperMotor(byte State) { // control stepper motor static byte MainTimer = 0; // number of the main timer static unsigned int RefTime; // stores the start value of the main timer static unsigned int PWMtime; // stores the PWM time for the active cycle switch(State) { // state machine case 0: // procedure is called from solenoid exception if (!MainTimer) { // initial call, stepper motor not yet running RefTime = 60; // set timeout to 60ms MainTimer = ActivateTimer(RefTime, 1, EX_StepperMotor);} // start main timer else { // not the first solenoid call from PinMame as main timer is already running PWMtime = RefTime - TimerValue[MainTimer]; // calculate time difference between PinMame's solenoid pulses KillTimer(MainTimer); // cancel timeout RefTime = PWMtime + 10; // set new timeout value based on last PWM cycle time MainTimer = ActivateTimer(RefTime, 1, EX_StepperMotor); // restart main timer ActivateSolenoid(PWMtime/2, 14); // generate PWM pulse on first solenoid ActivateTimer(PWMtime/4, 2, EX_StepperMotor);} // come back to generate pulse on second solenoid break; case 1: // timeout has occurred as no pulses from PinMame have been detected recently MainTimer = 0; // indicate that main timer is not active ActivateSolenoid(PWMtime/2, 14); // generate last step on the solenoids anyway ActivateTimer(PWMtime/4, 2, EX_StepperMotor); break; case 2: // generate pulse on second solenoid ActivateSolenoid(PWMtime/2, 15); break;}} Das Programm soll die PinMame Aufrufe an Spule 14 abfangen. Beim ersten Aufruf (State = 0) startet es nur einen Timer (MainTimer) für 60ms und wartet auf den nächsten Schritt von PinMame. Wenn der nächste Schritt kommt (wieder State = 0, aber der Timer läuft schon), dann wird der aktuelle Stand des Timers genommen (TimerValue[MainTimer]) und vom Startwert abgezogen. Dadurch kennen wir die PWMtime, die PinMame haben will und können die Erzeugung unserer eigenen Pulse starten. Der MainTimer wird mit der PWMtime + 10ms neu gestartet und misst wieder die Zeit bis zum nächsten Puls von PinMame. Sollte der MainTimer auslaufen, dann wird das als Ende der Schrittfolge gedeutet (timeout) und das Rad bleibt stehen, ein letzter Schritt wird aber noch nachgeholt, denn den haben wir ja am Anfang verpasst, als wir erst die PWMtime messen mussten. Ich habe diese Routine auch schon in V00.23 eingecheckt. Da ich deine Riverboat Exceptions aber nicht sehe müsstest du das Ding da eintragen. Dazu musst du folgenden Abschnitt in deine Exceptions einfügen: case SolenoidActCommand: // activate solenoids if (Command == 14){ // handle the activation of solenoid 14 EX_StepperMotor(0); // call the stepper motor handler return(1);} // ignore the command else if (Command == 15){ // handle the activation of solenoid 1 return(1);} // ignore the command return(0); // solenoid will be activated. Use return(1) to suppress this case SolenoidRelCommand: // deactivate solenoids if (Command == 14){ // handle the activation of solenoid 14 return(1);} // ignore the command else if (Command == 15){ // handle the activation of solenoid 1 return(1);} // ignore the command return(0); // solenoid will be deactivated. Use return(1) to suppress this Dadurch wird unsere Ex_StepperMotor Routine mit 0 als Parameter aufgerufen, wenn PinMame Spule 14 aktivieren will, ansonsten werden alle Kommandos für die Spulen 14 und 15 einfach ignoriert damit wir die alleinige Kontrolle darüber haben.

Hallo Medusa, Problem ist gelöst. War nur eine Lötstelle lose. Würde neu verlötet und er läuft wieder. Vielen Dank an alle, die mir geantwortet haben. LG Jürgen

Danke Dir Medusa. Werde das morgen gleich ausprobieren. Melde mich dann wieder bei Dir.