Hallo
ich werde in kürze ein umfangreiches Messprogramm bauen... nun will ich das möglichst "schick" machen...
iwelche grundstuktur nehmt ihr für ein Messprogramm
ich dachte an eine state machine ... es werden warscheinlich 20-25 cases...
welche variante ist "besser" geeignet ...
[
attachment=14916]
Variante 1 mit Schieberegister und Variante 2 mit lokalen Variablen...
Vorteil von Variante 2 ist: weniger drähte ...
wie macht ihr das ???
Toaran
Hilfe, bloss nicht Variante 2!!
State Machine immer mit Shift-Register.
Vorteil: Weniger Speicherverbrauch (jede lokale Variable erzeugt Kopien im Speicher), keine Gefahr von Race Condition, keine Gefahr, eine Weiterleitung des Zustandes für den nächsten Durchlauf zu vergessen (wenn du beim Case-Ausgang den Default abschaltest), etc, etc, etc.
Gruß, Jens
Wie wäre es mit Event-Struktur? Oder kein Professional Development Kit?
Grüße,
ch
Wozu überhaupt eine State-Machine? Was hast du vor?
' schrieb:Wozu überhaupt eine State-Machine? Was hast du vor?
Hallo
also ich muss ein Gerät vermessen...
dazu verschiedene initialisierungs parameter an das gerät über RS232 senden
dann an verschiedenen flowcontrollern über DAQ bestimmte Gaskonzentrationen einstellen
und je nach Messprogramm zwischen den Gasen über Ventile hin und her springen auch DAQ ...
dabei dann verschiedene Messungen machen .. also Gaskonzentration, Ansprechzeiten Rauschen etc.
das Messprogramm muss flexibel sein ...also verschiedene Zeiten einstellbar usw...
ich denke ich werde einen mix aus state machine und event strucktur machen ...
die eventstuktur zur programmsteuerung und die statemachine um das Messprogramm ablaufen zu lassen ...
Toaran
woran kann es denn liegen das meine state maschine sehr langsam läuft, hab sie so programmiert wie auf dem bild von toaran aber in der while schleife (um die case struktur) sind noch andere vis und verschiedene ein- und ausgaben.
wie kann man das ändern, das es "echtzeitfähig" wird
danke gruß gerald
' schrieb:woran kann es denn liegen das meine state maschine sehr langsam läuft, hab sie so programmiert wie auf dem bild von toaran aber in der while schleife (um die case struktur) sind noch andere vis und verschiedene ein- und ausgaben.
Bei solchen Fragen geht mir der Hut hoch...
Woher sollen wir das wissen, ohne auch nur einen Screenshot deines VIs (besser: VI posten!) gesehen zu haben?
Zitat:wie kann man das ändern, das es "echtzeitfähig" wird
Entsprechende Antwort: Fehler beseitigen!
' schrieb:Bei solchen Fragen geht mir der Hut hoch...
Woher sollen wir das wissen, ohne auch nur einen Screenshot deines VIs (besser: VI posten!) gesehen zu haben?
Entsprechende Antwort: Fehler beseitigen!
ja dann bin ich jetzt mal gespannt.
gleich mal vorne weg, posten bringt nix, weil das vi 2 subvis beinhaltet die für die profibus kommunikation zuständig sind wenn ihr also das vi startet habt ihr gleich fehler.
vi1: stellt die verbindung zum ethernet/profibus gateway her (wie genau keine ahnung weils gekauft is seh nur die anschlüsse).
vi2: com schnittstelle (siehe bild)
vi4: dient zur kommunikation mit dem gateway (genau anschauen kann ich mir das auch nicht weil es gekauft is und man nur die anschlüsse sieht).
vi7: wandelt die verschiedenen eingangwerte der bits in einen hexwert und fügt alle zu einem string zusammen die dann auf den bus gelegt werden
vi8: zerlegt den string vom bus und gibt mir die werte der einzelen bits aus
der taktgenerator dient zur erstellung eines lebenszeichens das von der maschinensteuerung erwartet wird, fehlt der, steigt die steuerung der maschine aus.
der referenzanschluss auf der rechten seite führt zu einem zweiten taktgenerator der eine andere frequenz darstellt.
die kommunikation ohne die states funktioniert einwandfrei, da kann also eig. kein fehler sein aber sobald man da die state machine einfügt fängt die kommunikation an zu haken und die steuerung steigt aus, weil der lebenszeichentakt nicht mehr stimmt.
hab die state machine auch schon mit lokalen variablen probiert aber das führt zum gleichen ergebnis.
danke schonmal für die mühe
gruß gerald
ach ja is mit 8.5 gemacht
[
attachment=14952]
[
attachment=14953]
' schrieb:die kommunikation ohne die states funktioniert einwandfrei, da kann also eig. kein fehler sein aber sobald man da die state machine einfügt fängt die kommunikation an zu haken und die steuerung steigt aus, weil der lebenszeichentakt nicht mehr stimmt.
Ich mach sowas immer wie folgt.
Erstens: Von Propertys, die über eine Referenz angesteuert werden, rate ich ab. Von normalen Propertys, wenn sie sich in einer Dauerschleife befinden, auch. Ich kann mir bisher keinen Fall vorstellen, in dem ein derartiges Vorgehen mit Referenzen notwendig wäre. Normalerweise geht sowas mit Datenfluss und Schiebereigistern.
Zweitens: Wenn es sich bei den Boolschen Elementen um Eingabeelemente handelt, die ein Anwender z.B. am Bildschirm bedienen kann, würde ich zur Verarbeitung diese Elemente eine Eventstruktur verwenden.
Drittens: Für den Profibus würde ich eine sog. Klasse machen. Das ist ein SubVI, dass selbständig läuft. Gesteuert wird dieses SubVI durch Queues. Daten in dieses SubVI kommen mit der Queue. Daten aus dem SubVI mit Meldern. Die Klasse kann z.B. selbständig das Taktsignal ausgeben. z.B. alle 50ms. Im Rest der Zeit wird auf Daten von der Queue gewartet. etc.
Übrigens: Das Anpassen dieser Klasse an ein neues, völlig anderes Projekt, das lediglich eben auch AI's verwendet, dauert gerademal zwei Stunden.
Ferner: Wenn da viele einzelne Eingabe/Ausgabe-Elemente vorhanden sind, würde ich die in einen Cluster legen. Der geht einfacher zu handeln: Einfach einen Draht für allle weiterschieben.
Hier hab ich mal ein Muster für so eine Klasse gepsotet:
Muster ohne Wert:
Muster AIn-Klasse (siehe Ende Posting #12 vom 25.02.2008 , 22:41:06).
' schrieb:Zweitens: Wenn es sich bei den Boolschen Elementen um Eingabeelemente handelt, die ein Anwender z.B. am Bildschirm bedienen kann, würde ich zur Verarbeitung diese Elemente eine Eventstruktur verwenden.
hi, danke für die schnelle antwort
Die Bedienelemente sollen automatisiert (in den verschiedenen states) angesteuert werden damit man Dauertestzyklen programmieren kann. also sollte das ganze auch recht flexibel sein, je nach dem was man testen will.
hmm ok dann werd ich mich mal in klassen und co einarbeiten hab damit noch nie was gemacht,...
gruß gerald