Kopie meines VI enthält nicht alle subVIs

Du kannst Dateien auch zippen.

Gruß Markus

Anzeige

ah, ok, hab gar nicht gewusst, dass man da dann den ganzen Ordner hochladen kann.

Also die Datei heißt "ps10demo_1axis.vi"

Diese versuche ich vergeblich zweifach laufen zu lassen

Also: Ich hab mirs mal angekuckt.

Zuerst muss ich sagen: Die Programmierung bietet viel Optimierungsmöglichkeiten. Da wimmelt es von Race-Conditions, die alle entfernt werden müssten! Genauso wie die vielen unnötigen Lokalen Variablen! Einiges sollte unbedingt sequenziert werden, anderes unbedingt mit Event-Struktur gelöst werden.

Nun zur Problemlösung:
Das VI "ps10demo_1axis.vi" soll - und kann - also eine einzelne Achse steuern. Du willst nun zwei solche Achsen steuern. Ob das alleine dadurch geht, dass du dieses VI zweimal aufrufst (invariant oder nicht) kann ich z.Z. nicht entscheiden. Ein Problem kann darin liegen, dass beide VIs das selbe Device - Serielle Schnittstelle - verwenden könnten. (Verwenden zwei Instanzen das selbe Device, so müssen die Instanzen synchronisiert werden - was den Vorteil der Instanzen zu nichte macht.)

Wie werden denn die Achsen angesteuert: jede Achse eine eigene Serielle Schnittstelle? Oder hängen beide Achsen an der selben COM-Schnittstelle?

Und mach dich mal schlau über die Event-Sequenz: Die Cases, die von Start, Go, GoRef und SwitchFree angesteuert werden, gehören in eine Event-Struktur.
Alle Cases, die von INC abhängen, sollten alle in nur einem einzigen Case liegen.

ok, interessant zu hören...

jede Achse, also jeder Motor, hat eine eigene com-Schnittstelle, muss man eben immer umstellen wenn man den anderen Motor verwendet.

' schrieb:ok, interessant zu hören...

Was hat das jetzt für Konsequenzen?

Zitat:jede Achse, also jeder Motor, hat eine eigene com-Schnittstelle, muss man eben immer umstellen wenn man den anderen Motor verwendet.

Das wirft aber doch ein Problem auf.

Ich gehe davon aus, dass die DLL PS10.dll prinzipiell schon in der Lage ist, mehrere Motoren zu steuern. Auch dann noch, wenn die Motoren an unterschiedlichen Schnittstellen hängen. (Hingen sie an der selben Schnittstelle, wäre die Schnittstelle vom Typ RS485/RS422).

Woher aber weiß das Modul (also die DLL) welchen Motor es jetzt gerade ansprechen soll? Hängen die Motoren an der selben Schnittstelle, könnte das über den Parameter "Axis Number" gehen, den jeder DLL-Knoten als Eingang hat. Hängen die Motoren aber an unterschiedlichen Schnittstellen, würde das so nicht mehr gehen. Da Schnittstellen initialisiert werden müssen, muss die DLL bereits im SubVI PortInit mitgeteilt bekommen, welcher Motor an welcher Schnittstelle hängt. Da gibt es aber nur den Eingang "Control Unit ID". Ich gehe jetzt davon aus, dass du überall zusätzlich zu Axis Number den Eingang "Control Unit ID" verwenden musst.

Axis Numer hat grundsätzlich den Wert 1. Die eine Schnittstelle, also der eine Motor, bekommt "Control Unit ID=1". Die andere Schnittstelle, also der zweite Motor, bekommt "Control Unit ID=2). Jetzt solltest du das VI ps10demo_1axis.vi zweimal starten können (entweder reentrant oder umbenannt).

"ok..interessant zu hören..."

also ich habe das Programm nicht geschrieben. deshalb interessant dass der Entwickler da so viel Fehler reinmacht :-)

Also heißt das, dass ich die Contraol Unit ID fest auf 1 setzten muss, dann das Programm speichern, dann die ID fest auf 2 setzen und das Programm unter einem anderen Namen speichern?

Wenn ich die Motoren immer einzeln ansteuere haben sie immer Control UNit ID 1.

Anzeige

' schrieb:Also heißt das, dass ich die Contraol Unit ID fest auf 1 setzten muss, dann das Programm speichern, dann die ID fest auf 2 setzen und das Programm unter einem anderen Namen speichern?

Besser so:
Ein Programm machen, das als Eingang den Wert von Control Unit ID hat. Diesen wert dann auf alle (!) entspechenden DLL-Knoten etc geben. Dieses VI dann unter zwei Namen abspeichern und ein Haupt-VI machen, das beide SubVIs aufruft.
Wenn du dann eine Änderung machen musst, brauchst du das Programm nur noch unter den anderen Namen speichern - und schon gehen wieder beide Motoren.

Zitat:Wenn ich die Motoren immer einzeln ansteuere haben sie immer Control Unit ID 1.

"Control Unit ID" könnte sowas wie ein Handle sein. Der tatsächliche numerische Wert ist egal. Wichtig ist nur, dass immer genau dieser Wert an den DLL-Knoten übergeben wird.

ok... hat geklapt!

VIELEN DANK AN EUCH ALLE !

Naja, ich habe schon Hardware gekauft (ich will den Namen nicht nennen), da wurde der LabVIEW-Treiber (DLL-Aufrufe,...) von einem Praktikanten erstellt. Da war auch nicht alles so konform, wie es sein sollte. Manche Dinge habe ich da auch nachträglich geändert / ändern müssen.
Du siehst, dass das leider kein Einzelfall ist.

Gruß Markus

' schrieb:deshalb interessant dass der Entwickler da so viel Fehler reinmacht :-)