LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Array Of Clusters Not Initializing or Possible Race Conditions

Solved!
Go to solution

Hi all,

 

I've been working on a fairly complex project for work, and I haven't worked with Labview before. Unfortunately nobody in my office really has experience with it so I'm on my own. I've mostly got the project working, and it might be a little cumbersome, but if it works that's fine.

 

Essentially it's a temperature control device and I made it so it's expandable, thus the clusters and arrays everywhere.

 

My question is this. I've got an array of clusters indicating the status of all the plates in the system. When I start up the VI for the first time they do not initialize. They just stay grey, but when I stop it and start it once, it will work every time. I think this is kind of strange behavior. I've heard of race conditions and while I've tried to make sure t hat's not happening, it might be without me noticing.

 

I've tried putting an initialize array block in the first call while loop and that doesn't do anything, and if I remove the initializer from the shift register in the top while loop that stops them being initalized altogether.

 

I guess I was hoping someone might have an idea what's causing it, or could possible give my code the once over. The main bulk of it is in the very top of the code, but there are a lot of smaller events taking care of GUI type stuff.

 

I've included all source code. It might be a little much but I didn't want to start pulling it apart if I don't know what's happening.

 

Thanks in advance.

 

Chris.

0 Kudos
Message 1 of 16
(2,853 Views)

From your description this isn't a race condition, it's a failure to initialize something properly.  When you initialize an array on the front panel, are you initializing it with an empty array, or an array with actual elements defined?

 

There's really no way for anyone to help you easily from the information you provided.  You uploaded three different zip files, two that have the same name but different file sizes, with no indication of which one to download nor which VI demonstrates the behavior you described.

 

As a quick style note, generally you would put your comments in text boxes, not in string constants.

0 Kudos
Message 2 of 16
(2,849 Views)

Thanks,

 

I think I saw the string boxes in some code somewhere and just went with it. Sorry to upload everything. I'll just put up the main VI and let you take a look at it.

 

 

0 Kudos
Message 3 of 16
(2,824 Views)

Hi Chris,

 

you have created a huge block diagram - that is no compliment...

 

For the first you should collapse all your while loops serving just one event case into one loop with one event structure serving all events! That way you could use shift registers to hold values instead of a lot of locals (reducing risk of race conditions).

 

Then you can re-attach your VI (don't forget the cleanup button)...

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 4 of 16
(2,819 Views)

So just to confirm, I can have one event structure with say 10 events happening? In this case could an event happen simultaneously with another? I thought I read something about each event having it's own event structure and while loop to make sure this works out.

 

Also, again, to confirm what I think I already know. When the event completes it outputs whatever data you output from the structure and then you can place it in a shift register. Where does this go until the next event takes place?

0 Kudos
Message 5 of 16
(2,815 Views)

@Chris Johnson wrote:

So just to confirm, I can have one event structure with say 10 events happening? In this case could an event happen simultaneously with another? I thought I read something about each event having it's own event structure and while loop to make sure this works out.


Each event case must complete before it can handle the next event, but many events will complete so quickly that this is not an issue (such as your "pause chart" button).  In general you should have only one event loop.  If you expect an event to take a long time to process, use a queue to hand that task off to another dedicated-purpose loop, so that the event structure can go back to waiting.  This is one example of the producer-consumer structure often mentioned on this forum: the producer is the loop containing the event structure, and it queues (produces) items to process.  A separate loop dequeues (consumes) those items and handles them appropriately.

 

As GerdW mentioned, you have race conditions all over the place.  You'll never know whether the Plate Info Cluster Array is properly updated because it's being written and read simultaneously in so many places.  I'm assuming that is also where you're seeing the issue that inspired the post, and, in fact, one of those race conditions could explain what you're seeing.


Chris Johnson wrote:

Also, again, to confirm what I think I already know. When the event completes it outputs whatever data you output from the structure and then you can place it in a shift register. Where does this go until the next event takes place?


I don't understand what you're asking.  Where does what go until the next event?  If by this you mean the data in the shift register - it stays in the shift register, accessible at the corresponding terminal on the left side of the loop.

Message 6 of 16
(2,785 Views)

OK, thanks. The more pointers I can get the better.

 

The reason it's so messy is that I wrote it one way and it worked nicely, but I was told to build in future proofing and I didn't have much time, therefore a nightmare of code from an amateur. If it's not too much trouble to everyone, I'll make the changes and then post it back up here later on today and see if it's getting closer to standard code style.

0 Kudos
Message 7 of 16
(2,780 Views)

Chris.

 

You have a major codeing flaw that will cause some bad things to happen in this code (And might be why you see what you are seeing).

 

EVERY one of your loops is an infinate loop.  so the only way to stop your program is to hit the ABORT button.  This is very much like stopping your car by running into a tree.  The program does stop but there are consequences.  The Abort button is a debug tool and should never be the only means of stopping vi execution.


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 16
(2,762 Views)

I guess I understand why that would be, but I'm creating an application whose users I don't want to give access to stopping the program. In this case should I have a stop button present?

0 Kudos
Message 9 of 16
(2,760 Views)

Hey again everyone,

 

So, I've tried to make some of the changes that have been suggested but I think my code still looks very cumbersome. Has anyone got any more ideas on how to simply clean it up. Or maybe there are some glaring style errors.

 

Any pointers would be appreciated.

 

Thanks again.

0 Kudos
Message 10 of 16
(2,748 Views)