Talktimer & Aircheck reagieren falsch auf Befehle über COM

Deutsch / German mAirList 5.x
1

Moin Torben und Community,

nach dem neu Aufsetzen meines Windows 10 habe ich die neueste mAirList 5.3.16 Build 3275 installiert und seitdem hat sich folgender Fehler eingeschlichen:
Ich sende via Mikrocontroller bei Faderstart den Befehl “TALKTIMER START” und “AIRCHECK ON”, sowie entsprechend “TALKTIMER STOP” und “AIRCHECK OFF” an die mAirList via COM-Schnittstelle.
Bei meiner “alten” mAirList 5.3 (genaue Version und Build weiß ich leider nicht mehr) funktioniert die Steuerung der GUI-Objekte auch damit tadellos.
Nach der Neuinstallation habe ich nun reproduzierbar folgendes Verhalten festgestellt:

[tt]Senden von “TALKTIMER START”: [/tt]

  • Talktimer zählt los

[tt]Senden von “TALKTIMER STOP”:[/tt]

  • nichts passiert

[tt]Erneutes Senden von “TALKTIMER START”:[/tt]

  • Talktimer stoppt

Es scheint also, als würde der Talktimer nur beim Befehl “START” an und aus toggeln.
Umgekehrtes Verhalten allerdings beim Aircheck:

[tt]Senden von “AIRCHECK ON”:[/tt]

  • nichts passiert

[tt]Senden von “AIRCHECK OFF”:[/tt]

  • Aircheck startet Recording

[tt]Erneutes Senden von “AIRCHECK ON”:[/tt]

  • nichts passiert

[tt]Erneutes Senden von “AIRCHECK OFF”:[/tt]

  • Aircheck pausiert Recording

Ich habe schon mehrfach gecheckt, ob der Mikrocontroller wirklich die korrekten Befehle sendet, oder ob ich da irgendein Debouncing-Problem habe. Aber die Befehle gehen zuverlässig raus.

Ist das ein Bug, oder mache ich irgendwas falsch? Ich bin ziemlich sicher, dass das noch ging vor dem Update der mAirList.

Viele Grüße aus Hamburg!
Stefan

2

Schau doch mal in der Fernsteuerungs-Konsole (im Menü neben dem mAirList-Button), ob die Befehle richtig und ohne Zeitverzögerung ankommen.

Tippe auf letzteres wegen defekte Line Breaks etc.

3

Tatsächlich kommt in der Fernsteuerungs-Konsole immer nur einer der beiden gesendeten Befehle an.
Beim Auslösen von Faderstart sende ich:

Serial.write("TALKTIMER START"); Serial.write(cr); Serial.write("AIRCHECK ON"); Serial.write(cr);

Faderstop löst dann das hier aus:

Serial.write("TALKTIMER STOP"); Serial.write(cr); Serial.write("AIRCHECK OFF"); Serial.write(cr);

In der mAirList kommt aber beim Faderstart nur [tt]TALKTIMER START[/tt] an und beim Faderstop (und das ist noch viel verwirrender): [tt]AIRCHECK ON[/tt].
Ich frage mich gerade was ich falsch mache, dass meine Befehle in einer Art Warteschlange zu sein scheinen. Wenn ein erneuter Befehl kommt, wird nur der nächste, aber nicht der gewünschte/gesendete Befehl ausgeführt wird.

PS: die variable [tt]cr[/tt] ist natürlich die ASCII 13. Ausprobiert habe ich das auch mit dem Befehl println statt write, der jeden Befehl mit ASCII 13 und ASCII 10 abschließt. Gleiches Ergebnis.

4

Hast Du das vorher mal mit einem Terminal ausprobiert?
Oder anders rum lauscht da ein Terminal oder sonstiger De-Bugger noch mit?

Nutzt Du eine Native serielle Schnittstelle am Rechner oder ist das ein USB-Seriell Wandler?
Mit welcher Baudrate arbeitest Du?

5

Jup, da werden beide Befehle mit Zeilenumbruch korrekt angezeigt.

Nein, gleichzeitig geht nicht. Wenn entweder das Terminal oder mAirList lauscht, wirft das jeweils andere einen Fehler.

