LabVIEW synchronization issue

[silvan.murer]

Hello all,

Currently I try to implement an application in LabVIEW (2015 SP1)

In this application I need some special synchronization. A 'central control loop' should be able to "trigger" and release other parts ('working sequences') in the application.

It would be possible, that in some cases the working sequence use and in some other sequences doesn't use this synchronization feature. The UID would also be change from time to time. So now the idea is, that a working sequence must register with a specific UID and then it would be able to wait for this UID... The wait call should also have a timeout...

Now I implemented a synchronization with a software-triggered timing source. But it isn't so stable. In some case the 'Stop Timed Structure' hangs and LabVIEW could finished the execution.

 Furthermore, when I try to stop the sequence without the 'Stop Timed Structure' but with the 'conditional terminal' in the timed loop, LabVIEW crash complete by the second cool of this loop (Sync_Wait.vi)

Does anyone have some idea why LabVIEW hangs or crash? Or has LabVIEW other synchronization concepts which supports something like this (whit out a polling..)?

By the way, all sources which are described could be found in the attachment... 

Thanks and greeting

Silvan

[Bob_Schor]

First, thank you for attaching the entire Zipped Project folder -- it provides all of the "pieces" and lets us see clearly what you are attempting to do.

So I'm looking at Sync_Test, which has two Working Sequences.  First problem -- you should learn to use a Simple State Machine (start LabVIEW, New Project, you'll find the Simple State Machine example on the right-hand pane) for these things.  You can put the "sequencing" right in there using a Wait function.

If you need more control, you can consider a Queued State Machine, with a separately-running Timer providing the "Next State" (or "Abort") information.  Using a State Machine will also allow you to get rid of the Local Variables for booleans 1 and 2 -- just put the Boolean on a Shift Register and wire the indicator to it.

I would recommend that you make the State Machine its own VI.  I notice you have two, that the functions that they call are PreAllocated Clones.  Well, you can still do that, but also make the State Machine VI a Clone, and "launch" it using Start Asynchronous Call.  What inside these Clones do you really need to "see" in your Caller?  If only a few indicators, you can pass in a Reference to the Indicator and set the Value of the Reference in the Clone using a Value Property.

While I'm making suggestions:

• Creating a LabVIEW Project urges you to create a Project-specific Icon for your VIs.  Use it, and use the template it creates (I'm assuming, here -- I always create my own Icons from my own templates) to make your VI's more self-documenting (see snippet of your code, below).
• Try to rarely, if ever, use the Sequence Structure.  NI removed the Stacked Sequence from the Structures Palette, but there are still die-hards who use even this crippled form ...
• Timed Structures are really designed for LabVIEW Real-Time, where there are hardware clocks that really do tick "regularly".  They should generally be avoided in programs that run on PCs under Windows.

Bob Schor 

[silvan.murer]

Hi Bob,

Many thanks for your fast and friendly replay.

I will give you some more information to the project and the goal of it.

In fact, the attached LabVIEW project is only a small part which shows you the issue which I have. In the full application I have state machines instead of the"working sequence" loops.

Also the central control loop would be a little bit different. On this place I have multiple (around 10) Hardware interfaces which includes some library calls (dll), socket communication or other interfaces to different hardware. Each hardware has his own loop and a queued state machine.

So now to the synchronization issue: The hardware loops accepts different commands from the "working sequence" loops. In some cases, the "working sequence" loop must wait until the command is finished. For this case, I would use the "Sync" VI's which are included in the attached project. 

Implement a polling in the "working sequence" isn't a solution for me because the sequence controls multiple hardware in parallel and in different states... A other problem by use a polling approach is the polling time. The sequence should be as quickly as possible...

With the implemented 'Sync' VIs I would create a library which do all the synchronization. The idea is, that I can create a software trigger which release all currently 'waiting' VIs. After the release, I would check the conditionals (Check Array entries) If all ok, I would exit the VI. If them not so, The VI should wait again until the next trigger is created or a timeout is occurred.

Now I can understand why LabVIEW hangs in the "Stop Timed Structure.vi"..? Is it possible, that the call hangs when a timeout occurred during the execution of previous code. So for example: In the "Sync_Wait.vi" in the "Normal" case, I loops trough the array (in the false case). Is it possible that the "Stop Timed Structure.vi" hangs when the timeout time arrived during the execution of the for loop? I can't understand this behavior.

Maybe someone knows a better implementation for a software trigger (with a timeout)? I'm not sure is the "Timed Structures" the correct implementation. Bob's opinion is, to use it only on LabVIEW Real-Time. In the NI documentation/help is written: "Requires: Base Development System (Real-Time, Windows)". So I think it's ok to use it in a windows application?

Maybe someone has experience with a similar synchronization solution? Or a other hint/idea?

Thanks

[Bob_Schor]

As Peter Parker's (Spiderman's) Uncle Ben once said, "With Great Power comes Great Responsibility".  LabVIEW's Data Flow model gives you Great Power in its ability to have multiple sections of code running independently and asynchronously, more-or-less simultaneously, but then you need to synchronize and coordinate these loops.

