RS485 Latenz bei IO16 GetPort?

[Arnim]

Eine Frage an TF (oder wer immer sich hier kompetent sieht):

 

Ich betreibe an einer RS485-Verbindung mehrere Master mit IO16 und fahre hier einen GetPort. Ein GetPort benötigt hierbei ca. 8ms vom Aufruf bis zur Rückgabe, also eine Ewigkeit. Ist das die normale Latenz bei RS485? (Win7, C#, SW2.x)

 

Betreibe ich den Brick direkt am USB liegt der Zyklus eines GetPort bei unter 1ms.

 

Und dazu gleich die zweite Frage:

 

Wenn das schon so gemutlich ist, wäre es dann nicht zumindest möglich in der Software einen GetPort zu implementieren, der beide Ports direkt, also in einem Rutsch abfragt? Wenn ich davon ausgehe, dass dieser Aufruf nicht langsamer wäre, würde dies meine Anwendung um 50% beschleunigen, da ich immer beide Ports abfragen muss.

 

Danke, Arnim.

[batti]

Wie ist denn dein RS485 Netzwerk konfiguriert?

[Arnim]

@Batti: Wenn Du schon so fragst: Hast Du Vergleicheswerte was eigentlich zu erwarten sein müsste? Und liege ich das völlig aus der Welt?

 

Ich habe das RS485 recht simpel eingerichtet:

- 2Mbit

- Keine Parität

- 1 Stop-Bit

- Einen Master + Einen Slave (beide Termination on)

- 30 cm verdrilltes Kabel dazwischen

[borg]

Naja das kann schon hin kommen. Du musst halt gucken was alles passiert. Deine Daten gehen von deinem Programm per TCP/IP an den Brick Daemon, der schickt es über USB an den Eingangsbuffer von Master1, der schiebt es in den RS485 Ausgangsbuffer, von da geht es in den Eingangsbuffer von Master2, der gibt es an das Bricklet weiter. Dort wird dann per I2C der Port abgefragt und das ganze geht den weg wieder zurück.

 

An allen Buffern kann ein Delay von 1ms auftreten, dazu kommt dann noch die Zeit die das eigentliche ausführen benötigt und schon kommst du auf 8ms.

 

Beide Ports gleichzeitig abfragen ist technisch natürlich möglich, ob das noch auf das IO16 EEPROM passt weiß ich aber nicht. Ich schreibe es mir mal auf die TODO Liste mir das anzugucken.

 

Ich werd auch mal ein paar Tests bzgl der Roundtrip Time machen, dann können wir das entsprechend dokumentieren. Das wird aber nichts in den nächsten paar Tagen.

[Arnim]

@borg: Danke für die Antwort.

 

Habe ich die deutliche Latzenz in der Doku eigentlich nur überlesen oder ist das bisher noch nirgends thematisiert? Ich kann mich nur erinnern, irgendwo von den 2Mbit im RS485 gelesen zu haben und wie flott alles geht. Aber knapp 10ms pro GetPort sind ja gerade mal 100 Zyklen je Sekunde, also nicht mal ein Kbit effektiver Durchsatz. Ich denke das sollte man schon deutlich erwähnen - für meine Anwendung bedeutet das leider - in dieser Form - das aus. Ich bin immer von 2-3ms maximal ausgegangen.

 

Ich muss auch feststellen, dass sich mir bei einer direkt Zykluszeit von unter 1ms (direkt am Brick per USB) nicht erschließt wo die Daten für weitere 7ms im System hägen bleiben, die werden ja vermutlich nicht per Buschtrommel über die RS485-Leitung geschickt.

 

Bitte versteht das nicht als Meckern, sondern als Wunsch, klare Gegebenheiten auch deutlich zu dokumentieren - fast 10ms Zyklus für ein einziges GetPort ist (in meinen Augen) einfach völlig aus der Welt wenn man sich den Hightech rund um euer System anschaut. Zumindest sollte man es eben wissen.

 

Was den kombinierten GetPort angeht: Das wäre genial!

[AuronX]

@borg: Ist das auch eine Nebenwirkung des Schedulings auf Millisekunden-Basis?

 

Ich habe die Befürchtung, dass das an weit mehr Enden Probleme verursacht als bisher angenommen... (es wäre vielleicht sinnvoll eine Liste mit Problemen zu führen die auf das aktuelle Scheduling zurückzuführen sind... fände ich interessant ^^)

[borg]

In gewisser Weise hängt es damit natürlich zusammen. Ein System welches nur dafür da wäre IO16 Werte über eine RS485 Verbindung auszulesen könnte sicherlich schneller sein.

 

Ich müsste mal zwei Stack mit unserem Logic Analyzer verkabeln um herauszufinden wo genau wieviel Zeit verloren geht.