| | |  | Gut zu wissen: Hilfreiche Tipps und Tricks aus der Praxis prägnant, und auf den Punkt gebracht für Autodesk Produkte | | | |  | PNY: der unverzichtbare Partner für umfassende KI-Lösungen von Workstations bis zu Edge Computing und KI-Cluster-Bereitstellung, eine Pressemitteilung
|
|
Autor
|
Thema: Node Red - gibt's Bedarf für sowas? (63 / mal gelesen)
|
archtools Mitglied
   
 Beiträge: 1086 Registriert: 09.10.2004 Entwickler für AutoCAD, BricsCAD u.a., alle Systeme
|
erstellt am: 18. Feb. 2026 16:43 <-- editieren / zitieren --> Unities abgeben:         
Vielleicht kennen einige von Euch Node Red, ein von IBM entwickeltes und frei gegebenes graphisches Entwicklungssystem auf Basis JavaScript. Man hat sogenannte Nodes, die durch kleine Kästchen repräsentiert werden, und platziert und verbindet diese zu einem Flow. Ein Flow ist dann ein lauffähiges Programm. Alles notwendige über Node Red erfährt man hier: https://nodered.org/Ich bin durch Zufall auf Node Red gestoßen, weil meine Victron-Photovoltaikanlage damit programmierbar ist und ich da jetzt etwas daran herumgebastelt habe. Aber im Grunde kann man Node Red für viele verschiedene Dinge verwenden. Viele Nodes (also diese Knotenteile, die aus dem Input irgendwas konkretes tun oder was berechnen und dann an andere Nodes weiter geben) sind vordefiniert, viele andere kommen von Firmen, die ihren Geräte damit steuern lassen wollen (z.B. Victron, Shelly), und man kann sie auch selbst definieren. Mir ist dabei gleich in den Sinn gekommen, dass mein Programm CALScript im Grunde auch sowas ist. Man kann damit im CAD auf einfachste Weise graphische Objekte definieren, die aus Input was berechnen, daraus ihre eigene Gestalt erzeugen und durch Verbindung mit anderen Objekten auch Daten an diese weiter geben können. In der kostenfreien CALScript Installation (https://www.calscript.com/) sind entsprechende Beispiele enthalten. Die CALScript Objekte sind also sowas wie die Nodes bei Node Red. Bei den CALScript Objekten kann bis dato ein Objekt als "Sender" zwar mit beliebig vielen anderen verbunden werden, aber als "Empfänger" nur mit einem einzigen Sender. Das könnte ich so weit umbauen, dass beidseitig beliebig viele Kommunikation stattfinden kann. Und v.a. würde ich bei Bedarf spezielle funktionale Objekte vordefinieren, wie beispielsweise den SWITCH Node in Node Red, der so arbeitet wie das COND in Lisp. Man legt in diesem Node verschiedene Fallunterscheidungen fest, und für jeden Fall gibt es einen eigenen Kommunikationsausgang. Damit könnte man mittels CALScript Objekten praktisch ohne Programmierung komplexe Programme aufbauen, und komplexe Systeme modellieren und Animationen und Simulationen durchführen. Wie ist das Interesse? Gibt es Anregungen, Ideen, Einsatzmöglichkeiten? Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
Vino Mitglied
 
 Beiträge: 249 Registriert: 24.05.2005 Windows 10 BricsCAD Pro V23
|
erstellt am: 19. Feb. 2026 08:24 <-- editieren / zitieren --> Unities abgeben:          Nur für archtools
Hallo, ich kenne Node Red aus dem Smarthome-Bereich früher mit ioBroker (Heute nutze ich HomeAssistant ohne NR)... Das ist zwar cool, aber ich weiß nicht, ob das für (Brics-/Auto-)CAD so viel bringt. Ein Paar Leute wirst du sicher finden, die das toll finden würden. Aber mit LISP haben wir ja schon eine Programmiersprache, die (auch wenn die Klammerwut und Präfix-Notation wohl am Anfang bissl verwirrt) ohne große Hürden zu schnellen Erfolgen führt. Jemand, der die Programmier-Logik versteht, kommt mit Lisp genauso zurecht wie mit Node-Red und muss dafür nicht noch was installieren und einrichten. Jemand der das nicht tut, kommt wohl mit beidem nicht klar. Meine Meinung ;-) Gruß, Stefan Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |

| |
archtools Mitglied
   
 Beiträge: 1086 Registriert: 09.10.2004 Entwickler für AutoCAD, BricsCAD u.a., alle Systeme
|
erstellt am: 19. Feb. 2026 09:39 <-- editieren / zitieren --> Unities abgeben:         
Zitat: Original erstellt von Vino: Hallo,ich kenne Node Red aus dem Smarthome-Bereich früher mit ioBroker (Heute nutze ich HomeAssistant ohne NR)... Das ist zwar cool, aber ich weiß nicht, ob das für (Brics-/Auto-)CAD so viel bringt. Ein Paar Leute wirst du sicher finden, die das toll finden würden. Aber mit LISP haben wir ja schon eine Programmiersprache, die (auch wenn die Klammerwut und Präfix-Notation wohl am Anfang bissl verwirrt) ohne große Hürden zu schnellen Erfolgen führt. Jemand, der die Programmier-Logik versteht, kommt mit Lisp genauso zurecht wie mit Node-Red und muss dafür nicht noch was installieren und einrichten. Jemand der das nicht tut, kommt wohl mit beidem nicht klar. Meine Meinung ;-) Gruß, Stefan
Da hast Du was falsch verstanden. Es geht nicht darum, eine weitere Programmiersprache wie JavaScript zu etablieren.Im Gegenteil: hier würde alles in LISP bleiben, und der Endanwender braucht zum Erstellen und Simulieren komplexer Modelle selbst keinerlei Lisp Kenntnisse. uch CALSCript ist in Lisp geschrieben, und erzeugt aus den vom Anwender kommenden Skripten Lisp-Funktionen. Und es geht nicht ums Schreiben von Programmen, sondern um das Erzeugen intelligenter Modelle, Simulationen usw.. Stell' Dir zuerst mal miteinander kommunizierende CAD-Objekte vor (kannst Du mit CALScript testen). Das kann alles mögliche sein, beispielsweise Zahnräder, die zusammen ein Getriebe bilden, das dann animiert wird, oder Rohre die zu einem Leitungssystem verbunden werden. Diese graphischen Objekte haben bestimmte Eigenschaften, die auch verändert werden können, und ein Objekt bestimmt, welche Daten es an seine Empfänger sendet, und die Folgeobjekte passen sich an. Beim derzeitigen Stand von CALScript kriegen alle Empfänger die gleiche Nachricht, und sie müssen selbst entscheiden, was davon sie wie weiter verarbeiten. Mit rein funktionalen "Nodes" gibt es einen Zwischenschritt: diese kriegen die Nachricht, verarbeiten diese, und senden unterschiedliche Daten an die Empfänger weiter, oder auch mal gar keine. Es gibt in komplexeren Modellen immer auch Reaktionen, die beispielsweise nicht von den beteiligten Objekten selbst abhängen, sondern von anderen, durchaus dynamisch veränderbaren Umständen. Dazu braucht man dann neben der Objektkommunikation noch weitere Objekte, deren graphische Ausprägung nichts zur Darstellung des Modells beiträgt, sondern die funktionale Bedeutung haben. Die von einem Sender-Objekt kommende Kommunikation wird dann nicht beim Empfänger verarbeitet, sondern in einem funktionalen Zwischenobjekt. Die zur Darstellung des Modells beitragenden Objekte brauchen dann nicht jeden möglichen Sonderfall intern zu berücksichtigen, sondern können sehr viel einfacher und allgemeiner gehalten werden. Dem Beispiel von Node Red folgend können dann beispielsweise Hersteller wie Shelly ihre Bauteile als Objekte herstellen und an die Anwender verteilen. Diese setzen sie ganz trivial zusammen, und bringen erst beim Zusammenbau durch funktionale "Nodes" das für den konkreten Anwendungefall notwendige weitere Wissen dazu. Solche funktionalen Nodes erlauben damit die Erstellung wesentlich komplexerer Modelle, nicht nur mit linearer Kommunikation zwischen einzelnen Objekten, sondern mit vielfacher nicht-linearer und mehrfach gebundener Kommunikation. Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP |
| Anzeige.:
Anzeige: (Infos zum Werbeplatz >>)
 |