On the Block Diagram's Functions Palette, there is a section called "Synchronization".  The Queue is the best-known (and most familiar to me) of these tools, but the others have utility in helping with what I believe you are trying to do.  I haven't used them as much, but I recommend you look up the Help and maybe an Example or two of the others and see if any of them "clicks" with what you are trying to do.

Once you have an idea of a scheme that might work, I'd recommend that you build for yourself a small Test Project and try to implement your scheme.  If it works, great.  If it doesn't, you'll have something "small and clean" to bring back here and ask for specific help.

Bob Schor

[silvan.murer]

Hi Bob, 

Thanks for your replay.

Once you have an idea of a scheme that might work, I'd recommend that you build for yourself a small Test Project and try to implement your scheme.  If it works, great.  If it doesn't, you'll have something "small and clean" to bring back here and ask for specific help.

Ok, to my specific question:

Please find in my first post the "small and clean" project. It doesn't work fine. Sometime, the VI "Stop Timed Structure" blocks the hole application. It doesn't return from this VI and the LabVIEW process must be killed in the task manager. When I navigate into the block diagram, the VI is labeled with a green arrow. (See the picture in the attachment)

I found the VI in "Programming -> Structures -> Timed Structures -> Stop Timed Structure" 

My simple question is: Why can this VI call not return?

(I can't debug the Stop Timed Structure VI because its password protected)

Cheers

[bavci]

I have downloaded your project and had a look. I think you precisely are talking about the Sync_Wait.vi in your project as it is the only VI that contains "Stop Timed Structure.vi" if I am not mistaken 🙂

I could run this VI and it did not block anything; probably I did not have the full functionality. What do you exactly mean by "blocking the whole application"? Do you get any errors?

BTW, I am not sure whether it helps but if you search for "Aborting the Execution of a Timed Structure (Real-Time, Windows)", you will find a explanatory example.

Cheers,

Bart

[Bob_Schor]

---

@silvan.murer wrote:

Please find in my first post the "small and clean" project. It doesn't work fine.

---

Give me a clue -- what is the name of the "small and clean" project?  Are you referring to a specific VI, or the entire Project?

But that's almost besides the point.  My notion (which may very well be completely wrong) is that you don't need, and don't want, a Timed Loop to do whatever it is that you are trying to do.  Timed Loops work very well in LabVIEW RT systems, especially those having Hardware-timed clocks that really give you precise and accurate times.  Windows doesn't do that!

Can you explain what it is you are trying to do?  Is your timing related to hardware?  Is it purely software timing ("I want to do a calculation every 25 minutes")?  What are the starting, stopping, and timing criteria?  Can you describe a "small, simple project" (in words) that exemplifies what you want to achieve?

I must confess that looking at your code, I "don't get it".  Even reading the Documentation didn't help ...

Bob Schor

[bavci]

Absolutely agree with Bob on the necessity of Timed Loops. If you are not using a RT system you don't need them.

Cheers,

Bart

[silvan.murer]

Hi Bart,

Ok, thanks for your support.

The problem arose when multiple triggers was generated in a short sequence. (Fast clicking on the trigger button in the Test bench)

I did it now by using the .NET interface and a System library call which could handle the synchronization correctly.