Eure Vorschläge: Erweiterung meiner grafischen OPC Ablauf Software

D

david.ka

Level-2
Beiträge
180
Reaktionspunkte
26
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

im Zuge eines Projekts habe ich eine kleine Zusatzsoftware entwickelt.
Mit dieser Software kann man eine Art Logik / Ablauf grafisch erstellen (Anhang).
Man kann Bausteine einfügen und diese dann miteinander verbinden.
Einige selbsterklärende Bausteine habe ich schon geschrieben:
NOT, AND, OR, Timer, Compare, DateAndTime, OpcClient, SetReset, Trigger, MidMinMax,
SysDateTimeComp, BinCode, Switch, Random und StopWatch

Bevor ich das ganze aber zum Download bereitstelle (und die Doku erstelle),
würde ich gerne noch einige Bausteine integrieren.
Welche wären denn eurer Meinung nach für euch wichtig,
wenn Ihr solche Software einsetzen würdet?

Geplant sind evtl:
- LibNoDave (Kommunikation über LibNoDave zur SPS)
- TextDatei (Schreibt den Wert in eine TextDatei)
- MSSQL (schreibt den Wert in eine MSSQL Datenbankt)


Bin über jede Antwort Dankbar.

Beste Grüße,
David
 
Es ist klar das es eine graphische flussorientierte Programmiersprache ist - aber es fehlt ein schönes(etwas groesseres) nicht-theoretisches Beispiel

Welche Organisationsmoeglichkeiten hast du:
  • der ganze Fluss immer nur auf einem Bild?
  • Wird automatisch angeordnet oder angeboten?
  • kann man Unterfunktionen/Schachtelungen (mit Parametern?) erstellen?

Programmbeeinflussung

  • hast du einen "Debugger"?
  • kann man Eingabewerte (Dateneinfluss) leicht simulieren?
  • Welche Arten von Flusserzeugern gibt es Events, mehrere Ablaufstränge gleichzeitig, OnChange, Timer?

Type?

  • Welche elementaren Typen verstehst du Double,Float, ASCII/Unicode Zeichen
  • gehen auch Arrays - also String[n] oder int MeineDaten[10]?
  • gibt es auch Konstanten?
  • wie sieht es aus mit Strukturen?
  • Hast du Referenzen oder wird immer mit Kopien gearbeitet?
  • Wie funktioniert deine Wertübergabe - muessen Typen exakt passen oder Konvertierst du hin/her <- wie sieht es da aus mit Abbilundgsproblemen/Präzisionsverlust (float<->double, string[8]<->string[10], ascii<->unicode,etc.)

Wo willst du genau erreichen?
  • einfach genug granulare Befehle bauen damit man alles machen kann?
  • Wie sieht es aus mit Performance, Grenzen usw?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Vielleicht solltest du dir darüber Gedanken machen eine Art Prozessabbild einzubauen.
Gerade wenn die Daten von verschiedenen Quellen kommen, hat das - meines Erachtens - Vorteile.

Gruß
Dieter
 
vielen Dank für Eure Antworten.

@ LowLevelMahn
Momentan ist es so, dass der gesamte "Fluss" auf einem Bild (srollbar) dargestellt wird.
dort können auch mehrere "Flüsse" programmiert werden, wie z.B. die Netzwerke im Simatic Manager.

autom. Anordnung hab ich nicht gemacht (weil ich pers. sowas nicht mag). Ein Raster wäre aber denkbar.

Der "Fluss" ist primär Event-Gesteuert. An jedem Baustein gibt es aber einen Power-Button, d.h. dieser Block wird dann in einem bestimmten Intervall ausgeführt. (z.B. 100ms).

Als elemataren Typ habe ich momentan Double. Evtl. kommen noch strings hinzu.

Array Bausteine habe ich noch nicht gemacht, das erfordert etwas mehr Arbeit, kommt aber noch.
Das Gesamte System basiert auf dem .NET Framework. Es gibt dann eine Möglichkeit selber Bausteine (anhand einer Projektvorlage in VS) zu schrieben.
z.B. Baustein für ein Ventil, Motor o.ä. Ich verwende sowas für meine Simulation beim Testen von Visualierungen.

Performance: hängt nätürlich auch vom Rechner ab.
200 Bausteine sind aber problemlos möglich.

Es wird auch möglich sein, mehrere solcher Instanzen zu starten (in versch. Tabs), um dort weitere Abläufe zu programmieren. Da jede Instanz in einem eigenen Thread laufen wird, sollte es performancemäßig keine Probleme geben. Es spricht aber auch nichts dagegen, das Programm mehrmals zu starten.

Einen Debugger gibt es nicht. Finde ich auch Überflüßig, da ich den kompletten ablauf grafisch sehe.
Alle Eingabewerte können manuell geändert werden.

@Blockmove
ich verstehe leider nicht genau was du als Prozessabbild meinst?

@Thomas_v2.1
Ich kenne die Programme leider nicht, ich habe sie gerade eben mal gegooglt. Ich denke schon, das dies in diese Richtung geht.
Hätte ich sie vorher gekannt...