[quote=“shorty.xs, post:4, topic:11514”]Nutzt Du eine Native serielle Schnittstelle am Rechner oder ist das ein USB-Seriell Wandler?
Mit welcher Baudrate arbeitest Du?[/quote]
Das ist ein Arduino-Nachbau, entsprechend ein USB-Seriell Wandler.
9600 Baud. Die Befehle werden auch richtig in der Fernsteuerungs-Konsole angezeigt, nur eben einzeln und in komischer Reihenfolge (siehe letzter Post).

Aber wie gesagt, bin ich der Meinung, dass es vor dem mAirList Update funktionierte. Vorher war auf jeden Fall auch mindestens die 5.1 drauf. Und ich habe am Script oder der Schnittstelle nichts geändert.

6

Der Code, der nach CR sucht und die Daten auseinanderschneidet, ist eigentlich trivial und seit Jahren unverändert:

procedure TSerialRemote.DoProcessData(iData: RawByteString);
var
  s: RawByteString;
begin
  inherited;
  fData := fData + iData;

  if pos(AnsiChar(13), fData) > 0 then begin
    s := copy(fData, 1, pos(AnsiChar(13), fData) - 1);
    fData := copy(fData, pos(AnsiChar(13), fData) + 1 , maxInt);
    DoExecuteCommand(string(s));
  end;
end;

Ich wüsste nicht, wie sich da die Reihenfolge der Befehle ändern sollte.

Vielleicht nimmst du mal dieses kleine Hintergrundscript zur Hand, das die Rohdaten direkt ins Systemprotokoll schreibt:

procedure OnSerialData(Port: string; Data: AnsiString);
begin
  SystemLog(Port + ': ' + Data);
end;

Ergeben sich daraus irgendwelche Erkenntnisse?

7

Jup, da werden beide Befehle mit Zeilenumbruch korrekt angezeigt.[/quote]
Gut

Nein, gleichzeitig geht nicht. Wenn entweder das Terminal oder mAirList lauscht, wirft das jeweils andere einen Fehler.[/quote]
Genau darauf wollte ich hinaus. Es kann nur eine Anwendung auf den Seriell Port zugreifen, wenn da eine andere dazwischen Funkt, könnte das ein Problem sein aber ich nehme mal an, dass mAirlist den Port permanent offen hält.

[quote=“Bubbl, post:5, topic:11514”][quote=“shorty.xs, post:4, topic:11514”]Nutzt Du eine Native serielle Schnittstelle am Rechner oder ist das ein USB-Seriell Wandler?
Mit welcher Baudrate arbeitest Du?[/quote]
Das ist ein Arduino-Nachbau, entsprechend ein USB-Seriell Wandler.
9600 Baud. Die Befehle werden auch richtig in der Fernsteuerungs-Konsole angezeigt, nur eben einzeln und in komischer Reihenfolge (siehe letzter Post).

Aber wie gesagt, bin ich der Meinung, dass es vor dem mAirList Update funktionierte. Vorher war auf jeden Fall auch mindestens die 5.1 drauf. Und ich habe am Script oder der Schnittstelle nichts geändert.[/quote]
Ich dachte erst daran, dass das ein Treiber Problem sein könnte, durch den Treiber, den FTDI mal verteilt hat. (Den aktuellen Status kenne ich nicht)

Das scheint aber vom Fehlerbild her nicht zu passen. Die Baudrate ist auch nicht so wahnsinnig schnell, dass es da Probleme geben könnte. Totzdem, hast Du es mall schneller oder langsamer probiert?

Irgendwie sieht das Fehlerbild für mich aus wie ein Handshake Problem oder kommen die Befehle bei mAirlist an, werden dort aber nicht abgearbeitet?
Ich habe gerade kein mAirlist auf einem Rechner mit Seriell Port zur Hand, kann man das in mAirlist konfigurieren ob Hardware Handshake benutzt wird oder nicht? Wird Hardware Handshake überhaupt unterstützt vom Arduino (Clone)?

@Torben, ich habe auch schon Probleme mit Programmen gesehen, die beim Hardware Handshake die Pins nicht initialisieren, nach dem öffnen der Schnittstelle, wenn H/W Handshake benutzt wird. Das führt dann dazu, dass je nach dem wie die Serielle Schnittstelle designed wurde, dort unterschiedliche Zustände stehen können. Bei manchen Ports sind die Handshake Signale per default auf high, bei anderen auf low. Die Software muss also auf jeden Fall, einen definierten Zustand herstellen.
Wie macht mAirlist das?

