doremi RAW Device Kommunikation

[grausi]

Hallo,

 

Zwar eher eine Technik Frage, aber das Problem scheint beim Doremi DCP-2K4 zu liegen...

 

Wir möchten gern ein Relais-Modul per Ethernet mit unseren Doremi DCP-2K4 steuern. Dafür hätten wir ein RAW-Device eingerichtet und entsprechende Makros eingerichtet.

Leider scheint am Relais-Modul die Nachricht nicht passend anzukommen.

Ich habe auf einem PC ein TCP-Listener-Programm eingerichtet und die Zeichenfolge vom doremi scheint richtig zu sein, nur (vermute ich) scheint beim Verbindungsauf- abbau etwas nicht ordnungsgemäß zu sein. Mit dem TCP-Tool kann ich vom PC aus das Modul einwandfrei steuern.

Hat wer einen Tipp für mich? Gibt 's dazu (RAW-Device, TCP-Messages am Doremi) ein Handbuch?

 

Danke!

Liebe Grüße Matthias

[MUOF]

hast du schone alle möglichen Einstellungen getestet? Port TCP/UDP? Binär/Text?

 

Muss ein Abschlusszeichen folgen nach den Befehlen ? ( "\r\n" z.b.)

[marktgerecht]

Wir haben das mit einer IP-Steckdose hinbekommen.

 

Wichtig ist, dass die Befehle im Makro nicht über copy/paste vom Windows-PC über VNC eingegeben werden, sondern direkt am Doremi.

 

Wie lauten denn die Befehle, die in den Makros stehen sollen?

[ChrisL]

Wir haben ebenfalls so ein DCA Modul, funktioniert wunderbar.

 

Einfach mal die kleinen Stolperfallen kontrollieren:

- IP Adresse

- Protokoll

- Port

 

Ein Befehl sieht bei uns folgendermaßen aus:

kinoton-command=relay_module_2_relay_7_impuls_013\r\n

 

Je nach Relaismodul und Relais ändert sich einfach nur die Nummer des Moduls oder Relais.

Auch 2 Befehle sind in einem Makro so ohne weiteres möglich.

 

Gruß

Chris

[grausi]

hallo,

 

danke erstmal für die tipps!

 

es ist ein ETHRLY16 von Robot Electronics. IP-Adresse und Port stimmen und Protokol ist TCP.

Ich hab sowohl HEX (bei Message steht zwar binary, aber wenn man einen ungültigen Wert eingibt sagt die Fehlermeldung "invalid hexadecimal message") als auch TEXT probiert.

Bei TEXT nur den jeweiligen Buchstaben, als auch mit \r\n oder nur \n.

Das Makro wird immer erfolgreich ausgeführt!

 

Hier noch eine Website mit zusätzlichen Infos: http://mainstreetanswers.org/ethrly16/ bzw. die Dokumentation vom Hersteller http://www.robot-electronics.co.uk/htm/eth_rly16tech.htm

 

Ich hab noch am doremi-FTP gesehen, dass es ein Hotfix für den MacroEditor gibt. Weiß da jemand bescheid? Ist von 2009, also sollte in der aktuellen Software schon enthalten sein, oder?

 

Danke!

Liebe Grüße, Matthias

[grausi]

hab nun auch bei ROBOT ELECTRONICS nachgefragt. die meinen, dass nichts besonderes beachtet werden muss.

tcp verbindung, richtige ip und port und das war 's.

 

hat wer eine idee, mit was ich evtl. im terminal die verbindung testen könnte am doremi? curl oder nc sind leider nicht installiert...

[ChrisL]

Hast du mal nachgeschaut was für eine IP und für ein Subnetz im Doremi und entsprechend im Modul eingetragen ist?

[grausi]

sind beide im kino-internen 192er netz. beim doremi ist das eth1.

ich probiers mal mit einer 172er adresse vom eth0 netz...

[marktgerecht]

