wenn ich in mAirList die serielle Fernsteuerung aktiviere, friert bei mir die Oberfläche ein, mAirList ist unbedienbar und macht 99% Systemlast, sobald ein Kommando über die Fernsteuerung reinkommt, oder mAirList aus einem Script heraus etwas an den seriellen Port sendet. Immer und reproduzierbar, sobald ich die serielle Fernsteuerung und das Notificationscript entferne, funktioniert alles.
Einstellungen der Schnittstelle sind 9600 Baud und Standard (8N1, keine Flusskontrolle weil CTS/RTS unbeschaltet), empfangen und gesendet werden nur Plaintext-Kommandos, terminiert mit CRLF (#13#10).
Gruß
Dominique Görsch
Nachtrag: in Build 534 tritt das Problem nicht auf, dort laufen serielle Fernsteuerung und auch das entsprechende Script problemlos.
Dominique, bitte lade dir doch nochmal den jetzt aktuellen Snapshot (derzeit 544) herunter. Nicht dass ich glaube, dass das Problem dort weg ist - aber es hat sich die Verwaltung der seriellen Schnittstellen dort grundlegend geändert (zentrale Einstellung der Parameter in mAirListConfig), und es wäre gut, wenn wir beide die gleiche Basis zum Testen/Fehlersuchen hätten.
Gesagt getan. Die hohe Systemlast und der Freeze der Oberfläche findet beim aktuellen Snapshot nichtmehr statt, allerdings funktioniert nun eins meiner Notificationscripte nichtmehr: “Während der Initialisierung sind die folgenden Fehler aufgetreten: Fehler beim Laden von M:\mAirList3\scripts\notification\Mixercontrol.mls: [Error] (14:39): Type mismatch”
Die relevante Stelle aus dem Script:
procedure OnStartup;
begin
ComPort(2).SendStr('RESET' + #13#10);
end;
Durch gezieltes Auskommentieren konnte ich feststellen, dass der Fehler überall dort vorkommt, wo mittels SendStr ein String mit Angehängtem #13#10 gesendet werden soll.
Der Fehler rührt vermutlich daher, dass die seriellen Schnittstellen jetzt über ihren Namen angesprochen werden und nicht mehr über die Nummer. Du musst also schreiben:
ComPort('COM2').SendStr('RESET' + #13#10);
Bitte damit mal testen
PS: Kann man eigentlich Einstellen, dass man nach dem Absenden einer Antwort zurück zum Thread und nicht zur Übersicht kommt? *narv*
Guck mal in deinem Profil unter “Profil”, da gibt es einen Haken “Nach dem Schreiben zum Thema zurückkehren?”
Danke, genau das wars.
Kann man eigentlich Konstanten innerhalb der Sciprte verwenden? Gerade bei umfangreicheren Scripten würde sich das ja z.B. für den Port anbieten…
Danke für den Hinweis mit der neuen Schreibweise…soweit meckert mAirList nun mit meinem PFL Script nicht mehr…
Kann es aber sein, daß sich noch etwas verändert hat? Unter mAirList 2 hat es bei PFL eine Flanke auf dem Comport gegeben, jetzt wird nur noch ein Puls rausgegeben…bzw. das Signal sofort wieder zurückgesetzt. Das Mischpult geht für den Bruchteil einer Sekunde in den PFL Modus und gleich weider raus…
[quote=“dgoersch, post:9, topic:5941”]Danke, genau das wars.
Kann man eigentlich Konstanten innerhalb der Sciprte verwenden? Gerade bei umfangreicheren Scripten würde sich das ja z.B. für den Port anbieten…[/quote]
Ich sehe hier ein grundlegendes Problem: Du vermischst zwei Arten der Ansteuerung des Ports. Einmal (wie man es für die Datenübertragung machen würde) über die IComPort-Schnittstelle, und einmal greifst du direkt per inpout32.dll auf den Port zu und veränderst ein Bit. Mich wundert, dass diese Mischung (bei mAirList 2.2) überhaupt funktioniert.
Welche Datenleitung setzt du denn da überhaupt? Funktioniert das eventuell, ohne dass man den Port überhaupt initialisieren muss?
…daher auch das abgewandelte Script. Das Script setzt am Comport den Flag “bereit” und dann stehen an einem Pin 12V/5V an…diese schalten dann über einen Optokopler an meinem Pult 2 Kontakte zusammen. Dadurch geht das Pult in den PFL-Modus.
Bitbanging unter Windows ist irgendwie immer ein bissl frickelig, ich seh das bei den simplen ISP-Programmierern für meine AVRs. Allerdings wird da auf allen Leitungen gebangt, das Script von Timo zieht ja nur DTR auf High…
btw, unten fehlt um die beiden ComPort-Befehle noch “begin” und “end”, sonst bezieht sich das “if” nur auf den SetDTR-Befehl, und das Close wird immer ausgeführt, auch wenn PFLCount > 0 ist.