Die Ursache dafür liegt darin, dass es nach der Norm, keine definierte Ausgangslage gibt. Das kann bei nativen seriellen Ports, Pci auf Seriell oder USB auf seriell jeweils anders sein, bei nativen ports sogar noch abhängig vom BIOS. Die Pegelwandler die in der Schaltung, dahinter kommen, tun ihr übriges obwohl sie eigentlich nur Transparent sein sollten. Ok, der Arudino hat keinen Pegelwandler, der arbeitet intern direkt mit dem TTL Pegel aus dem FTDI Chip.

8

Ich stecke da nicht so furchtbar im Thema drin. Um Hardware-Pins macht man sich als Programmierer heute eigentlich keine Gedanken mehr. Sondern benutzt einfach eine Library für den Zugriff. In meinem Fall diese hier: http://tpapro.sourceforge.net/ApdComPort.html

Kannst ja mal den Sourcecode durchsuchen, ob du irgendwie herausfindest, was sie macht, und was nicht, und was man ändern könnte.

https://github.com/TurboPack/AsyncPro

Aber wenn ich das richtig sehe, greift sie einfach nur auf das entsprechende Windows-Device \.\COMx zu.

9

Dass Du nicht low level mit dem Port redest ist mir schon klar aber Du sagst ja der Library wie sie den port öffnen soll.

Ich bin leider zu wenig Programmierer, um den Source Code zu verstehen.

Ich habe hier mal ein Beispiel, was unser Programmierer mal in C# gebaut hat, ich meine in C++ sieht das so ähnlich aus. Hier geht aus auch noch gezielt darum, eine Änderung des Handshake Pins zu detektieren um eine alte USV zu erkennen.

[code]//Serial-Port öffnen
try
{
serialPort = new SerialPort(_ComPort);
serialPort.PinChanged += new SerialPinChangedEventHandler(OnSerialPinChanged);
serialPort.Open();
serialPort.RtsEnable = true;

            TimeSpan intervall = new TimeSpan(0, 0, 10);
            _Timer = new Timer(new TimerCallback(timer_Elapsed), null, intervall, intervall);
        }[/code]

Du kannst ja die Library vermutlich auch so ansprechen, dass die für Dich den Hardware Handshake macht und die Kommunikation mit der Gegenstelle automatisch aushandelt, sonst müsstest Du dich ja selber ums timing kümmern. Da Du den port aber einfach nur öffnest, gehe ich mal davon aus, dass der Hardware Handshake, gar nicht aktiv ist und somit auch keine Auswirkungen hat/ haben sollte.

10

Ich weiß gar nicht genau, was du mit “Hardware Handshake” meinst - Flusskontrolle?

  {Hardware flow control types}
  THWFlowOptions = (
    hwfUseDTR,         {Use DTR for receive flow control}
    hwfUseRTS,         {Use RTS for receive flow control}
    hwfRequireDSR,     {Require DSR before transmitting}
    hwfRequireCTS);    {Require CTS before transmitting}

Das kann die Lib natürlich. Ich reiche die Optionen nur bislang nicht in die Config durch.

11

Ja, genau. Hardware Handshake = Flusskontrolle

Wenn Du das nicht durch reichst, wird es sicherlich auch nicht von der Lib genutzt und kann auch nicht dir Ursache für das Problem sein. Es seih denn, die Lib hätte einen Bug, wovon ich aufgrund des Alters der Technik und der Lib, mal nicht ausgehen würde.

Mich wundert nur, dass bei einem einfachen Terminal, das Problem der mehrfachen Befehle, vom Arduino nicht auftritt. Es kann also eigentlich auch kein Treiber- oder Hardware Problem sein.

12

Für die 6.1 kann ich dazu jetzt etwas anbieten. Ab Build 3870 kann man über Einträge im entsprechenden Abschnitt der serial.iin die verschiedenen Flusskontroll-Mechanismen aktivieren wie im Sourcecode von ApdComPort beschrieben:

  {Hardware flow control types}
  THWFlowOptions = (
    hwfUseDTR,         {Use DTR for receive flow control}
    hwfUseRTS,         {Use RTS for receive flow control}
    hwfRequireDSR,     {Require DSR before transmitting}
    hwfRequireCTS);    {Require CTS before transmitting}
  end;

Angabe jeweils ohne das “hwf” davor, als z.B. “UseDTR=on”.

13