Wir haben unsere IP-Steckdosen IP mässig im ETH0-Netz

[ChrisL]

Kommt hier eben auch auf das subnetz drauf an, am besten 255.255.255.0 eintragen, damit sind alle 254 adressen im 192.168.x.x Netz verfügbar.

 

Bei unserem Projektor ist z.B. 255.255.255.128 eingetragen (warum auch immer?! :rolleyes:) und somit gehen nur Adressen von 192.168.x.130 bis 192.168.x.254, die auf den Projektor zugreifen können - da er selbst 192.168.x.129 hat.

 

Die Doremis bei uns haben 192.168.x.133 mit dem Subnetz 255.255.0.0 und können somit die IPs von 192.168.1.1 bis 192.168.255.254 erreichen.

 

Macht die Sache im gesamten Kinonetz erheblich leichter, da ich von meinen Kassen PCs somit auf alle Devices im gesamten BWR zugreifen kann.

 

Frag aber nur keinen älteren Techniker nach einer sinnvollen Lösung für dieses Problem, da wird dir nur teure Technik angedreht :rolleyes:

[grausi]

hab 's jetzt im eth0 netz ausprobiert.

172.20.x.x mit 255.255.0.0

funktioniert auch nicht...

[ChrisL]

Das ist schon merkwürdig, wenn wirklich alles richtig eingestellt ist.

Bist du dir sicher, dass die Befehle von deinem Windows Programm im Klartext verschickt werden?!

 

Noch ein Edit zu meinem Post, es muss 192.168.x.128 bis 192.168.x.254 heißen :)

[grausi]

ich hab grad vom pc per telnet nochmal probiert und vergessen die verbindung zu beenden

und hab dann am doremi einen fehler bekommen, dass er das makro nicht ausführen kann.

nachdem ich die telnet verbindung beendet habe, hat er das makro wieder erfolgreich ausführen können.

das muss meiner einschätzung nach heißen, dass der doremi verbindung hat, aber die steuerzeichen im falschen format (oder ähnliches) beim relais-modul ankommen. leider gibt es beim relais-modul keine debug funktion...

[grausi]

also wenn ich mit netcat die message abfange bekomme ich genau das selbe, wie zb. von einer telnet verbindung, nur mit dem unterschied dass der doremi die verbindung sofort beendet...

[Vogel]

Hast du Mal versucht, das Dingen zu pingen?

[Hondo]

...zu deinem ersten Post:

was für ein TCP-Listener Programm verwendest du denn?

Ich empfehle (Freeware) Wireshark, da sieht man alle möglichen Informationen einer Verbindung, und auch Blocking-Reports.

Ansonsten scheinst ja du alles richtig gemacht zu haben, es bleibt die Möglichkeit eines Hardware-Defekts.

Grüßle,

Hondo

[HaraldSchaefer]

Hallo

 

Ich vermute mal, deine TCP Device hat einen Atmega Prozessor und vermutlich läuft darauf eine ETHmx Variant von Ulrich Radig. Dessen Telnet Server ist absolut inkompatibel zu dem was der Doremi via Raw Device ausgibt. Das Problem liegt darin, dass der Doremi die Verbindung sofort wieder trennt und der Server die Daten nicht vernünftig puffert. Die einzige Chance ist die Software des Controlers zu modifizieren.

 

Mir ist es nicht gelungen den Telnet Server so anzupassen dass er zuverlässig funktioniert hat (am Ende kam zwar eine Kommunikation zu stande, aber dafür sind immer wieder Zeichen verloren gegangen). Die Doremi RAW Device ist einfach kein Telnet Client. Die meisten Server kommen damit klar, aber halt nicht alle.

 

Wenn Du Zugriff auf die Software hast, dann versuche sie mal so zu ändern, dass die Kommunikation via UDP läuft.

 

Gruß Harald

[grausi]

Hast du Mal versucht, das Dingen zu pingen?

 

ja, ist erreichbar.

 

 

