Semaphor Fehler/Error 1111

[etmtr]

Hi,

ich habe das eigentliche VI stark vereinfacht und angehängt. Hier wird ein Semaphor benutzt, um über eine optische Schnittstelle mit einem Messgerät zu kommunizieren. Das VI prüft zuerst, ob die Messung gestartet wurde, wonach durch ein anderes VI geprüft wird, ob es einen Fehler bei der Kommunikation gibt. Gibt es keinen Fehler, kann die Semaphore freigegeben und die Variablen aus dem Messgerät ausgelesen werden. (Vermutung) Die Problemursache entsteht dadurch, dass 1 vor 2 ausgeführt wird (siehe VI in Anlage).

Hat vielleicht jemand eine andere Vermutung oder einen Lösungsansatz, wie dieses Problem behoben werden kann?

Vielen Dank im Voraus!

english version:

Hi,

I greatly simplified the actual VI and attached it. A semaphore is used here to communicate with a measuring device via an optical interface. 
The VI first checks whether the measurement has started, after which another VI checks whether there is an error in the communication. 
If there is no error, the semaphore can be released and the variables can be read from the measuring device. 
(Assumption) The cause of the problem arises from the fact that 1 is executed before 2 (see VI in Appendix).

Maybe someone has another guess or a solution how to fix this problem?


Thanks in advance!

[etmtr]

Hi,

ich habe das eigentliche VI stark vereinfacht und angehängt. Hier wird ein Semaphor benutzt, um über eine optische Schnittstelle mit einem Messgerät zu kommunizieren. Das VI prüft zuerst, ob die Messung gestartet wurde, wonach durch ein anderes VI geprüft wird, ob es einen Fehler bei der Kommunikation gibt. Gibt es keinen Fehler, kann die Semaphore freigegeben und die Variablen aus dem Messgerät ausgelesen werden. (Vermutung) Die Problemursache entsteht dadurch, dass 1 vor 2 ausgeführt wird (siehe VI in Anlage).

Hat vielleicht jemand eine andere Vermutung oder einen Lösungsansatz, wie dieses Problem behoben werden kann?

Vielen Dank im Voraus!

Englisch:

Hi,

I greatly simplified the actual VI and attached it. A semaphore is used here to communicate with a measuring device via an optical interface. The VI first checks whether the measurement has started, after which another VI checks whether there is an error in the communication. If there is no error, the semaphore can be released and the variables can be read from the measuring device. (Assumption) The cause of the problem arises from the fact that 1 is executed before 2 (see VI in Appendix).

Maybe someone has another guess or a solution how to fix this problem?

 

Thanks in advance!

[etmtr]

Hi,

ich habe das eigentliche VI stark vereinfacht und angehängt. Hier wird ein Semaphor benutzt, um über eine optische Schnittstelle mit einem Messgerät zu kommunizieren. Das VI prüft zuerst, ob die Messung gestartet wurde, wonach durch ein anderes VI geprüft wird, ob es einen Fehler bei der Kommunikation gibt. Gibt es keinen Fehler, kann die Semaphore freigegeben und die Variablen aus dem Messgerät ausgelesen werden. (Vermutung) Die Problemursache entsteht dadurch, dass 1 vor 2 ausgeführt wird (siehe VI in Anlage).

Hat vielleicht jemand eine andere Vermutung oder einen Lösungsansatz, wie dieses Problem behoben werden kann?

Vielen Dank im Voraus!

[altenbach]

(I removed the attachment in your first post, because it seems to be the same VI, but containing tons of breakpoints)

Obviously, you are coming from a text based programming background and have not embraced the power and elegance of dataflow. Indications are that all terminals are disconnected in the upper left and all wiring done vial local variables. Local variables are NOT variables in the classic sense, the wire is the variable!

LabVIEW is a highly parallel programming language and since your two loops have no data dependency, they will both start at the same time and there is no way to tell what starts first if you only have one CPU core. Your sequence structure initializing you terminals also runs in parallel and there is no guarantee that it will execute before the loops start, leading to glaring race conditions. What's the purpose of the lower outer while loop? (It will cause the timed loop to be called twice, the second time for only one iteration before the VI stops). Your upper loop is a greedy loop!

All you probably need is a clean state machine architecture.

Can you give step-by-step instructions how you run the VI, what the control defaults are, what you see, and what you expect to see instead so we can try to reproduce and fix whatever you think is wrong.