Moin,

ich weiß, das Thema ist schon so alt. Ich bin aber leider jetzt erst dazu gekommen mich nochmal damit zu beschäftigen. Ich hatte auch gehofft, dass sich das mit der 6.1 jetzt erledigt hat. Leider ist das nicht so. Gleicher Fehler wie oben beschrieben.

Ich sende mit dem Arduino mehrere Befehle über die COM-Schnittstelle. Nicht alle davon sind für mAirList.

Beispiel:
Ich ziehe Mic 1 auf, vom Arduino wird folgendes gesendet:

-- MIC 1 ON -- MIC ON TALKTIMER START AIRCHECK ON

Beim schließen des Kontakts entsprechend das Gegenteil:

-- MIC 1 OFF -- MIC OFF TALKTIMER STOP AIRCHECK OFF

Die Befehle mit Prefix “–” sind momentan zur Kontrolle, was ankommt und was nicht.
Wenn ich nun ein paar Mal das Mic auf und zu mache, kommen immer öfter weniger Zeilen an (laut Fernsteuerungs-Konsole in mAirlist). Es werden irgendwann immer nur noch zwei Befehle angezeigt. Diese zwei Befehle sind aber NICHT die, die gerade gesendet werden. Sondern mit dem Hinzufügen weiterer Zeilen, werden nur die zwei nächsten in der “Warteschlange” angezeigt und ausgeführt.
Ist schwer zu beschreiben. Beispiel:
Also angenommen gesendet habe ich ein paar Mal den Vierzeiler von oben. Dann kommen beim ersten Mal Senden (nach mAirlist Programmstart) alle vier Zeilen an. Beim zweiten Mal Senden nur noch die ersten beiden Zeilen. Und beim dritten Mal Senden kommen nur die fehlenden zwei Zeilen des vorherigen Befehls. Beim vierten Mal Senden dann die ersten beiden Zeilen des dritten Befehls, beim fünften Mal Senden die zweiten beiden Zeilen des dritten Befehls, usw. So staut sich das immer weiter auf.
Ich hoffe, das ist einigermaßen verständlich.

Ausprobiert habe ich in der serial.ini jetzt sowohl “UseDTR=on” als auch “UseRTS=on”, leider ohne Veränderung. Mit der verlinkten Library oben kann ich vom Verständnis wenig anfangen :slight_smile:

Ich bin ratlos. Wenn ich im Terminal oder im Serial-Monitor des Arduino die Befehle beobachte, werden mir alle angezeigt.

14

Welchen 6.1-Build verwendest du da jetzt?

15

Kann das an dem Arduino clone liegen? Die haben ja teilweise ziemlich exotische USB-Seriellwandler drauf.
Ich hätte gerade einen Arduino Nano Clone zur Hand. Magst Du Dein Scetch mal teilen?

Dann könnte man das zumindest schon mal etwas einkreisen. Ich wollte mir da was mit Midi bauen, also Nativ über die Serial Pins vom Arduino, nicht über USB. Da könnte ich aber auch mal einen orginal FTDI dran hängen zum Vergleich, ob das einen Unterschied macht für mAirlist.

16

Momentan ist es die mAirList 6.1.5 build 3898.

[quote=“shorty.xs, post:15, topic:11514”]Kann das an dem Arduino clone liegen? Die haben ja teilweise ziemlich exotische USB-Seriellwandler drauf.
Ich hätte gerade einen Arduino Nano Clone zur Hand. Magst Du Dein Scetch mal teilen?[/quote]

Hmm. Das lese ich zum ersten mal mit den exotischen Seriellwandlern. Ich habe aber auch noch einen originalen hier liegen, das könnte ich ja relativ leicht ausprobieren. Den Sketch würde ich ungern in voller Länge teilen, da da doch sehr viel Arbeit drin steckt (ressourcensparend, Debouncing, etc). Letztenendes frage ich im betroffenen Code ab, ob sich der Status der Inputs geändert hat. Wenn ja, setze ich eine Variable und feuere das serielle Kommando (s.o.) ab. Die Variable setzt dann später im Code die Outputs.

Edit: Soeben den MEGA-Clone gegen einen originalen UNO ersetzt. Keine Veränderung. In der Serial-Konsole der Arduino-Software werden alle Befehle korrekt angezeigt. In der mAirList Fernsteuerungs-Konsole (wie oben genannt) immer nur die ersten zwei Zeilen der “Befehlsliste”.

