Jump to content

Recommended Posts

Am 8.6.2019 um 16:09 schrieb Black Knight:

Die Kommandos 'Set Sound Volume' und 'Init/Reset' haben beide die gleich Nummer (0x36). Ich werde 'Init/Reset' daher jetzt als (0x37) implementieren.

Da es Init vorher schon gab würde ich gerne Set Sound Volume als 0x37 nehmen.

Ich habe gerade mal die Fehler in dem Dokument korrigiert. Ich werde jetzt mal die neuen Commands implementieren. Dazu muss die Hardware dann API Version >= 9 zurückgeben.

vor einer Stunde schrieb jabdoa:

AssertionError: Invalid LISY hardware version b''

Da sieht es mir aus als wenn er beim Command 0 gar keinen String zurück gibt. Kann das sein? Er gibt da genau aus was er gelesen hat (einen leeren String). Kannst du einmal "debug: True" in die "lisy:" section setzen. Dann sollte im Log genau stehen was er ließt und schreibt.

Link to post
Share on other sites
  • Replies 1.4k
  • Created
  • Last Reply

Top Posters In This Topic

vor 11 Minuten schrieb jabdoa:
Am 8.6.2019 um 16:09 schrieb Black Knight:

Die Kommandos 'Set Sound Volume' und 'Init/Reset' haben beide die gleich Nummer (0x36). Ich werde 'Init/Reset' daher jetzt als (0x37) implementieren.

Da es Init vorher schon gab würde ich gerne Set Sound Volume als 0x37 nehmen. 

Kommando zurück. Ich war verwirrt. 0x36 ist SetSoundVolume. Init/Reset ist 100 oder 0x64. Ist mir irgendwo kaputt gegangen. Sorry!

Link to post
Share on other sites
11 hours ago, jabdoa said:

Kannst du einmal "debug: True" in die "lisy:" section setzen

Dan bekomme ich

mpf.exceptions.ConfigFileError.ConfigFileError: Config File Error in ConfigValidator: Your config contains a value for the setting "lisy:debug", but this is not a valid setting name. Error Code: CFE-ConfigValidator-2

Ich habe jetzt erst mal meine alte Config-Datei genommen, die sieht so aus:

#config_version=5

hardware:
    platform: lisy
    coils: system11

# lisy:
    # connection: network
    # network_port: 1234
    # network_host: "localhost"
    
lisy:
   connection: serial
   port: com3
   baud: 115200
   debug: True

system11:
  ac_relay_driver: c_ac_relay

switches:
    s_test00:
        number: 00
    s_test37:
        number: 37
    s_test77_nc:
        number: 77
        type: 'NC'

coils:
    c_test:
        number: 0
    c_test1_c_side:
        number: 1c
    c_test1_a_side:
        number: 1a
    c_ac_relay:
        number: 12
        allow_enable: True

segment_displays:
  info_display:
    number: 0
  player1_display:
    number: 1
  player2_display:
    number: 2

 

10 hours ago, jabdoa said:

Du kannst hier gucken was MPF erwartet beim Starten:

Also APC\00 sollte als Antwort auf eine Null kommen. Ich verstehe seine Erwartungen bei der Anzahl der Spulen u.s.w. noch nicht so ganz, heißt das er will genau 9 Spulen oder mindestens 9 …?

Link to post
Share on other sites
vor 9 Minuten schrieb Black Knight:

Ich verstehe seine Erwartungen bei der Anzahl der Spulen u.s.w. noch nicht so ganz, heißt das er will genau 9 Spulen oder mindestens 9 …? 

Das ist die maximale Anzahl an Spulen. Wenn du 100 zurück gibst kann man in MPF Coils 0-99 konfigurieren. Wenn man Coil 100 oder 101 konfiguriert wird MPF einen Fehler werfen.

 

vor 11 Minuten schrieb Black Knight:
vor 11 Stunden schrieb jabdoa:

Kannst du einmal "debug: True" in die "lisy:" section setzen

Dan bekomme ich


mpf.exceptions.ConfigFileError.ConfigFileError: Config File Error in ConfigValidator: Your config contains a value for the setting "lisy:debug", but this is not a valid setting name. Error Code: CFE-ConfigValidator-2

