The Industrial Raspberry Pi Forum

Sorry, dass ich erst jetzt dazu komme zu schreiben. Ich bin am Node-Red Node für RevPi dran. Für den Anfang kann man sich mit einem Exec Node behelfen und piTest aufrufen.
Wichtig erscheint mir, dass wir immer auf das Prozessabbild zugreifen. Da Sven ja schon eine tolle Python Lib für den Zugriff auf das Prozessabbild geschrieben hat, bin ich gerade dabei, die einzubauen.
Derzeit erstelle ich Input- und ein Output-Node. Hier kann man dann über ein Dropdown auf die entsprechenden Werte zugreifen. Die Namen stellt Svens Library mir zur Verfügung.

Wenn jemand Lust hat, die Lib von Sven auf Node.JS zu portieren wäre das klasse. Bis dahin nutze ich die Python Lib.

Volker hatte ins Gespräch gebracht, dass das Node gleich mehrere Werte auslesen können sollte, da man sonst unter Umständen sehr viele Nodes braucht. Ich dachte hier eingangs an etwas wie das Switch Node, dass mehrere Ausgänge hat. Da ich keinen Weg gefunden habe, dort Label unterzubringen, macht das imho keinen Sinn. Ich sehe derzeit auch keine andere Möglichkeit, bin aber für Vorschläge offen.

Bei Bedarf stelle ich mein aktuelles quick and dirty Output Node zur verfügung. Das wertvollste daran ist fast das Icon. O_1 etc sind dabei im Dropdown hart codiert. Support für mehrere DIOs ist da aktuell nicht drin.
Das soll allerdings nicht ins GIT, weil das nicht die Grundlage für die RevPi Nodes wird.

Ingo wrote:......
Ich mache es auch nicht anders um einige Sachen zu realisieren wo mir die Physischen IOs fehlen.

Hallo Ingo,

schönen Dank für deine Antwort.

Über die Aufteilung des Schlaf- und Wachmodus in zwei Variable habe ich noch nicht nachgedacht.

Erst einmal eine Idee, die ich mal gedanklich durchspielen werde.

Den Ansatz mit einer Logik zu arbeiten hatte ich auch schon, aber irgendwie habe ich dafür kein passendes Node gefunden. Alle Nodes haben immer nur einen Eingang. Auch das Switch-Node scheint mir da nicht zu helfen.

Der von mir angedachte Weg über ein Script führt jedenfalls mit meinen Kenntissen nicht zum Ziel, dass habe ich bereits gelernt.

da du ja eh mit LC3 arbeitetest kannst du dort dein Programm anpassen

Was soll mir dieser Satz sagen? Irgendwie habe ich als Neuling damit ein Verständinsproblem, mit LC3 kann ich im Moment nicht wirklich etwas anfangen. Ich hoffe nur, ich stelle mich gerade nicht besonders blöd an.

Vielleicht könntest Du mir ein Beispieflow von Dir zur Verfügung stellen?

Dieter

Hallo Dieter,

die Programmiersoftware mit der du Arbeitest ist von LogiCals oder? das ist die LC3.

gruß
sorry hätte auch LogiCals schreiben können.

Hallo Ingo,

ich arbeite nicht mit LogiCals, deshalb konnte ich mit LC3 auch nichts anfangen.
Ganz am Anfang wollte ich damit die ersten Gehversuche machen, aber da ging mal gar nix. Volker konnte mir auch nicht weiterhelfen und der erf. Zukauf einer Lizenz haben mich davon abgehalten damit weiter zu machen.

Die Realisierung muss schon alleine durch ein Flow im NodeRed erfolgen. Und da hängt es im Moment.

Gruß Dieter

Hallo Dieter.

Ok ich dachte das du damit arbeiten tust da in deinem anderen Post eine Abbildung derer drinne gewesen ist.
Leider kann ich dir da dann nicht helfen da ich hier mit LC3 Arbeite. Phyton hatten wir mal in betracht gezogen sind aber wieder ab davon.

gruß
Ingo

