ich habe ein kleines Modbus RTU Terminal geschrieben.
Es hat gerade mal um die 540 kByte mit grafischer Oberfläche als ausführbare Datei ohne Installation.
Da ich kein einfaches sauber funktionierendes Terminal hierfür gefunden
habe, habe ich selbst eines erstellt. Es ist komplett kostenlos.
Vielleicht ist es auch für andere hilfreich.
Das Terminal unterstützt Read Holding und Input Register FC03/FC04 und Write Single und Multiple Register FC06/FC16.
Über Feedback bin ich dankbar.
Gerne erweitere ich das Terminal, oder behebe Fehler.
Es ist selbstverständlich frei von Viren, Malware, etc..
Dass fälschlicherweise Schadsoftware erkannt wurde.
Ich habe ja den Sourcecode vor mir liegen und mein System ist frei von Schadsoftware. Würde mich sehr wundern, wenn da was infiziert wäre. :)
Kommt die Meldung von Windows selbst?
Über virustotal.com kannst du prüfen, welcher Virenscanner darauf anschlägt.
Das sind 4 Stück von geschätzt 100 Virenscanner, darunter Microsoft. Wobei ich bei mir keine Meldung bekomme.
Es ist komplett kostenlos.
Vielleicht ist es auch für andere hilfreich.
Das sind halt 30-Tage-Testversionen, aber auch nicht ganz so teuer, wenn man sie kauft. (über 150$ / Lizenz macht sich eine Firma normalerweise keinen Kopf; und wozu braucht ein Privatmensch schon Modbus? Die zigte Wechselrichter Anzeige / Steuerung?).
hast du das zufällig in Delphi (Embarcadero) geschrieben?
dann ist es klar ein false positiv.
wir verwenden 20 Jahre alte Tools, und seit einigen Jahren jammert das scheiß Windows dass die Software unzuverlässig ist.
Auffällig ist es nur bei Tools die auf die serielle Schnittstelle zugreifen.
Es ist komplett kostenlos.
Vielleicht ist es auch für andere hilfreich.
Das sind halt 30-Tage-Testversionen, aber auch nicht ganz so teuer, wenn
man sie kauft. (über 150$ / Lizenz macht sich eine Firma normalerweise
keinen Kopf; und wozu braucht ein Privatmensch schon Modbus? Die zigte
Wechselrichter Anzeige / Steuerung?).
Ein Privatmensch braucht Modbus z.B. um einen Stromzähler auszulesen, oder die Wärmepumpe anzusteuern, oder mit dem Wechselrichter zu kommunizieren.
Oder mit der Wallbox, die in die Haus Automatisierung eingebunden werden kann, etc..
Alle anderen treiben sich in diesem Forum ja nicht herum. :)
hast du das zufällig in Delphi (Embarcadero) geschrieben?
dann ist es klar ein false positiv.
wir verwenden 20 Jahre alte Tools, und seit einigen Jahren jammert das
scheiß Windows dass die Software unzuverlässig ist.
Auffällig ist es nur bei Tools die auf die serielle Schnittstelle
zugreifen.
Nein, das Terminal wurde in Pure Basic geschrieben. Scheint aber das gleiche Problem zu haben ...
... und wozu braucht ein Privatmensch schon Modbus?
Neuerdings gibt es einen Trend zu Smart Home ;-)
Dies findet gerade im Bereich von Privatmenschen statt und beinhaltet recht häufig Geräte die mit Modbus RTU kommunizieren.
Dabei geht es meist eher selten um die Anzeige, sondern meist im Einbindung ins Gesamtsystem (messwertabhängige Steuerung, Datenaufzeichnung).
Übersehen?
Neuerdings gibt es einen Trend zu Smart Home ;-)
Übersehen?
Tremds werden von mir ignoriert.
Das klingt nämlich wie die Typen, die ihren CAN-Bus im Auto unbedingt auslesen wollen (, dann den Fehlerspeicher löschen und sich wundern, warum sie im Graben landen).
Eine sinnvolle Anwendung für den Modbus habe ich (bis jetzt noch) nicht zuhause.
Danke für die Links! Kenne tatsächlich beide, da ich diese ursprünglich auch genutzt bzw. getestet habe.
QModbus konnte auf meinem Rechner plötzlich nicht mehr gestartet werden und ist des Öfteren abgestürzt. War aber gut zu bedienen und hat mir gut gefallen.
Mit QModMaster hatte ich auch irgendwelche Probleme, weiß aber nicht mehr was das war. Habe ich dann nicht weiter genutzt.
Auf jeden Fall sind diese beiden Programme umfangreicher in den Funktionen und decken mit Sicherheit mehr ab, falls benötigt.
Bevor ich meine Bude mit Modbus-Verkabelung vollpröle, lege ich mir
lieber Ethernet (mit POE).
Modbus TCP läuft üblicherweise per Ethernet. Nur Modbus RTU und Modbus ASCII benötigen eine EIA-485/422/232. Und natürlich gibt es entsprechende Umsetzer in beiden Richtungen.
Modbus TCP läuft üblicherweise per Ethernet. Nur Modbus RTU und Modbus
ASCII benötigen eine EIA-485/422/232. Und natürlich gibt es
entsprechende Umsetzer in beiden Richtungen.
Bevor ich meine Bude mit Modbus-Verkabelung vollpröle, lege ich mir
lieber Ethernet (mit POE).
Du weißt schon, dass RS-485 (für ModBus RTU) im Smart Home Bereich eher nicht die Hauptverkabelung ist?
Modbus gibt es übrigens nicht als spezielle Verkabelung. Modbus TCP, um das es hier nicht geht, läuft über Ethernet.
Vielleicht hast du da etwas mit KNX verwechselt?
Du weißt schon, dass RS-485 (für ModBus RTU) im Smart Home Bereich eher
nicht die Hauptverkabelung ist?
Ach?
Modbus gibt es übrigens nicht als spezielle Verkabelung. Modbus TCP, um
das es hier nicht geht, läuft über Ethernet.
Vielleicht hast du da etwas mit KNX verwechselt?
Vielleicht kenne ich mich auch so mit dem Kram aus?!
Ich hatte zufällig auch eine (kommerzielle) Alternative zum (nicht einfach so lauffähigen) Programm genannt. Man möchte sich aber lieber über einen Nebensatz aufregen.
Wenn man schon mit Modbus "rumspielt", braucht man auch das Wissen, wie die Datenstruktur "hinter" der Schnittstelle aussieht.
Wenn man die nicht kennt, ist der Modbus zum Verreiben.
Ja, natürlich gibt es inzwischen Informationen dazu.
Vor 30 Jahren hat mein Vater schon jeden Morgen die Verbrauchswerte für Gas, Wasser und Strom aufgeschrieben - wir haben die Zettel dann mangels Interesse ungelesen entsorgt...
Bevor ich meine Bude mit Modbus-Verkabelung vollpröle, lege ich mir
lieber Ethernet (mit POE).
Rainer W. schrieb:
Du weißt schon, dass RS-485 (für ModBus RTU) im Smart Home Bereich eher
nicht die Hauptverkabelung ist?
Ach?
Wegen eines Modbus-Interfaces wird sich wohl keiner die Bude mit Modbus-Verkabelung vollprölen - welche Verlegeart auch immer du mit dieser Wortschöpfung beschreiben magst.
welche Verlegeart auch immer du mit
dieser Wortschöpfung beschreiben magst.
"Pröl" oder "Pröhl" (die genaue Schreibweise ist mir gerade entfallen) sind überflüssige Dinge.
Das Programm oben unterstützt doch nur Modbus RTU. Ergo ist da erst wieder ein Umsetzer auf Ethernet nötig. Dann wäre ein Ethernet-Interface per Software doch sinnvoller, da es entsprechendes (mit dem gleichen oder sogar größeren Funktionsumfang) schon gibt.
welche Verlegeart auch immer du mit
dieser Wortschöpfung beschreiben magst.
"Pröl" oder "Pröhl" (die genaue Schreibweise ist mir gerade entfallen)
sind überflüssige Dinge.
Das Programm oben unterstützt doch nur Modbus RTU. Ergo ist da erst
wieder ein Umsetzer auf Ethernet nötig. Dann wäre ein Ethernet-Interface
per Software doch sinnvoller, da es entsprechendes (mit dem gleichen
oder sogar größeren Funktionsumfang) schon gibt.
RTU nutzt z.B. ein Energiemeter oder andere Geräte, die keinen Ethernet Anschluss oder WLAN haben.
Modbus TCP füge ich aber noch hinzu. Benötige ich z.B. für Wechselrichter, die nicht über RTU angeschlossen sind.
Ja, es gibt bessere Programme mit größerem Funktionsumfang, aber ich wollte es so einfach wie möglich halten. Es soll ein kleines kostenloses Programm bleiben und einfach zu bedienen sein, mit den Funktionen, die am häufigsten benötigt werden.
Mein Gedanke war lediglich etwas Feedback zu bekommen, was man besser machen bzw. ergänzen kann.
Streitet euch nicht, jeder macht es so, wie er will und nutzt die Programme, die ihm am besten liegen, ob kostenlos oder kostenpflichtig.
Was hat das alles mit Modbus TCP zu tun? Es war ja von RTU die Rede.
Ich finds auch sicherer z.B. wenn die Wärmepumpe über Modbus RTU mit dem Wechselrichter redet als mit was auch immer für Protokolle über WLAN oder Ethernet. Da is man immun gegen Störungen der IP-Infrastruktur (router, internet etc...).
Verkabeln tut man das natürlich mit CAT5 oder besser. Hat den Vorteil dass man "hin"- und "retour" Paar hat und noch 2 Paare um die Gegenstelle mit Strom zu Versorgen.
pymodbus wär auch noch zu erwähnen, hat zwar kein GUI, aber ein CLI interface.
Ich finds auch sicherer z.B. wenn die Wärmepumpe über Modbus RTU mit dem
Wechselrichter redet
Das Programm interessiert doch gar nicht. wenn die Geräte direkt miteinandere verbunden sind.
Dazu bräuchte man nur einen (reinen) Listener, um auf dem Bus mitzuhören.
Was hat das alles mit Modbus TCP zu tun? Es war ja von RTU die Rede.
Nö. Es geht um ein Programm mit dem man auf einem RTU-Moodbus
kommunizieren kann.
Das ging auch schon vorher mit anderen Programmen.
sag ich ja dass von RTU die Rede war und nicht von TCP. Und klar gibts für ein Protokoll das seit den 70ern bis jetzt "lebt" unzählige Programme die dieses Protokoll sprechen. Hab selber ein paar Links dazu gepostet.
Neben dem bereits hinzugefügten Modbus TCP Protokolls, kam heute noch ein serielles Terminal hinzu, mit der Zwischenspeicherung der eingegebenen Befehle und Abruf dieser Befehle über die Pfeiltasten.
Da ich noch einige Mikrocontroller Projekte habe, die über UART kommunizieren bzw. parametriert werden können, ist das ganz praktisch nur ein Tool zu haben.
Ich habe noch viele Ideen für das Terminal, die noch ganz nützlich sein werden.
Das war eher eine rhetorische Frage.
Wenn das, wovon ich rede bzw. in meinem Terminal nutze, kein Modbus TCP ist, sondern irgendwas mit RTU über TCP Connection, dann hätte ich schon gerne gewusst, was Modbus TCP wirklich ist. :)
MODBUS over serial line specification and implementation guide V1.02 vom 20.12.2006 (44 Seiten)
MODBUS Messaging on TCP/IP Implementation Guide V1.0b vom 24.10.2006 (46 Seiten)
im Anhang.
Irgenwie muss man ja da drauf schauen können wenns irgendwo hakt. Oder
Parameter setzen.
Ihr bastelt Euch echt solche Hausinstallationen selber zusammen?
Das erinnert mich an das, was ich schon wegen der CANBus-Geschichte im Auto schrieb...
Irgenwie muss man ja da drauf schauen können wenns irgendwo hakt. Oder
Parameter setzen.
Ihr bastelt Euch echt solche Hausinstallationen selber zusammen?
Das erinnert mich an das, was ich schon wegen der CANBus-Geschichte im
Auto schrieb...
Wie bindest du z.B. eine Wallbox mit Modbus Schnittstelle in deine Hausautomation ein, wenn du z.B. Überschussladen machen willst?
Viele Hersteller hatten früher keine Wallbox im Programm, die zu dem bereits bestehenden System gepasst hätten.
So lese ich z.B. eine Wallbox / EVSE per Modbus mit ESP32 aus und kann übers WLAN auf die ESP32 Weboberfläche oder über MQTT direkt auf die Ladedaten und Konfigurationsschnittstelle zugreifen.
Es gibt unzählige Anwendungsfälle.
Was soll da schief gehen? Im schlimmsten Fall zieht das Fzg. die Energie aus dem Netz, statt vom Dach. Oder die Anzeige zeigt dir Müll an.
Und gerade dafür hat man Tools, wie solch ein Terminal, mit dem die Daten angezeigt bzw. überprüft werden können. Auch kann man so Geräte konfigurieren, was man ansonsten gar nicht machen könnte.
Oder man hat so viel Kohle, dass man sich das alles machen lässt. Aber selbst da gibt es Grenzen, denn nicht jeder Elektriker kann das umsetzen, was man möchte. :)
Viele Hersteller hatten früher keine Wallbox im Programm
Wieder ein Grund, warum ich nicht jeden neuen Trend mitmache.
Ich bin kein alpha- oder beta-Tester.
Hausautomation gibt es doch schon ewig. Home Assistant oder Node Red gibt es doch auch schon zig Jahre. Was dafür da ist, seine Hausautomation einfach selbst aufzubauen, wofür man die Modbus Terminals zur Unterstützung benötigt.
Alternativ gibt es Fertigprodukte für teures Geld, auch schon seit vielen Jahren.
Über die Beta Phase sind wir doch schon längst hinaus.
Ich brauche es heutzutage zwingend, ja, denn damit regle ich meine Heizstäbe, um den Überschuss aus der PV für die Warmwasseraufbereitung bzw. zur Unterstützung der Zentralheizung verwenden zu können. Das Gleiche gilt für die Wallboxen zum Überschussladen.
Ich kann auch gezielt meine Pelletsheizung automatisch herunterfahren bzw. abregeln, wenn im Winter die Sonne scheint.
Das alles lasse ich mir über eine Weboberfläche gesammelt anzeigen. So auch der Akkustand des Hausspeichers. So weiß ich immer, ob es Sinn macht, das Elektroauto zwischendurch zum Laden anzustecken.
Ich nutze so tatsächlich mehrere tausend KWh im Jahr an Energie, die ich ansonsten ins Netz einspeisen und wieder teuer beziehen müsste.
Um Energie zu sparen ist eine vernünftige Hausautomation aus meiner Sicht also unumgänglich
Man kann auch den ganzen Tag aus dem Fenster schauen und einen Schalter umlegen, wenn die Sonne zwischen den Wolken hervorkommen sieht, aber dafür habe ich leider keine Zeit. :)
Nur zum Verständnis, ich steuere damit nicht meine Rollläden, oder überwache nicht meine Fenster, ob offen oder geschlossen. Auch steuere ich nicht meine Beleuchtung, da ich der Meinung bin, dass man das nicht unbedingt braucht.
Wobei das Steuern der Rollläden auch einen Beitrag zur Energieeinsparung leisten kann.
Ich brauche es heutzutage zwingend, ja, denn damit regle ich meine
Heizstäbe, um den Überschuss aus der PV für die Warmwasseraufbereitung
bzw. zur Unterstützung der Zentralheizung verwenden zu können. Das
Gleiche gilt für die Wallboxen zum Überschussladen.
Ich kann auch gezielt meine Pelletsheizung automatisch herunterfahren
bzw. abregeln, wenn im Winter die Sonne scheint.
Das alles lasse ich mir über eine Weboberfläche gesammelt anzeigen. So
auch der Akkustand des Hausspeichers. So weiß ich immer, ob es Sinn
macht, das Elektroauto zwischendurch zum Laden anzustecken.
Kann aber, wenn sinnvoll gemacht, auch einiges weniger ausgegebenes Geld bedeuten.
Gut, manche hier lassen sich noch von Mama oder Papa durchfüttern, die wissen dann vielleicht noch nicht, was es bedeutete, mit Geld umgehen zu müssen.
Ich brauche es heutzutage zwingend, ja, denn damit regle ich meine
Heizstäbe, um den Überschuss aus der PV für die Warmwasseraufbereitung
bzw. zur Unterstützung der Zentralheizung verwenden zu können. Das
Gleiche gilt für die Wallboxen zum Überschussladen.
Also "man" braucht es nicht zwingend. ;)
Unsere Gas-Heizung ist von 2021, mein Auto ist von 2019 und das meiner Frau von 2014. Sollte irgendwas davon (in der aufgezählten Reihefolge) irreparabel kaputtgehen, können wir ja mal über eine "Hausautomation" nachdenken.
Deinen Aufbau würde ich nicht als eine Standard-Hausautomation, sondern eher als "Energiespar- und verteilungsautomation" bezeichnen.
Braucht niemand. Häuser gibt es völlig unautomatisiert seit über 2000 Jahren.
Wieder ein Grund, warum ich nicht jeden neuen Trend mitmache.
Ich bin kein alpha- oder beta-Tester.
Kein Mensch braucht sich in seiner Freizeit mit Elektronik oder SW-Entwicklung befassen. Das kann man alles fertig kaufen oder sich von Profis installieren lassen.
Andere bei der Ausübung ihrer Hobbies zu beobachten ist für viele befremdlich, nicht nur für Dich. Da ist vieles nicht nachvollziehbar. Warum klettert jemand auf einen Berg, statt mit dem Hubschrauber hochzufliegen? Und warum setzen sich Leute stundenlang an einen Fluss und halten die Angel ins Wasser, statt den Fisch einfach bei Real zu kaufen?
Man kann übrigens viel Lebenszeit sparen, wenn man die Foren meidet, in denen andere Leute ihren Hobbies nachgehen.
"Pröll" im Sinne von Gerümpel hat nichts mit "Proll" im Sinne von Mensch ohne Umgangsformen gemeinsam. "Proll / Prolo" stammt tatsächlich im Wortstamm von "Prolet" (Arbeiterklasse) ab, hat aber seine Bedeutung deutlich geändert.
Das Ö könnte einfach die Tätigkeit "herumproleten" beschreiben.
Aber es ging um Hausautomation. Die besteht bei mir praktisch nur aus der Heizungssteuerung. Nachdem ich vor Jahren die kalten Lötstellen nachgelötet habe erledigt sie bisher unauffällig ihren Dienst, mehr erwarte ich nicht.
Gasheizung, Bj.1998, irgendwann muss eine Wärmepumpe her, dazu muss erst mal der Stromzähler ausgetauscht werden für die höhere Leistung, davor habe ich mich bisher gedrückt.
Der Stromzähler hat seit dem letzten Update eine optische Schnittstelle, hab es mir angeschaut, aber kein Bedüfnis verspürt, mich damit zu befassen. Davon wird meine Stromrechnung nicht kleiner.
...
Gasheizung, Bj.1998, irgendwann muss eine Wärmepumpe her, dazu muss erst
mal der Stromzähler ausgetauscht werden für die höhere Leistung, davor
habe ich mich bisher gedrückt.
Der Stromzähler hat seit dem letzten Update eine optische Schnittstelle,
hab es mir angeschaut, aber kein Bedüfnis verspürt, mich damit zu
befassen. Davon wird meine Stromrechnung nicht kleiner.
Macht aus meiner Sicht auch wirklich nur dann Sinn, wenn man Energie damit einsparen kann, durch Interaktion zwischen Verbrauchern und Energieerzeugung. Also z.B. mit einer PV Anlage.
Für eine Gas Zentralheizung fällt mir jetzt nicht viel ein.
Da kann man an der Warmwasser Erzeugung und Heizkreisläufen durch Ansteuerung von Pumpen etwas erreichen, aber dazu reicht eine einfache Steuerung direkt an der Heizung.
Um ein paar Lichter oder die Gartenbewässerung einzuschalten, braucht es heutzutage nicht wirklich eine Hausautomation, wenn man nicht gerade eine 1000 m² Villa sein Eigen nennt und noch einen Swimmingpool irgendwo auf dem 3000 m² Gelände hat, dessen Wasserqualität, Wassertemperatur und Wasseraufbereitungsanlage überwacht werden muss.
Und für alles andere gibt es sowieso heutzutage für fast jedes Gerät eine App, die sich damit weltweit verbindet. Was während der Urlaubszeit sehr nützlich sein kann.
Lässt sich aber auch über einen VPN auf den eigenen Server erledigen,
wenn man Hausautomation hat. :)
Wenn's schee macht?!
Für die Energie, die du mit deiner Hausautomation sparst, betreibst du dann also einen Server? ;)
Und alles nur, um Modbus zu verwenden?
Ja, ich habe auch ein paar Raspberry Pis laufen...
Lässt sich aber auch über einen VPN auf den eigenen Server erledigen,
wenn man Hausautomation hat. :)
Wenn's schee macht?!
Für die Energie, die du mit deiner Hausautomation sparst, betreibst du
dann also einen Server? ;)
Und alles nur, um Modbus zu verwenden?
Ja, ich habe auch ein paar Raspberry Pis laufen...
Genau, ich habe lediglich einen einzigen Raspberry Pi als Server mit Node Red drauf.
Alles andere mache ich über Modbus TCP und MQTT.
MQTT sende ich über ESP32, die an den jeweiligen Verbrauchern hängen und diese regeln oder auslesen.
Die ESP8266 und ESP32 selbst sind kleine Server mit Weboberfläche, die im WLAN hängen, so dass ich alle Verbraucher, z.B. Wallbox, darüber direkt konfigurieren kann, aber auch MQTT für diesen Verbraucher konfigurieren kann, was z.B. mit welchem Topic zyklisch verschickt oder empfangen werden soll.
Das ist alles universal aufgebaut, so dass ich praktisch jeden Verbraucher mit irgendeiner Schnittstelle über MQTT in die Hausautomation einbinden kann.
Das ist auch der Grund, warum ich ein eigenes Terminal erstellt habe, da ich das nach meinen Bedürfnissen anpassen kann.
Ein paar kleine Recherchen zu "Pröll" ergaben, dass der Nachname wohl in Österreich (1:6461) und Deutschland (1:46082) halbwegs verbreitet ist. Zudem wird "Pröll" als kölnische Schreibweise von "Prüll" genannt.
"Prüll" leitet sich sprachlich wiederum von "Plunder" ab. Außerdem kennt der Duden diesen Begriff ebenfalls mit der Bedeutung "wertloses Zeug, Plunder". "Plunder" stammt aus dem Mittelhochdeutschen und besaß der eine ähnliche Bedeutung, ist aber auch mit "plündern" in Sinne von "Waren mit Gewalt nehmen" verbunden.
Der Begriff "Prolet" leitet sich wiederum von "Proletarier" und vom lateinischen "proletarius" ab und bedeutete ursprünglich "der nichts als Nachkommen (proles) Hervorbringende". Ob es da wirklich einen sprachlichen Zusammenhang mit "Plunder" gibt, wage ich aber zu bezweifeln.
Der Begriff "Prolet" leitet sich wiederum von "Proletarier" und vom
lateinischen "proletarius" ab und bedeutete ursprünglich "der nichts als
Nachkommen (proles) Hervorbringende".
Wie handhabst Du den Fall, dass weniger als 4.1kW Überschuss da ist?
Komplette Abschaltung, oder wechselst Du dann auf einphasiges Laden?
Ich schalte nicht auf einphasiges Laden um, da ich ja einen Speicher habe. Ich lade dann dreiphasig mit 6A weiter. Da der Speicher ja praktisch voll ist, wenn ich Überschussladen mache. Bei einem bestimmten SOC schalte ich dann aus, vorausgesetzt ich habe kein Prioladen eingestellt.
ich habe ein kleines Modbus RTU Terminal geschrieben.
Es hat gerade mal um die 540 kByte mit grafischer Oberfläche als
ausführbare Datei ohne Installation.
Da ich kein einfaches sauber funktionierendes Terminal hierfür gefunden
habe, habe ich selbst eines erstellt. Es ist komplett kostenlos.
Vielleicht ist es auch für andere hilfreich.
Danke Roland für das Teilen deiner Arbeit. Ich habe mir vor ein paar Monaten nach so etwas einen Wolf gesucht um Chinesische BLDC-Controller zu parametrieren. (Die ich anschließend in die Tonne für demnächst zum Wertstoffhof gekloppt habe. Wer billig kauft...)
Wegen der merkwürdigen Posts in diesem Thread, Modbus RTU ist nicht für Hausautomation gemacht sondern es ist ein steinaltes, einfaches, genormtes und freies, Protokoll für die Vernetzung von SPSen, Sensoren und Aktoren.
Es lässt sich überall wo ein Controller mit UART werkelt durch Anlöten eines popeligen RS485-Bausteins und einigen Zeilen Software implementieren. Deswegen, und weil es einfach funktioniert, lebt es immer noch, hauptsächlich in der industrieellen Steuerungstechnik.
Roland, wo du grade dabei bist, die Welt braucht unbedingt ein ähnlich einfaches und kleines Terminalprogramm welches die emfangenen Daten von 2 seriellen Schnittstellen (z.B. RS232) in einem Fenster darstellen kann. Anwendung beispielsweise zum debuggen der Kommunikation zwischen einem Controller und einem Mobilfunkmodem... ;-)
danke für deinen Input, habe ich leider jetzt erst gelesen.
Das mit den zwei Port in einem Terminalfenster sollte kein Problem sein und ist eine sehr gute Idee. Es braucht dann auch zwei Eingabefelder für das Senden der Nachrichten, bzw. zumindest eine Auswahl des Ports.
Das mit den zwei Port in einem Terminalfenster sollte kein Problem sein
Denk mal drüber nach, wie Du sicherstellst, daß die Zeichen auch wirklich /synchron/ von den beiden seriellen Schnittstellen abgeholt werden.
Denn Ziel ist ja wohl, zeitliche Zusammenhänge darzustellen, wie sie in seriellen Protokollen üblich sind - Gerät X sendet etwas, Gerät Y antwortet darauf. Und das kann mit sehr kurzen Reaktionszeiten und auch sehr wenigen übertragenen Daten einhergehen.
Insbesondere, wenn die UARTs einen Empfangspuffer haben, in dem sie mehrere eintreffende Daten sammeln, bevor sie an höhere Treiberschichten weitergeleitet werden.
Unter DOS habe ich vor Jahrzehnten mal ein entsprechendes Programm geschrieben, und dafür halt zwei Interrupthandller gebaut, die in den gleichen Empfangsfifo geschrieben haben (mit einer Markierung, welcher Kanal die Daten geliefert hatte). Das funktionierte, setzte allerdings voraus, daß die 16550 im 8250-Modus betrieben wird (um den störenden Hardwarefifo loszuwerden).
Das Verfahren würde man heute noch um einen Zeitstempel erweitern.
Unter Windows und mit herkömmlichen USB-Seriell-Bridges ist all' das praktisch ausgeschlossen.
Da muss man sich eigene Hardware bauen - einen µC mit zwei Hardware-UARTs und USB-Device-Port, der ausreichend viel Pufferspeicher für empfangene Daten hat (pro Nutzbyte kommen noch Kanalkennung und Zeitstempel dazu), um das dann geordnet und verlustfrei via USB zum Auswerteprogramm zu übertragen.
Das mit den zwei Port in einem Terminalfenster sollte kein Problem sein
Denk mal drüber nach, wie Du sicherstellst, daß die Zeichen auch
wirklich /synchron/ von den beiden seriellen Schnittstellen abgeholt
werden.
In der Tat, das dürfte unter Windows schwierig bis unmöglich werden, habe ich bei meinem Wunsch nach einem solchen Feature nicht bedacht.
Denn Ziel ist ja wohl, zeitliche Zusammenhänge darzustellen, wie sie in
seriellen Protokollen üblich sind
Ja, genau das.
Unter DOS habe ich vor Jahrzehnten mal ein entsprechendes Programm
geschrieben, und dafür halt zwei Interrupthandller gebaut, [...]
Nicht umsonst findet man auch heute noch Maschinensteuerungen die unter DOS laufen.
Da muss man sich eigene Hardware bauen - einen µC mit zwei
Hardware-UARTs und USB-Device-Port, der ausreichend viel Pufferspeicher
für empfangene Daten hat
Denn Ziel ist ja wohl, zeitliche Zusammenhänge darzustellen, wie sie in
seriellen Protokollen üblich sind - Gerät X sendet etwas, Gerät Y
antwortet darauf.
...
Insbesondere, wenn die UARTs einen Empfangspuffer haben, in dem sie
mehrere eintreffende Daten sammeln, bevor sie an höhere Treiberschichten
weitergeleitet werden.
Falls einen solche Details interessieren, gibt es Logikanalysatoren mit Dekoder für einen Appel und ein Ei, ganz ohne Puffer und zusätzliche Zeitstempel - einfach die Rohdaten von beiden Schnittstellen synchron mitschneiden, was auch immer "beide Schnittstellen" bei RS-485 bedeutet. Ohne Zugriff auf die Treiberfreigabe der Busteilnehmer wird auch ein LA bei der Zuordnung Mühe haben ;-)
Falls einen solche Details interessieren, gibt es Logikanalysatoren mit
Dekoder für einen Appel und ein Ei, ganz ohne Puffer und zusätzliche
Zeitstempel - einfach die Rohdaten von beiden Schnittstellen synchron
mitschneiden,
Produziert halt irrwitzig viel Daten. Kann man sowas ein paar Stunden mitlaufen lassen?
Ohne Zugriff auf die Treiberfreigabe der Busteilnehmer wird auch ein LA
bei der Zuordnung Mühe haben
Das ist in der Tat ein Problem, wobei das durch Einschleifen des Analysators in die Signalleitung gelöst werden kann. Der muss dann halt sicherstellen, daß er auf beiden Seiten die selbst empfangenen Daten möglichst verzögerungsfrei weiterreicht.
Mit 'ner simplen UART kann man das knicken, der von mir weiter oben verlinkte Analysator nutzt dafür etwas aufwendigere Logik. Das wird allerdings auch mit den von dem Ding unterstützten Datenraten (bis 20 MBit/sec) liegen.
Man hat sich schon Gedanken gemacht, diese Menge im Rahmen zu halten.
Bei einem Logikanalysator?
Ja, natürlich! Darum geht es doch!
Bei welchem,
Bei diesem Saleae-Ding z.B.
und wie?
Steht nicht drauf.
Aber ich habe festgestellt, dass der Speicherbedarf vom Umfang der Aktivität an den Probes abhängig ist und kaum von der eingestellten Abtastrate.
Ich nehme an, dass die Anzahl der Samples zur nächsten Flanke gezählt/notiert werden.
Das ist in vielerlei Hinsicht auch einfacher, als viele einzelne Bits zu verwalten.
Das mit den zwei Port in einem Terminalfenster sollte kein Problem sein
und ist eine sehr gute Idee. Es braucht dann auch zwei Eingabefelder für
das Senden der Nachrichten, bzw. zumindest eine Auswahl des Ports.
Überflüssig, wenn man einen Halbduplex-Bus (RS485) verwendet, wie er bei Modbus-RTU üblich ist.
Zum Abhören einer Vollduplex-Kommunikation ist es natürlich sinnvoll, aber dann braucht man immer noch keine zwei Eingabefelder für Befehle, da man doch eh nur horcht / belauscht.
Aber ich lasse mich gerne eines Besseren belehren.
Überflüssig, wenn man einen Halbduplex-Bus (RS485) verwendet, wie er bei
Modbus-RTU üblich ist.
Es gibt auch einige Hersteller, die Modbus-Komponenten mit EIA422 statt 485 anbieten. In diesem Fall wäre es schon praktisch, zwei Schnittstellen mitschneiden zu können.
Das, was ein ordentlicher Monitor auch noch darstellen sollte, wären die Pausenzeiten zwischen mehreren Paketen und ggf. auch eine Indikation, wenn z.B. durch ein Gerät T35 unterschritten worden sein sollte. So etwas hatte uns mal eine mehrere Tage lange Fehlersuche eingebracht. Gerät A antwortete manchmal zu schnell, woraufhin einige (nicht alle!) Geräte des Typs B plötzlich eine Busstörung diagnostizierten. Danach waren sie solange nicht normal ansprechbar, bis das Fehlerregister ausgelesen und der Fehler quittiert wurde.
Es gibt auch einige Hersteller, die Modbus-Komponenten mit EIA422 statt
485 anbieten. In diesem Fall wäre es schon praktisch, zwei
Schnittstellen mitschneiden zu können.
Das hatte ich im zweiten Absatz auch geschrieben...
Dann bräuchte man trotzdem nur eine Eingabemöglichkeit zum Senden von Anfragen.
Das ist wahr. Aber machmal möchte man dem Slave etwas mitteilen.
Die Eingabe an den Host müsste ja vom Slave kommen, wenn man eine weitere Eingabezeile haben will.
Die Eingabe an den Host müsste ja vom Slave kommen, wenn man eine
weitere Eingabezeile haben will.
Und wie hinderst Du bei so einem Konstrukt die beteiligten Geräte daran, just in dem Moment selbst etwas zu senden, wenn Du mit einem Deiner Eingabefelder etwas beitragen willst?
Damit wirst Du bestenfalls die Fehlerkorrekturfähigkeiten der Protokollimplementierung ausprobieren können.
Und wie hinderst Du bei so einem Konstrukt die beteiligten Geräte daran,
just in dem Moment selbst etwas zu senden, wenn Du mit einem Deiner
Eingabefelder etwas beitragen willst?
Das würde natürlich bedeuten, dass es kein reiner Listener ist.
Das Terminalprogramm müsste natürlich für die Einhaltung des Prokolls sorgen.
Zwei Ausgabefenster wwären ja auch nur bei getrennten Schnittstellen oder einer Richtungserkennung aufgrund des Protokolls möglich.
Wenn man nur auf einem (Mod)-Bus horcht, reicht eins.
Vielleicht reden wir auch aneinander vorbei:
Für eine Modbuskonstruktion braucht man nur ein Eingabefenster, wenn man Host (für mehrer Slaves) spielt.
Ein zweites ist da mMn überflüssig.
Hallo,
ich bin gerade auch auf der Suche nach einem Modbus Monitor und auf diesen Thread gestoßen. Mit fällt auf, dass jeder Beitrag - absolut jeder - mit Lesenswert: -1 gekennzeichnet ist.
Gibt es da eine globale Einstellung?
Mal warten, wie mein Beitrag eingestuft wird...
J.
Einfach ignorieren. Diese Funktion der Forensoftware ist bekanntermaßen vollkommen sinnlos, aber Lebensinhalt einiger Personen hier, die was-auch-immer dort hineininterpretieren wollen, und auch an den Zahlen meinen erkennen zu können, /wer/ da draufgeklickt hat.
Einfach ignorieren.
Leider hat Andreas, der Betreiber dieses Forums und einzige Mensch, der die Forensoftware wartet/weiterentwickelt, in den letzten Jahren etwas an Elan verloren.
Modbus_RTU_Terminal.png
(57 KB)