Edit 2: Habe mir nochmal zur Sicherheit eine unabhängige Software (Serial Port Monitor / RS232 Sniffer) installiert. Auch dort werden immer alle vier Befehle empfangen und angezeigt. Die Software stellt auch nochmal die HEX-Daten usw. zur Verfügung. Hab mal einen Screenshot angehängt. Dort sieht man auch, dass die Zeilen mit 0d und 0a (also ASCII CR LF bzw. DEZ 13 10) abgeschlossen werden.

Ausschnitt Loop:

if ((button_mp_mic_on_reading != button_mp_mic_on_state)){ button_mp_mic_on_state = button_mp_mic_on_reading; if(button_mp_mic_on_reading) { mic_on = HIGH; Serial.println("-- MIC ON"); } else { mic_on = LOW; Serial.println("-- MIC OFF"); } Check_Inputs(); set_talktimer(); }

Ausschnitt set_talktimer():

if(mic_on && !talktimer_on){ Serial.println("TALKTIMER START"); Serial.println("AIRCHECK ON"); talktimer_on = HIGH; } else if (!mic_on) { Serial.println("TALKTIMER STOP"); Serial.println("AIRCHECK OFF"); talktimer_on = LOW; }

mairlist_serial.PNG

17

Moin Torben und shorty,

hatte jetzt am Wochenende bei einem Event wieder genau den Fehler über COM, diesmal mit einem anderen Mikrocontroller (CH340).
Der Fehler ist verrückterweise auch aufgetreten, obwohl ich nur einen Befehl zur Zeit sende, also stinknormalen Faderstart. Bei den ersten 2-3 Malen klappt es, danach wird kurios beim Hochziehen von Fader 1 einfach das “STOP PLAYER 1-2” von zuvor ausgeführt, statt des gesendeten “START PLAYER 1-1”.
Ich bin leider mit meinen Ideen am Ende woran es liegen könnte, zeigen mir doch jedes mal die COM-Sniffing-Programme (siehe letzter Post) die korrekten Befehle an :o

LG Stefan

18

Hier ist eine Debug-Version basierend auf dem aktuellen 6.1-Snapshot:

https://cloud.mairlist.com/index.php/s/ReCHCjF5qf3ekdb

Sie öffnet ein zusätzliches Konsolenfenster, wo du alle empfangenen Bytes als Hex in Echtzeit mitlesen kannst.

Kommen die Daten dort auch schon verzögert an? Wenn ja, dann liegt der Fehler in der von mir verwendeten Library (AsyncPro) - und wird nur sehr, sehr schwer zu debuggen sein :frowning:

19

Hi Torben,
es ist nun wieder ein bisschen Zeit vergangen. Sorry dafür.

Ich bin jetzt kein Profi im Umgang mit HEX-Editoren. Wenn ich mich nicht täusche, kommen im Konsolenfenster der mairlist-Debug-Version alle Befehle richtig an.
Ich habe mal einen kurzen Screencast und einen Screenshot gemacht und hier angehängt:
https://www.dropbox.com/s/gnuap2diyaz28op/mairlist_debug.mp4?dl=0

Oben links im Bild ist eine Serial-Monitoring-Software, die den entsprechenden Comport überwacht und die Befehle korrekt anzeigt, wie ich sie auch mit dem Arduino sende.
Unten dann das Konsolenfenster der Debug-mairlist.
Und ganz rechts dann noch die Fernsteuerungskonsole von mairlist zum Vergleich.

Für mich macht es dein Eindruck, dass die Fernsteuerung der mairlist nicht die Befehle ausführt, die im von dir erstellten debug-Fenster ankommen. Oder (über-)sehe ich da was falsch?

LG Stefan

Anmerkung zum angehängten Screenshot:
4 Zeilen sind ausgegraut, da der Arduino 4 Zeilen bereits bei Initialisierung der Schnittstelle abfeuert. Aber auch hier sieht man schon, dass das, was in der debug-Konsole angezeigt wird, nicht mit dem übereinstimmt, was in der Fernsteuerungskonsole rechts steht.

screenshot.PNG

20

Sehe den Fehler. Passiert, wenn mehrere Befehle gleichzeitig empfangen werden und (intern) in einem “Paket” landen.

Teste mal bitte Snapshot 3938, ob es dort besser ist.