Arnim Posted March 16, 2013 at 08:53 PM Share Posted March 16, 2013 at 08:53 PM 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. Quote Link to comment Share on other sites More sharing options...
batti Posted March 17, 2013 at 03:42 PM Share Posted March 17, 2013 at 03:42 PM Wie ist denn dein RS485 Netzwerk konfiguriert? Quote Link to comment Share on other sites More sharing options...
Arnim Posted March 17, 2013 at 04:13 PM Author Share Posted March 17, 2013 at 04:13 PM @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 Quote Link to comment Share on other sites More sharing options...
borg Posted March 17, 2013 at 08:47 PM Share Posted March 17, 2013 at 08:47 PM 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. Quote Link to comment Share on other sites More sharing options...
Arnim Posted March 18, 2013 at 10:46 AM Author Share Posted March 18, 2013 at 10:46 AM @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! Quote Link to comment Share on other sites More sharing options...
AuronX Posted March 18, 2013 at 10:54 AM Share Posted March 18, 2013 at 10:54 AM @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 ^^) Quote Link to comment Share on other sites More sharing options...
borg Posted March 18, 2013 at 11:55 AM Share Posted March 18, 2013 at 11:55 AM 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.