Is there a way to detect if Excel is busy?

[metzler]

I have a VI that is testing three products at the same time, and writing data to three different excel spreadsheets.  If more than one subvi is writing to Excel at the same time, I get an error.  Is there a way to detect if Excel is busy, and wait until it is not busy?

[Lucither]

Is the error fatal or can you trap this error and use this as your indication? 

[metzler]

It does show an error - I guess the easiest way is detecting the error on inside the state machine and re-inserting the type definition state inside the queue. 

Is there a way to insert a type definition at the front of the queue?

[RavensFan]

Enqueue element at opposite end function.

[Kristoff2]

metzler,

You could use semifphores to ensure that only one test is written at a time.  Please let us know if this is not an option for you.

Regards,

Sam K

Applications Engineer

National Instruments

[Been bitten by LabVIEW]

Do not VIs still block if you try to call the same VI from a different thread if that VI is not reentrant?  Or has that changed from 7.0?

If they still block, then you just make ONE interface VI that does the writing to Excel and then use that VI everywhere in your code.  This will not work for a multi processed application, but for a single process app, this will work very well as the semaphores are implied, safer (you will not inadvertently manipulate the semaphore incorrectly) and is a no brainier as you should be using centralised code anyway for easier maintenance.

A

[LV_Pro]

Been bitten's suggestion is similar to what I was to suggest, encapsulate the Excel stuff in an Action Engine, then only one can write at a time, the others are blocked (momentarily) until the action is complete.

[metzler]

Been bitten...

I had thought of this, but I have multiple state machines - one for each product under test.  I don't know how to implement this with the multiple state machines.

[metzler]

Sammy K:

I like the idea of using a semiphore, but I don't know how I could do it.

Currently, my VI is only testing one product.  I will copy my state machine and Daq while loop twice to test three products (I have done this before and it worked out, but I only copied it once.)  Previously I handled Excel busy problems using a time delay in one loop, since both were usually started at the same time.  This not the case now, and more data needs to be written. Each of my state machines will have a Write to Excel state, but I need only one of these to be active at a time. 

Would a global variable be better, into a case structure, which would delay the writing until the global variables went low, but I would need to wrap that in a while loop to repeat until Excel was free - I guess that's okay.

Anyone have any other suggestions?

[mikeporter]

The correct answer is the one that Putnam (and others) suggested: Encapsulate all the logic to perform a single write into a VI that is used wherever you need to write to an Excel file. This structure will guarantee that the code will only be writing to Excel from one place at a time.

If you don't want to have the different sections of the code waiting for their turn to come up, a variation on the theme would be to create a separate stanalone process that does nothing but write to Excel files. The rest of the code would pass it the data to be written using a queue. With this approach everybody seems to write at the same time, but the standalone process is actually serializing the Excel operations. This approach could even be extended to include the ability to read from files, but that is as they say, "...left as an exercise for the reader..."

Mike...