Ich habe das ganze für einen Kunden programmiert, welcher eigentlich nur eine "Logik" für seine Anlage gebraucht hat.
Diese sollte unbedingt auf einem PC laufen und über OPC arbeiten. Da ich diese aber nicht fix im Code hinterlegen wollte, habe ich dieses Tool Entwickelt.

Da man aber damit weitaus mehr machen könnte, möchte ich das ganze Erweitern...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Willst du das Programm denn hauptsächlich zu Visualisierungs- oder Simulationszwecken weiterentwickeln?
So wie ich das verstehe, hast du das erstmal für Visualisierungszwecke entwickelt und nutzt es jetzt für Simulationen weiter. Vielleicht schreibst du mal worauf dein Fokus liegt.

Zum Visualisieren ist das zwar ganz schön, aber das versteht imho auch nur jemand der mit der Programmierung halbwegs vertraut ist. Das was du da nachgebildet hast, entspricht weitestgehend der Darstellung von Programmen in CFC. Wenn man das Programm direkt in CFC erstellt, benötigt man eine solche Visualisierung eigentlich nicht mehr.

Was ich nicht schlecht finde, ist verschiedene Linientypen/-farben und verschiedene Darstellungen der Anbindungspunkte (z.B. Kreis, Dreieck, Rechteck) für verschiedene Datentypen (zumindest Bool, Integer, Gleitkomma) zu verwenden. Und man sollte die Aufrufreihenfolge der Objekte einstellen können, damit man den Datenfluss in einem Aufrufzyklus kennt - wie in CFC eben.

Ich muss sagen, dass ich dein Programm für Simulationen nicht schlecht fände (mit Plcsim Anbindungsbox...). Für ein Projekt war mal eine vorab Simulation der Anlage gefordert, und in dem Zuge habe ich mir auch mal Xcos näher angeschaut. Vom Prinzip her ist dort die Erstellung von eigenen Blöcken möglich die man dann nur noch in den Plan ziehen muss, aber die Erstellung ist viel zu kompliziert (Xcos ist selber auch nicht gerade bugfrei, geschweige denn optisch ansprechend). Hauptnachteil war aber, dass mit Xcos nicht mal grad so auf die Schnelle eigene Simulationsobjekte erstellt werden können.
 
Momentan ist es so, dass der gesamte "Fluss" auf einem Bild (srollbar) dargestellt wird.
dort können auch mehrere "Flüsse" programmiert werden, wie z.B. die Netzwerke im Simatic Manager.
Zum Vergrößern anklicken....

kann man eigene "Organisationsblöcke" definieren und kann kann man die Ein/Ausgangs"variablen" dort frei definieren? -

Der "Fluss" ist primär Event-Gesteuert. An jedem Baustein gibt es aber einen Power-Button,
d.h. dieser Block wird dann in einem bestimmten Intervall ausgeführt. (z.B. 100ms).
Zum Vergrößern anklicken....

also hast du eingebaute Timer und OnChange

Als elemataren Typ habe ich momentan Double. Evtl. kommen noch strings hinzu.
Zum Vergrößern anklicken....

Das ist aber höchst mager - damit kommst du garantiert nirgendwo hin, warum diese Einschränkung?

Array Bausteine habe ich noch nicht gemacht, das erfordert etwas mehr Arbeit, kommt aber noch.
Zum Vergrößern anklicken....

also bildest du auch komplexe Typen über Bausteine ab - und dann gibt eine Index-Variable, also so eine Art (De)Multiplexer

Performance: hängt nätürlich auch vom Rechner ab.
200 Bausteine sind aber problemlos möglich.

Es wird auch möglich sein, mehrere solcher Instanzen zu starten (in versch. Tabs), um dort weitere Abläufe zu programmieren. Da jede Instanz in einem eigenen Thread laufen wird, sollte es performancemäßig keine Probleme geben. Es spricht aber auch nichts dagegen, das Programm mehrmals zu starten.
Zum Vergrößern anklicken....

Ok also keine Hochperformanzanwendung - also zeitkritische Teile einer Produktion oder sowas - du hast einen eigenen Interpreter der alles von Hand durchreicht (daher bestimmt auch die Eingrenzung auf double - macht die Schnittstellen so schön einfach) oder generierst du gar direkt IL Code?

Einen Debugger gibt es nicht. Finde ich auch Überflüßig, da ich den kompletten ablauf grafisch sehe.
Alle Eingabewerte können manuell geändert werden.
Zum Vergrößern anklicken....

Naja es ist schon schön wenn man im grafischen Ablauf Wait- oder Stopmarken setzen könnte damit bei großen Netzwerken nicht
immer alles kurz blinkt und schwupps ist man an der Fehlerstellen vorbeigerauscht - eine grafische Ein/Ausgabe verhindert nicht die
typischen Probleme beim programmieren oder der Fehlererkennung - oder sollen die Programme in deiner Umgebung immer trivial bleiben?
 
ich glaube du hast das etwas falsch verstanden. Das ganze ist natürlich keine Programmiersprache, sondern nur ein Tool, mit dem man Funktionen / FunktionsBausteine logisch miteinander verbinden kann. Diese Funktionsbausteine kann man problemlos in c# schreiben.

