DMX-Sender mit Xojo: Serial Port instabil?

OP (Firma: Q3) #4969618
Ich versuche mittels Serial Socket aus Xojo heraus (Mac) über einen 
USB-RS485-Adapter DMX-taugliche Geräte, z.B. einen Movinghead, 
anzusteuern. Der Adapter wird über einen Treiber von FTDI "FT232R" 
angesteuert.

Um das notwendige Protokoll hinzubekommen, habe ich eine etwas tricky 
Methode im Web gefunden (kenne nix anderes für die Erzeugung des 
"Break"), ausprobiert und es funktioniert meist:
1
if serial.open then
2

3
  serial.baud=50000 //Break erzeugen
4
  serial.reset //ist notw. um ohne erneutes Open den Speed zu ändern
5
  serial.write chrb(0)
6
  serial.xmitwait
7

8
  serial.baud=250000 //Universum senden
9
  serial.reset
10
  serial.write dmxbuf
11
  serial.xmitwait //wartet bis alle Zeichen aus dem Buffer sind
12

13
end if

(chrb ist wie chr, liefert aber garantiert nur 1 Byte, dmxbuf ist ein 
String mit der Länge von 512, wobei das erste Zeichen ein chrb(0) ist.)

Das funktioniert auch meistens (oft minutenlang), aber nicht immer. Vor 
Allem wenn andere Programme auf dem Mac im Hintergrund aktiv sind, 
beginnt der Movinghead gerne unvorhersehbar zu wackeln oder zu blitzen 
... was irgendwie nix anderes heissen kann, als dass die 512 Bytes des 
Universums nicht sauber rausgehen. Auch die Einkapselung der 
Senderoutine mit der Compilerdirektive "no background tasks" brachte 
keine Besserung.

Bei der Benutzung von professionellen DMX-Programmen passiert sowas 
übrigens nicht (beim gleichen USB-Adapter), also müssen die irgendwie 
einen anderen Zugang zu der virtuellen seriellen Schnittstelle haben.

Was ist die Ursache für meine Probleme mit dem serial Socket und wie 
kann ich die beheben? Danke für Tips.
#4969703
Keine Ahnung, was Xojo ist, aber der Mac hat an sich eine normale 
tty-API wie andere Unixe auch. Damit sollte es auch einen ioctl mit 
TIOCSBRK (Break an) bzw. TIOCCBRK (Break aus) geben. Schau mal, ob du 
den auch irgendwie aufrufen kannst.
Gast #4969808
Die Senderoutine muss in einen eigenen prozess der mit sehr hoher 
priorität im Hintergrund läuft. kommunikation zwischen dem hauptprogramm 
und dem Prozess über shared-memory...dazu ein ein output buffering etc.

Ich befürchte mit deiner "spielzeugsprache" bekommt man das nicht ohne 
weiteres hin..

Professionelle DMX Interfaces erledigen die Erzeugung des DMX Frames im 
Interface selber..so vermeidet man Timing-Probleme mit dem Host System, 
die trotz der o.g. Optionen auftreten können.
Persönliche Seite #4969827
Statt mit Kanonen auf Spatzen zu schießen könnte man hier auch direkt 
mit dem USB-Seriell-Adapter kommunizieren und die zu übertragenden Daten 
an der  Betriebssystem-API vorbei transferieren.

Der FT232R ist in der libftdi ausreichend gut dokumentiert.

https://www.intra2net.com/en/developer/libftdi/documentation/group__libftdi.html

Break & Co. können mit ftdi_set_line_property2 gesendet werden.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 9 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.