...zu deinem ersten Post:

was für ein TCP-Listener Programm verwendest du denn?

Ich empfehle (Freeware) Wireshark, da sieht man alle möglichen Informationen einer Verbindung, und auch Blocking-Reports.

Ansonsten scheinst ja du alles richtig gemacht zu haben, es bleibt die Möglichkeit eines Hardware-Defekts.

Grüßle,

Hondo

 

TansuTCP. Ich werd mir Wireshark gleich mal anschaun, danke!

Defekt ist zu 99% auszuschließen, da sich das Modul vom PC aus steuern lässt...

 

 

Hallo

 

Ich vermute mal, deine TCP Device hat einen Atmega Prozessor und vermutlich läuft darauf eine ETHmx Variant von Ulrich Radig. Dessen Telnet Server ist absolut inkompatibel zu dem was der Doremi via Raw Device ausgibt. Das Problem liegt darin, dass der Doremi die Verbindung sofort wieder trennt und der Server die Daten nicht vernünftig puffert. Die einzige Chance ist die Software des Controlers zu modifizieren.

 

Mir ist es nicht gelungen den Telnet Server so anzupassen dass er zuverlässig funktioniert hat (am Ende kam zwar eine Kommunikation zu stande, aber dafür sind immer wieder Zeichen verloren gegangen). Die Doremi RAW Device ist einfach kein Telnet Client. Die meisten Server kommen damit klar, aber halt nicht alle.

 

Wenn Du Zugriff auf die Software hast, dann versuche sie mal so zu ändern, dass die Kommunikation via UDP läuft.

 

Gruß Harald

 

es ist ein PIC18F67J60 drauf. telnet ist nicht zwingend notwendig, aber das mit dem puffer befürchte ich auch...

ich werd mal bei robot electronics nachhacken, ob man zugriff auf die board-software hat/bekommt.

 

Vielen Dank an alle erstmals für die Tipps! Ich werd mich melden, sobald es Neuigkeiten gibt!

[grausi]

Hallo miteinander,

 

für alle, die es interessiert: ich hab nun eine lösung gefunden.

wie HaraldSchaefer bereits vermutet hat, ist die geschwindigkeit das problem!

ich hab nun am zentralen netzwerkserver bei uns ein kleines skript geschrieben, dass die messages vom doremi empfängt und dann an die relais-module weiterleitet.

damit das ganze funktioniert, wird der string (oder was auch immer gesendet wird) um eine sekunde verzögert (also verbindungsaufbau -> 1s dealay -> message).

 

LG Matthias

[carstenk]

Hast Du es mal direkt versucht, aber mit '\w' vor und nach dem Kommando auf dem Doremi? Dein Kistchen ist nicht das einzige Gerät, das Probleme mit dem Doremi Timingverhalten hat. \w fügt eine Pause ein.

 

 

'First, try surrounding the command text in the Doremi server with \w. Put \w before the command and after the command. This inserts a short delay to allow the target device to get the command before the server disconnects.'

 

- Carsten

[Hondo]

@Carsten:

 

Kannst du mir die Quelle für den \w (wait?) Befehl nennen?

Wie lange ist dieses Delay und kann ich das mehrfach nacheinander ausführen? (Ein erster Test ging ins Leere...)

 

Grüßle

[grausi]

Hast Du es mal direkt versucht, aber mit '\w' vor und nach dem Kommando auf dem Doremi? Dein Kistchen ist nicht das einzige Gerät, das Probleme mit dem Doremi Timingverhalten hat. \w fügt eine Pause ein.

 

 

'First, try surrounding the command text in the Doremi server with \w. Put \w before the command and after the command. This inserts a short delay to allow the target device to get the command before the server disconnects.'

 

- Carsten

 

danke, danke, danke!! bei mir funktionierts mit \w STEUERZEICHEN \w !!

wenn das natürlich in irgendeiner dokumentation stehen würde...