Ich denke double reicht vorerst mal völlig aus, denn dein c# Baustein kann eine Konvertierung in bool, int, short, ... erledigen.

Genau, nur onchange(), außer wenn der POWER Button gedrückt ist, dann wird in diesem Baustein der Timer aktiviert.

Eine Hochperformanzanwendung? NEIN!!! ich denke, von Hochperformanzanwendung auf einem Windows Rechner und gewöhnlicher Hardware zu sprechen, macht keinen Sinn. Das läuft wirklich schnell & stabil, aber Hochperformanzanwendung wäre der falsche begriff.

Naja, die Programme müssen nicht zwingen trivial bleiben, ich meine, du kannst einen sehr umfangreichen c# Block schreiben. Diesen siehst du dann in der "Außenansicht" und kannst ihn beliebig verschalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich glaube du hast das etwas falsch verstanden. Das ganze ist natürlich keine Programmiersprache, sondern nur ein Tool, mit dem man Funktionen / FunktionsBausteine logisch miteinander verbinden kann. Diese Funktionsbausteine kann man problemlos in c# schreiben.
Zum Vergrößern anklicken....

sobald Conditions und Schleifen erstellt werden können ist es eine Programmiersprachen - nur dein Quelltext sieht anders aus :)

Ich denke double reicht vorerst mal völlig aus, denn dein c# Baustein kann eine Konvertierung in bool, int, short, ... erledigen.
Zum Vergrößern anklicken....

Nur das ich es nicht falsch verstehe - deine Bausteine können nur Doubles als Eingabe/Ausgabe enthalten - d.h. ein IsGreaterAs(oder dein Compare)-Baustein frisst ein 1.2 und 4.5 und spuckt ein 0.0 oder 1.0 aus
es ist klar das der C#-Baustein intern alles damit machen kann was er will - d.h. aber das zwischen deinen Bausteinen z.B. nur Werte herumgereicht werden können die sich verlustfrei in einem double abbilden lassen
d.h. wenn intern mit in64 oder float gerarbeitet wird (werden muss) kann es passierte das es nicht passt oder gerundet wird

Eine Hochperformanzanwendung? NEIN!!! ich denke, von Hochperformanzanwendung auf einem Windows Rechner und gewöhnlicher Hardware zu sprechen, macht keinen Sinn. Das läuft wirklich schnell & stabil, aber Hochperformanzanwendung wäre der falsche begriff.
Zum Vergrößern anklicken....

Wie ist die Performance wenn du einen Sqrt-Baustein machst und damit eine Schleife 1-10000 durchläufst - wo bleibt da die meiste Zeit liegen - denke primär in/zwischen deiner Interpreter-Schicht, weniger im internen Sqrt

Naja, die Programme müssen nicht zwingen trivial bleiben, ich meine, du kannst einen sehr umfangreichen c# Block schreiben. Diesen siehst du dann in der "Außenansicht" und kannst ihn beliebig verschalten.
Zum Vergrößern anklicken....

Das ist klar - aber ausser, es ist was passiert, gibt es sonst keine Hilfestellung beim "Debuggen" von komplexen Netzwerken, also nicht die Blöcke selbst sondern was damit erreicht wurde - ist das alles immer noch so schön nachvollziehbar wenns dann mal 200 Bautsteine sind???
 
naja, double ist ja quasi in .net eine fließkommazahl mit einem sehr großen wertebereich.
das casten sollte eigentlich keine Probleme machen, zumindest sind mir keine bekannt.

double hab ich damals einfach verwenden müssen, war so vorgegeben ;)
 
naja, double ist ja quasi in .net eine fließkommazahl mit einem sehr großen wertebereich.
das casten sollte eigentlich keine Probleme machen, zumindest sind mir keine bekannt.
Zum Vergrößern anklicken....

was auch immer das heissen soll - ein .net double ist eine 64Bit breite IEEE754 konforme Fließkommazahl - mit der Ausnahme das .net kein Problem mit denormalen floats hat
also kannst du z.B. nicht verlusstfrei einen long in einen double konvertieren


double hab ich damals einfach verwenden müssen, war so vorgegeben
Zum Vergrößern anklicken....

Die Vorgabe war sicher nicht "darf nur mit double arbeiten" sondern eher "sollte mit double arbeiten", oder?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich habe deine Aussage vorhin falsch verstanden. sorry. ja das stimmt, es kommt dann 0.0 o. 1.0 raus.
dafür gibt es dann Converter Klassen, die man im Baustein verwenden kann.
Nur das ich es nicht falsch verstehe - deine Bausteine können nur Doubles als Eingabe/Ausgabe enthalten - d.h. ein IsGreaterAs(oder dein Compare)-Baustein frisst ein 1.2 und 4.5 und spuckt ein 0.0 oder 1.0 aus
Zum Vergrößern anklicken....




naja, kommt ja fast auf dasselbe raus, oder nicht? ;) Erweitern kann man ja immer, nur ob das hier wirklich notwendig ist, ist eine andere sache.
 
Zurück
Oben