Sieht so aus als wenn da was nicht gebaut hat bei uns. Fixe ich heute Abend. An sich sollte das aber trotzdem so funktionieren. Vielleicht kommen beim Command davor zwei null Bytes zurück?

Link to post
Share on other sites
11 minutes ago, jabdoa said:

Das ist die maximale Anzahl an Spulen. Wenn du 100 zurück gibst kann man in MPF Coils 0-99 konfigurieren.

Das verstehe ich, aber was hat denn die 9 bei den 'expected commands' für eine Bedeutung

        self.serialMock.expected_commands = {
            b'\x00': b'APC\00',         # hw APC
            b'\x01': b'0.02\00',        # APC version
            b'\x02': b'0.09\00',        # api version
            b'\x64': b'\x00',           # reset -> ok
            b'\x03': b'\x28',           # get number of lamps -> 40
            b'\x04': b'\x09',           # get number of solenoids -> 9
            b'\x06': b'\x05',           # get number of displays -> 5
            b'\x09': b'\x58',           # get number of switches -> 88
            b'\x13': b'\x00',           # get number of modern lights -> 0
            b'\x1e\x00': None,          # clear display
            b'\x1f\x00': None,          # clear display
            b'\x20\x00': None,          # clear display
    

 

13 minutes ago, jabdoa said:

Vielleicht kommen beim Command davor zwei null Bytes zurück?

Das ist möglich. Wir benutzen ja den normalen Arduino USB-Port und da sitzt ja auch noch der USB-Controller zwischen, der den Haupt-Controller bei Bedarf neu programmiert. Um ehrlich zu sein habe ich keine Ahnung, was das Ding nach einem Reset zurück gibt, bevor der Haupt-Controller übernimmt.

Da werde ich gleich mal mit Ralf drüber sprechen, der hat die Kommunikation mit Lisy ja am laufen.

Link to post
Share on other sites
vor einer Stunde schrieb Black Knight:

Um ehrlich zu sein habe ich keine Ahnung, was das Ding nach einem Reset zurück gibt, bevor der Haupt-Controller übernimmt.

Ich auch nicht, aber ich denke er muss ja irgendwie rauskriegen ob er (nach einem Reset durch DTR) gerade programmiert werde soll

oder ob das ne 'normale' serielle Kommunikation ist die da losläuft. Kann sein dass er da sehr früh (über die Firmware) zwei Nullbytes schickt.

In meiner Initroutine öffne ich den seriellen Port, das setzt normaleweise DTR woraufhin der Arduino einen Reset macht.

Dann warte ich eine Sekunde und werfe danach erst einmal alles was sich ggf. im Empfangsbuffer befindet weg bevor

ich '\0' schicke und auf eine Antwort vom Arduino warte. Das wiederhole ich bis zu 10 mal bevor ich aufgebe.

 

Code:

    //start with asking for Hardware string
    //for init we reapeat that up to ten times in case
    //the other side ( Arduino) needs time to resset
    //set the command first
    cmd = LISY_G_HW;
    //and flush buffer
    sleep(1); //need to wait a bit beofre doing that
    tcflush(lisy_usb_serfd,TCIOFLUSH);
    //now send and try to read answer (one byte)
    ret = tries = 0;
    do
    {
        //send cmd
     if ( write( lisy_usb_serfd,&cmd,1) != 1)
      {
        printf("Error writing to serial %s\n",strerror(errno));
        return -1;
      }

      //read answer
        if ( ( ret = read(lisy_usb_serfd,&data,1)) != 1)
         {
           tries++; //count tries
           sleep(1); //wait a second
           tcflush(lisy_usb_serfd,TCIOFLUSH); //flush buffers
           fprintf(stderr,"send cmd to %s, %d times\n",portname,tries);
         }
    }
    while( (ret == 0) & ( tries < ARDUINO_NO_TRIES));

 

Link to post
Share on other sites
Am 14.5.2019 um 18:40 schrieb bontango:

Ein Sache noch für die Fehlerliste: C20 (100nF) ist in der BOM ne DIP Variante, auf dem Board aber SMD

Wie ist denn die Bestellnummer für C20 bei Reichelt? In der pdf auf github ist immer noch die Dip drin! Wollte morgen eh was bestellen....

Link to post
Share on other sites
1 hour ago, Volley said:

Aber laut Liste soll es doch ein 220N sein. C10 ist doch nur 100N?

Schau bitte nochmal nach. Auch C20 ist bei mir  ein 100n.

Wenn ich mich nicht irre, dann gibt's auf dem APC gar keine 220n.

Link to post
Share on other sites

Hi Frank,

ich habe gerade einbaut, dass MPF nach einer falschen Response (also ungleich 0) den buffer löscht und es danach nochmal versucht. Außerdem sollte debug jetzt gehen. Kannst du Version "0.53.0-dev.36" probieren und ein Log anhängen falls es nicht geht?

Jan

Link to post
Share on other sites
46 minutes ago, jabdoa said:

Kannst du Version "0.53.0-dev.36" probieren und ein Log anhängen falls es nicht geht?

Alles klar, probiere ich morgen aus.

@bontango Das dein Comet momentan mit PinMame nur Kraut in den Displays anzeigt liegt übrigens daran, dass wir die Displaysteuerung noch nicht so umgebaut haben, wie wir Ende April beschlossen haben. Der Jan hat das unter 'Set Segment Display 0-6 (0x1E - 0x24)' sehr schön beschrieben: je nachdem ob es ein numerisches (bis einschl. Sys9) oder ein alphanumerisches (Sys11) Display ist, müssen die Daten anders übertragen werden.
Dein Comet ist ein Sys9 und daher überträgt PinMame BCD Daten, du benutzt allerdings ein alphanumerisches Display, das mit BCD nichts anfangen kann und siehst daher nur Kram. Damit du mal was siehst müsstest du in USBcontrol.ino folgende Änderung vornehmen 

	case 31:                                              // set display 1 to
//		if (APC_settings[DisplayType] > 4) {
//			DisplayBCD(1, SerialBuffer);}
//		else {
//			WritePlayerDisplay((char*)SerialBuffer, 1);}
    for (i=0; i<7; i++) {
      SerialBuffer[i] = (SerialBuffer[i] & 127) + 48;}
    WritePlayerDisplay((char*)SerialBuffer, 1);
		break;

Damit werden die Daten für das Player 1 Display von BCD nach Segmentdaten konvertiert (das Komma haben ich jetzt mal ignoriert).

Das ist natürlich nur zum testen, letztendlich sollte es wie folgt laufen:

Lisy fragt mit 'Get Segment Display Details (0x07)' beim APC an, welche Displays angeschlossen sind. Wenn als Antwort 'BCD' kommt, dann schickt Lisy BCD Daten (ob wir die '7_1-segment' Einstellung brauchen überlege ich mir noch) und bei '14_2-segment' müssen es Segment-Daten sein.

Wir hatten ja schon gesagt, dass die Segmentdaten in zwei Bytes übertragen werden sollten (14 Segment + Komma + Punkt) allerdings müssten wir uns noch auf die genaue Belegung der zwei Bytes einigen. Mein Vorschlag wäre, einfach die APC-Belegung zu verwenden, damit würden wir uns die Arbeit ersparen jeden Buchstaben in Segmenten abzubilden, da ich das vor ein paar Jahren schon gemacht habe. Die Belegung wäre dann d, c, b, a, e, f, g, Komma für's erste Byte und j, h, m, k, p, r , Punkt, n für's zweite. Ich habe mal ein Bild angehängt, wie die Segmente bei Williams zugeordnet sind.

 

DispSegments.PNG.7d7afcad92f82fab681152f37d02ec54.PNG

Link to post
Share on other sites
16 hours ago, jabdoa said:

Kannst du Version "0.53.0-dev.36" probieren und ein Log anhängen falls es nicht geht?

Die Debug-Option funktioniert jetzt, die Kontaktaufnahme zum APC leider immer noch nicht. Das Log-File sieht aus wie folgt:

2019-06-16 10:59:44,343 : INFO : Machine : Mission Pinball Framework Core Engine v0.53.0-dev.36
2019-06-16 10:59:44,343 : INFO : Machine : Command line arguments: {'no_load_cache': False, 'create_config_cache': True, 'bcp': True, 'configfile': ['config.yaml'], 'mpfconfigfile': 'c:\\users\\ff\\appdata\\local\\programs\\python\\python36\\lib\\site-packages\\mpf\\mpfconfig.yaml', 'force_assets_load': False, 'jsonlogging': False, 'logfile': 'logs\\2019-06-16-10-59-44-mpf-LAPTOP-SF35AA1F.log', 'pause': False, 'production': False, 'text_ui': True, 'loglevel': 15, 'consoleloglevel': 20, 'force_platform': None, 'syslog_address': None, 'mc_file_name': None, 'no_sound': False}
2019-06-16 10:59:44,343 : INFO : Machine : MPF path: c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf
2019-06-16 10:59:44,343 : INFO : Machine : Machine path: C:\Users\ff\MPF\Rollergames
2019-06-16 10:59:44,343 : INFO : Machine : Platform: win32
2019-06-16 10:59:44,343 : INFO : Machine : Python executable location: c:\users\ff\appdata\local\programs\python\python36\python.exe
2019-06-16 10:59:44,343 : INFO : Machine : Python version: 3.6.4 (64-bit)
2019-06-16 10:59:44,343 : INFO : Machine : Machine config file #1: config.yaml
2019-06-16 10:59:44,343 : WARNING : ConfigProcessor : Config file in cache changed: C:\Users\ff\MPF\Rollergames\config\config.yaml
2019-06-16 10:59:44,343 : INFO : ConfigProcessor : Loading config from file c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\mpfconfig.yaml.
2019-06-16 10:59:44,528 : INFO : ConfigProcessor : Loading config: c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\mpfconfig.yaml
2019-06-16 10:59:44,544 : INFO : ConfigProcessor : Loading config from file C:\Users\ff\MPF\Rollergames\config\config.yaml.
2019-06-16 10:59:44,578 : INFO : ConfigProcessor : Loading config: C:\Users\ff\MPF\Rollergames\config\config.yaml
2019-06-16 10:59:44,583 : INFO : ConfigProcessor : Config file cache created: C:\Users\ff\AppData\Local\Temp\5379302b5e3ea4e88c53f77f445884d7.mpf_cache
2019-06-16 10:59:44,600 : INFO : Machine : Initialise MPF.
2019-06-16 10:59:45,378 : INFO : lisy : Connecting to com3 at 115200bps
2019-06-16 10:59:45,483 : WARNING : lisy : Reset of LISY failed. Got 65 instead of 0. Will retry.
2019-06-16 10:59:45,979 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:46,474 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:46,979 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:47,464 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:47,979 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:48,464 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:48,974 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:49,464 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:49,979 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:50,469 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2019-06-16 10:59:50,654 : INFO : Machine : Shutting down...
2019-06-16 10:59:50,654 : INFO : EventManager : Event: ======'shutdown'====== Args={}
2019-06-16 10:59:50,794 : ERROR : Machine : Failed to initialise MPF
Traceback (most recent call last):
  File "c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\core\machine.py", line 715, in initialise_mpf
    raise init.exception()
  File "c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\core\machine.py", line 229, in initialise
    yield from self.initialise_core_and_hardware()
  File "c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\core\machine.py", line 224, in initialise_core_and_hardware
    yield from self._initialize_platforms()
  File "c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\core\machine.py", line 318, in _initialize_platforms
    result.result()
  File "c:\users\ff\appdata\local\programs\python\python36\lib\site-packages\mpf\platforms\lisy\lisy.py", line 260, in initialize
    raise AssertionError("Invalid LISY hardware version {}".format(type_str))
AssertionError: Invalid LISY hardware version b''
2019-06-16 10:59:50,804 : INFO : root : MPF run loop ended.

Ich kann in dem File leider nicht erkennen, was der MPF sendet, aber da er sagt 'Reset of Lisy failed' nehme ich an, er schickt das Init Kommando (0x64) und bekommt beim ersten Mal anstelle von Null eine 64 zurück. Danach scheint nichts mehr zu kommen.

Ich habe bei meinem Terminalprogramm mal den DTR Switch gesetzt, so dass er jetzt beim Verbinden auch einen Reset auslöst. Wenn ich danach eine 64 sende bekomme ich komischerweise zwei Nullen zurück. Außerdem ist 64 ja der ASCII Code eines 'A', das könnte also der Anfang von APC\00 sein.

Hast du eigentlich schon einen Arduino? Du kannst die Kontaktaufnahme nämlich auch ohne APC Board testen, dann müsste ich dir nur schreiben was du dazu im Code ändern musst.

Frank

 

Link to post
Share on other sites

Hi Frank,
Starte MPF mal mit "mpf -v -V" dann solltest du vollen debug output bekommen.

vor 16 Stunden schrieb Black Knight:

Wir hatten ja schon gesagt, dass die Segmentdaten in zwei Bytes übertragen werden sollten (14 Segment + Komma + Punkt) allerdings müssten wir uns noch auf die genaue Belegung der zwei Bytes einigen. Mein Vorschlag wäre, einfach die APC-Belegung zu verwenden, damit würden wir uns die Arbeit ersparen jeden Buchstaben in Segmenten abzubilden, da ich das vor ein paar Jahren schon gemacht habe. Die Belegung wäre dann d, c, b, a, e, f, g, Komma für's erste Byte und j, h, m, k, p, r , Punkt, n für's zweite. Ich habe mal ein Bild angehängt, wie die Segmente bei Williams zugeordnet sind.

  

DispSegments.PNG.7d7afcad92f82fab681152f37d02ec54.PNG

 

Das wäre dann 14_2 und 7_1 oder? Das können wir gerne so machen. Ich baue eine Mappingtabelle und dann schickt MPF das entsprechend.

Bzgl. unterschiedlicher Displays in einer Machine können wir natürlich auch den Typ pro Display abfragen wenn du willst.

 

Jan

 

Link to post
Share on other sites
29 minutes ago, jabdoa said:

Starte MPF mal mit "mpf -v -V" dann solltest du vollen debug output bekommen

Den habe ich jetzt, die wohl entscheidende Passage ist:

2019-06-16 12:08:27,908 : DEBUG : lisy : Sending reset.
2019-06-16 12:08:27,908 : DEBUG : lisy : Sending 100
2019-06-16 12:08:27,908 : DEBUG : lisy : Reading one byte
2019-06-16 12:08:28,064 : DEBUG : lisy : Received 0
2019-06-16 12:08:28,064 : DEBUG : lisy : Sending 0
2019-06-16 12:08:28,064 : DEBUG : lisy : Reading zero terminated string
2019-06-16 12:08:28,064 : DEBUG : lisy : Received b''
2019-06-16 12:08:28,080 : INFO : Machine : Shutting down...

Nach einigen Timeouts kriegt er also endlich seine Null, aber den String kriegt er nicht.

Kann es sein, dass du mit einer Null zu wenig rechnest? Wir hatten ja gesagt, dass ich eine Null senden soll, wenn die Verbindung steht. Offensichtlich schickt MPF danach nochmal einen Init (0x64) und bekommt daraufhin wieder eine Null zur Bestätigung zurück. Anschließend sendet MPF eine Null um die Hardware Version zu erfragen, hat aber vom Init noch eine Null im Lesepuffer, die er nun als Ende des Strings interpretiert und damit einen Leerstring hat.

38 minutes ago, jabdoa said:

Das wäre dann 14_2 und 7_1 oder? Das können wir gerne so machen. Ich baue eine Mappingtabelle und dann schickt MPF das entsprechend.

Mappingtabelle brauchst du nicht zu machen, die gibt es im APC.ino schon:

const byte AlphaUpper[118] = {0,0,0,0,0,0,0,0,107,21,0,0,0,0,0,0,0,0,0,0,64,191,64,21,0,0,64,4,0,0,0,40, // Blank $ * + - / for upper row alphanumeric displays
		63,0,6,0,93,4,15,4,102,4,107,4,123,4,14,0,127,4,111,4,0,0,0,0,136,0,65,4,0,34,0,0,0,0, // 0 1 2 3 4 5 6 7 8 9 < = > and fill bytes
		126,4,15,21,57,0,15,17,121,4,120,4,59,4,118,4,0,17,23,0,112,136,49,0,54,10,54,130,63,0, // Pattern A B C D E F G H I J K L M N O
		124,4,63,128,124,132,107,4,8,17,55,0,48,40,54,160,0,170,0,26,9,40}; // Pattern P Q R S T U V W X Y Z

Da sind Zahlen, Buchstaben und ein paar Sonderzeichen für die von mir vorgeschlagene Bytebelegung schon definiert.

Wenn du selbst Zeichen basteln möchtest kannst du mein kleines Perl-Script nehmen. Wenn du das in einer Konsole startest kannst du die Buchstaben eines Segmentes und Enter eingeben, um das Segment zu setzen bzw. zu löschen (q zum Beenden). Die beiden Definitionsbytes werden unten immer angezeigt.

Link to post
Share on other sites
vor 17 Minuten schrieb Black Knight:

Kann es sein, dass du mit einer Null zu wenig rechnest? Wir hatten ja gesagt, dass ich eine Null senden soll, wenn die Verbindung steht. Offensichtlich schickt MPF danach nochmal einen Init (0x64) und bekommt daraufhin wieder eine Null zur Bestätigung zurück. Anschließend sendet MPF eine Null um die Hardware Version zu erfragen, hat aber vom Init noch eine Null im Lesepuffer, die er nun als Ende des Strings interpretiert und damit einen Leerstring hat.

Ja MPF schickt als erstes einen Init/Reset. Danach erwartet er eine Null. Ich kann einbauen, dass wir jedes Mal den Inputbuffer wegwerfen wenn wir den Command senden. Gib mir ein paar Minuten bitte.

Link to post
Share on other sites

Das klappt noch nicht, immer noch der gleiche Fehler.

Aber es ist das Problem mit der zusätzlichen Null, denn ich habe im APC jetzt mal eingestellt, dass er das Kommando 0x64 ignoriert und dann läuft's, zumindest bis er ein Kommando 0x13 bekommt, mit dem er (und ich) nichts anfangen kann.

2019-06-16 13:30:14,695 : DEBUG : lisy : Sending reset.
2019-06-16 13:30:14,695 : DEBUG : lisy : Sending 100
2019-06-16 13:30:14,695 : DEBUG : lisy : Reading one byte
2019-06-16 13:30:14,836 : DEBUG : lisy : Received 0
2019-06-16 13:30:14,836 : DEBUG : lisy : Sending 0
2019-06-16 13:30:14,836 : DEBUG : lisy : Reading zero terminated string
2019-06-16 13:30:14,852 : DEBUG : lisy : Received b'APC'
2019-06-16 13:30:14,852 : DEBUG : lisy : Sending 1
2019-06-16 13:30:14,852 : DEBUG : lisy : Reading zero terminated string
2019-06-16 13:30:14,867 : DEBUG : lisy : Received b'0.02'
2019-06-16 13:30:14,867 : DEBUG : lisy : Sending 2
2019-06-16 13:30:14,867 : DEBUG : lisy : Reading zero terminated string
2019-06-16 13:30:14,883 : DEBUG : lisy : Received b'0.09'
2019-06-16 13:30:14,883 : DEBUG : lisy : Connected to b'APC' hardware. LISY version: b'0.02'. API version: b'0.09'.
2019-06-16 13:30:14,883 : INFO : EventManager : Event: ======'machine_var_lisy_hardware'====== Args={'value': b'APC', 'prev_value': None, 'change': True}
2019-06-16 13:30:14,883 : INFO : EventManager : Event: ======'machine_var_lisy_version'====== Args={'value': b'0.02', 'prev_value': None, 'change': True}
2019-06-16 13:30:14,883 : INFO : EventManager : Event: ======'machine_var_lisy_api_version'====== Args={'value': b'0.09', 'prev_value': None, 'change': True}
2019-06-16 13:30:14,883 : DEBUG : lisy : Sending 3
2019-06-16 13:30:14,883 : DEBUG : lisy : Reading one byte
2019-06-16 13:30:14,899 : DEBUG : lisy : Received 64
2019-06-16 13:30:14,899 : DEBUG : lisy : Sending 4
2019-06-16 13:30:14,899 : DEBUG : lisy : Reading one byte
2019-06-16 13:30:14,914 : DEBUG : lisy : Received 24
2019-06-16 13:30:14,914 : DEBUG : lisy : Sending 6
2019-06-16 13:30:14,914 : DEBUG : lisy : Reading one byte
2019-06-16 13:30:14,930 : DEBUG : lisy : Received 2
2019-06-16 13:30:14,930 : DEBUG : lisy : Sending 9
2019-06-16 13:30:14,930 : DEBUG : lisy : Reading one byte
2019-06-16 13:30:14,945 : DEBUG : lisy : Received 73
2019-06-16 13:30:14,945 : DEBUG : lisy : Sending 19
2019-06-16 13:30:14,945 : DEBUG : lisy : Reading one byte
2019-06-16 13:30:31,134 : DEBUG : asciimatics.screen : Processing mouse: 28, 37
2019-06-16 13:30:31,134 : DEBUG : asciimatics.widgets : New event: MouseEvent (28, 37) 0

Du kannst du den Init am Anfang auch sparen, denn wenn nach dem Reset die erste Null kommt, dann hat er sowieo alles initialisiert.

Bin jetzt mal für 2 Stunden weg, danach kann ich weiter frickeln.

Edited by Black Knight
Link to post
Share on other sites

Wann sendet der APC denn die Response?

Nach dem Starten sendet er eine 0 oder? Es ist also gut möglich, dass MPF das für die Antwort von seinem "Init/Reset" Command hält. Ja das macht Sinn und es ist unmöglich die beiden "0" voneinander zu unterscheiden für MPF. Selbst wenn wir es könnten würde MPF danach ein Command senden was der APC nicht bekommen würde weil er neustartet.

Ich denke wir müssen das DTS beim Starten fixen. Da habe ich ggf eine Lösung für. Ist aber unter Windows und Linux jeweils etwas anders daher kann das auch schief gehen. Leider geht das wohl auch nicht 100%tig bei allen USB-Serials. Mit Arduino sollte meine Lösung aber eigentlich gehen.

In 0.53.0-dev.38 habe ich das DTS toggle ausgeschaltet so gut es geht (wie man es für Arduino in Linux und Windows macht) und den Flush des Serials noch etwas verbessert.

 

Jan

Link to post
Share on other sites
vor 52 Minuten schrieb Black Knight:

zumindest bis er ein Kommando 0x13 bekommt, mit dem er (und ich) nichts anfangen kann.

Das ist das hier: http://docs.missionpinball.org/en/dev/hardware/lisy/protocol.html#get-count-of-modern-lights-0x13 Da willst du vermutlich eine 0 zurückgeben. Da kannst du später die seriellen LEDs mit ansteuern z.b.

vor 2 Minuten schrieb bontango:

Und wenn ihr die init response ändert und zB 1 zurück schickt? Dann kann man am Anfang alle Nullen wegwerfen und auf die eins warten?! 

Das Problem ist dass der APC das ja nicht unterscheiden kann ob er per 0x64 resettet wurde oder durch powercycle/DTS. Er sendet immer nach dem Neustart eine 0 (oder eine 1). Und da sich DTS und Init überschneiden ist es auf beiden Seiten schwierig. Am einfachsten ist es wenn wir DTS wegbekommen.

Jan

Link to post
Share on other sites
vor 21 Minuten schrieb jabdoa:

Das Problem ist dass der APC das ja nicht unterscheiden kann ob er per 0x64 resettet wurde oder durch powercycle/DTS.

und wenn der 0x64 nur nen internen Reset auslöst und dann '1' zurück geben würde? Ich denke am Anfang müssen wir ja nicht direkt die 'dicke Keule' schwingen oder?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines