RS-485-Geräte transparent verbinden

Ich habe einen Hauptcomputer mit einer RS-485-Karte. Über dieses Kommunikationsboard kommuniziert es mit seinen Subsystemen.
Ich habe auch einen Testcomputer, der über einen RS-485-Kanal mit der Hauptplatine verbunden ist. Es wird zum Testen und Aktualisieren der Subsysteme verwendet, die diese RS-485-Kanäle verwenden.

Ich möchte, dass sich der Hauptcomputer gegenüber dem Testcomputer transparent verhält, sodass der Hauptcomputer nichts über den Testalgorithmus weiß. Ich möchte den Hauptcomputer nicht aktualisieren, wenn sich die Testalgorithmen ändern.
Wenn ich meine Hardware entworfen hätte, würde ich einen FPGA verwenden, um den Testcomputer physisch mit den Subsystemen zu verbinden, sodass der Testcomputer die Subsysteme direkt verbindet und der Hauptcomputer nichts über Tests weiß, aber ich verwende einen Standardcomputer und eine Kommunikation Karte.

Was würden Sie tun, um den Testcomputer und die Subsysteme zu verbinden, ohne dem Hauptcomputer testbezogene Algorithmen hinzuzufügen?

Blockdiagramm

RS-485 ermöglicht Multidrop-Verkabelung. In diesem Aufbau könnte es nur einen einzigen gemeinsamen RS-485-Bus geben, bei dem jeder einzelne Knoten einfach die Drähte anzapft, ohne dass Pakete umgeschaltet oder wiedergegeben werden.

Antworten (1)

Nun, es gibt viele mögliche Lösungen ... aber Sie haben nicht genug Informationen darüber gegeben, wie die Kommunikation zwischen dem Testcomputer und den Subsystemen wirklich aussieht. Liegt es ganz bei Ihnen, was Sie implementieren? Ich gehe davon aus, dass dies der Fall ist, aber die Lösung würde sich wahrscheinlich ändern, wenn das Protokoll über RS485 bereits definiert oder ausgewählt ist.

Die meisten Kommunikationsprotokolle auf dieser Ebene enthalten eine Art von eingebauter Adressierung .

Wenn Sie mit dem Versenden von Binärstrukturen vertraut sind, definieren Sie einfach eine Struktur, mit der jede Nachricht beginnt und die Folgendes enthält:

  • Die Länge der gesamten Nachricht in Bytes
  • Die Adresse des Subsystems, mit dem Sie sprechen möchten
  • Die Adresse des Subsystems, von dem Sie sprechen (optional)
  • Der Befehl, den Sie an das Subsystem ausgeben möchten

Sie würden jede Nachricht mit diesem Header beginnen, dann alle erforderlichen Daten übergeben und schließlich optional (aber es wird bei RS485-Links dringend empfohlen) eine Prüfsumme oder einen CRC des Headers und der Daten senden.

Der Hauptcomputer muss an diesem Punkt nichts anderes tun, als den Nachrichtenheader zu lesen, die Länge zu sehen und diese an das entsprechende Subsystem weiterzuleiten. Es muss nicht einmal wissen, wo die Adressen sind ... Sie könnten die Nachricht einfach an alle drei Subsysteme senden. Wenn sich die Befehle ändern und die Daten sich ändern, ändert sich das Nachrichtenformat nicht ... so kann die Logik des Hauptcomputers dieselbe bleiben.

Die Antwort des Subsystems sollte dasselbe Format haben.

Es ist nützlich, die Adresse des FROM-Knotens anzugeben, damit das Subsystem weiß, an wen es antworten soll. In einigen Situationen wird sich das nie ändern, also können Sie das fest codieren. Normalerweise ziehe ich es trotzdem vor, die FROM-Knotenadresse einzugeben, da Sie nie wissen, wie sich die Netzwerktopologie später ändern könnte.

Zum Schluss. Da Sie dies den "Hauptcomputer" nennen, gehe ich davon aus, dass Sie von einem echten PC sprechen. Bei echten PCs, auf denen ein modernes Betriebssystem wie Windows, OS/X oder Linux ausgeführt wird, werden Sie Latenzen haben, wie schnell die Anwendung auf diesem Computer reagieren kann ... Bauen Sie also entsprechend große Timeouts in Ihr Protokoll ein. Viele seriell-basierte Protokolle sind auf modernen PCs ein echtes Ärgernis, da bei Antworten usw. enge Zeitüberschreitungen zulässig sind. Sie könnten MODBUS wahrscheinlich nicht so durch einen modernen PC leiten, wie Sie es beispielsweise beschreiben ... zumindest nicht ohne entweder spezielle serielle Gerätetreiber oder das Timing zu verletzen (was manchmal für feste Lösungen in Ordnung ist) Bis der Hauptcomputer die Antwort vom Testcomputer las, sie an die Subsysteme sendete, die Antworten erhielt,

Es ist furchtbar schwierig, Modbus auf einem modernen PC so zu implementieren, dass alle Timeouts vollständig eingehalten werden. Aber Modbus ist wahrscheinlich der beste Ausgangspunkt als Referenz für die Dinge, über die man nachdenken sollte. Vor allem, weil es praxiserprobt ist, schon eine Weile existiert und auf zahlreichen Ebenen wirklich gut dokumentiert ist.