Ich glaube, hier gehen jetzt eine Menge Dinge ziemlich durcheinander: Modbus Master, LC3, Node Red, Node.Js...
1)
Zunächst einmal hat Dieter von unserem Modbus Master gesprochen, der streng zyklisch arbeitet. Das hat mit LC3 absolut nix zu tun. LC3 kann zwar über das Prozessabbild auch auf die Werte des virtuellen Moduls "Modbus Master" zugreifen, aber das ändert absolut nichts daran, dass dieser immer zyklisch arbeitet - völlig unabhängig von den Zugriffen von LC3. Daher kann man mit LC3 und dem virtuellen Modul "Modbus Master" nicht die Probleme von Dieter lösen:
Er hat ein Modbus Register im Slave, dem er einen Wert sendet, um den Slave in den Schalfmodus zu versetzen. Danach darf der Master keinerlei Modbusbefehle mehr an diesen Slave senden, sonst wacht er sofort wieder auf. Es spielt keine Rolle, an welches Register er danach einen Befehl sendet, der Modbus Befehl vom Master wird zwangsläufig den Slave wieder aufwecken. Der Modbus Master wird aber gnadenlos weiter zumindest das Register beschreiben, mit dem Dieter seinen Slave in den Schlafmodus versetzt. Da ändern LC3 Variablen für unterschiedliche Status gar nichts daran.
2)
Node-Red ist nicht Node.Js! Node-Red ist ein Browser-basierter Editor für Datenflüsse, der über eine grafische Programmieroberfläche einfache Programmierung solcher Datenflüsse zulässt. Das Ergebnis ist eine JSON formatierte Datei, die zur Laufzeit vom Server in Java.Script im Framework Node.Js übersetzt wird. Node-Red ist Bestandteil unseres Jessie Images.
3)
In Node-Red gibt es die Möglichkeit, eigene oder im Internet zugängliche "Nodes" dem System hinzuzufügen. Solche Nodes programmiert man dann oder holt sie sich aus Bibliotheken. U.a. existiert nach meiner Information eine Modbus Biliothek, die eben NICHT zyklisch arbeite, sondern ganz im Sinne von Node-Red und seinen Datenflüssen Event-basiert Daten sendet oder abfragt.
4)
Es gibt weitere Alternativen zu dem Modbus-Master Modul im PiCtory:
Verwendung einer Python-Bibliothek und eigene Ansteuerung des Modbus-Protokolls: Dafür muss man schon relativ tief in der Materie stecken, um zum Erfolg zu kommen.
Verwendung von Modbus-Stacks anderer Applikationen(Procon Web, LC3, etc.): Dazu sind meist zusätzliche Lizenzen erforderlich oder es fehlt die Unterstützung der entsprechenden Schnittstellen beim RevPi.

Ich empfehle daher einfach erst mal den Weg, den Modbus Node von Node Red auszuprobieren. Ansonsten halt warten, bis wir bei usnerem Master-Modul auch Einzeltelegramme unterstützen.

Wer Node-Red nutzen möchte, sollte zuerst die vorinstallierte Version auf den aktuellen Stand bringen.
Anschließend Node-Red mit dem Browser über http://IP-VOM-REVPI:1880 aufrufen.
Danach Nodes für Modbus oder was immer man braucht hier nachinstallieren:



Schlagworte: Update, Upgrade, Aktualisieren, Node-Red, Nodered, Node Red, NPM, LTE

volker wrote:hi Joey,
Das Thema Node red ist eines, welches wir im 4. Quartal sehr gezielt angehen wollen. Aktuell haben wir von KUNBUS aus keinerlei Nodes für den IO Zugriff gebaut. ich weiß aber, dass sich einige aus der Community damit befasst haben. daher hoffe ich, dass dir hier vielleicht jemand schnell weiterhelfen kann.
Viel Erfolg,
Volker.

Wenn jemand brauch es:
Es war siemlicht leicht.

Ein timestamp-inject (cyclic, für cyclic Lessung )
---> ein file Buffer read (/dev/piControl0)
---> eine Function die gibt der spezifische Byte/Word/Bit von der 4096 Bytes Buffer
z.b.S: msg.payload = msg.payload[13]+msg.payload[14]*256;
hier lesse ich InputValue_2 von die Analogue Module (Addresse 13)

Ich weiß, das die Function einfacher sein kann, vielleicht es kann direkt der Datei lessen

Das würde meine "Lössung" für 4 analogue Eingäng sein

Alles super! Aber wenn wir das dann mal angehen wollen wir das schon mehr allgemein lösen. Vielleicht über ein virtuelles device in PiCtory in Kombination mit einem configuration node. Das Ziel ist jedenfalls klar: Es müssen alle Prozesswerte ohne Offsets usw. per Namen in Node-Red zur Verfügung stehen. Und das möglichts ohne Eingriff nach eine Re-Konfiguration genauso wie vorher. Node-Red ist ja gerade NICHT für Programmierer geschrieben (dann könnte man die Datne auch in Python oder C weiterreichen und zwischenbearbeiten), sondern für Menschen, die mit Drag & Drop Datenflüsse konfigurieren wollen. Und das genau ist unser Ziel bei einer Node-Red Anbindung. In einer Woche wird es bei uns eine wichtige Entscheidung geben, von der abhängt, wie schnell wir das angehen können.