Wait on Asynchronous Call - why so long?

[CoastalMaineBird]

In the previous system, which used this same idea, the memory usage would go up and down, as the window opened and closed.

I changed this back so that the CONTAINER window used a RUN VI method (I had switched it to CALL AND COLLECT) and now the memory usage comes and goes, as I would expect.

However, when I take out the 5-sec wait, the rise tiime and fall times increase (this is the "walking thru sludge" experience):

I can see how it might affect the rise time, if the blocks are running at the start, they are competing for CPU resources with the launch of every other block.

But I don't see how that affects the fall time...

[Kevin_Price]

---

@Yamaeda wrote:

If you only want to wait for all processes it sounds like a Rendevous to me. The event and counter works ofcourse also and basically do the same thing.

/Y

---

Just wanted to highlight and repeat this comment from Yamaeda that seemed to get overlooked in the midst of the other in-depth conversation.  Nice thing about using a Rendezvous is the ability to wait & then release without the need for polling a count value.

-Kevin P

[CoastalMaineBird]

Well, after a fresh CPU restart, with the dummy WAIT removed, and using RUN VI instead of CALL AND COLLECT, it seems to be stable and reasonable:

Mem usage settles down to a repeatable value when the container window is UP and when it is DOWN.

The CALL and COLLECT was doeing something to me - I verified that I was collecting, but memory was not being released.

[CoastalMaineBird]

Thanks, Kevin.  I am going to look at RENDEZVOUS as a way of verifying that all instances have quit.

I am also going to look at using a single REFNUM and hatching 72 copies of the VI from that refnum, rather than making 72 refnums as I am now.

[CoastalMaineBird]

I am going to look at RENDEZVOUS as a way of verifying that all instances have quit.

Well, that was quick.  If you look inside the RENDEZVOUS code, it turns out that it's all dealt with as queues. It's not a separate primitive type.

They typecast a QUEUE refnum to / from a RENDEZVOUS refnum and deal with queues from there.  

I think I'll stick with polling a queue for empty, to determine when all are finished.

[CoastalMaineBird]

Looks like the origiinal RUN VI method is the best way.

I tried using the static VI ref directly into the INSERT VI method

--- It works on the first block, but gives "ERROR 1105 - VI ALREADY IN ANOTHER SUBPANEL" on all other blocks.

I tried opening a reference with option 0x08 and using the single ref in the INSERT VI method

--- It works on the first block, but gives "ERROR 1105 - VI ALREADY IN ANOTHER SUBPANEL" on all other blocks.

I tried opening a reference with option 0x40 and using that single ref into the INSERT VI method

--- "ERROR 1591 - 0x40 option not valid with this VI"

I don't know why - the block VI is already saved as REENTRANT.  Always has been.

So, I'm back to the original scheme.