We would like to have our LabVIEW Operator Interface executable send data via a TestStand queue to a logging sequence. The SyncManager API sounds like a slick way to do this because it provides access to TS syncronization objects from other processes outside of TestStand. I created an experimental sequence to try out the concept. The sequence creates a queue with a TestStand Queue step, enqueues an item with another TS queue step, then uses ActiveX calls into the SyncManager API to add another item to the queue. That all works.
When I added a LabVIEW VI to enqueue another item via similar ActiveX calls into the SyncManager API, the VI does not get a valid reference to the queue and so it can't enqueue the item.
I read on the forum that the TS queue name needs to start with * in order to be accessed by separate processes on the same machine. When I prepend a * on my queue name, the TS queue steps continue to work, but the step that uses an ActiveX call into the SyncManager API to get a reference to the queue returns a null ref so the following ActiveX enqueue step returns an error. Plus the LabVIEW VI still doesn't get a valid reference to the queue either.
Ideas and suggestions welcome! The sequence and LabVIEW VI are attached. Using LV and TS 2012, got similar results in 2013SP1 .
Solved! Go to Solution.
I see what the problem is with your sequence. It's a bit subtle, but the problem is that you incorrectly have the "Create Object" checkbox checked on both the "Get Sync Manager Ref" and "Get Queue Ref" steps. Uncheck the "Create Object" ActiveX adapter setting on both of these steps and then your sequence works as expected. The problem with the "Create Object" setting is that, rather than use the passed in reference to make the call, the ActiveX adapter is creating new objects and in the case of the SyncManager, it's creating a new in-process SyncManager, rather than using the out-of-process one you got from the Engine.GetSyncManager() call.
I think your VI has a similar problem, where you are unnecessarily using an Automation Open node. I think you should just be using the wire returned from VariantToData node directly instead. Using Automation Open is similar to doing the "Create Object" checkbox in the automation adapter and would similarly give you the wrong version of the SyncManager.
Hope this helps,
Thank you very much dug9000. I unchecked the Create Object box in the sequence step adapter settings and disabled the Automation Open node in the VI. Now the sequence ActiveX steps can get a valid queue ref for a queue named "*TestQueue" and can enqueue an item. Yay! The VI gets now gets a valid reference to the queue and can get the numbers of items on the queue. Yay! But, I have not been able to get the VI to successfully enqueue an item. I tried both passing the sequence context and a null sequence context to the IQueue Enqueue method, but no luck either way. The updated zip file is attached. More help would be greatly appreciated!
The Enqueue API is expecting a PropertyObject not a string for the newElementPropObj parameter (not sure why LabVIEW's even letting you wire up a string). To create such a new PropertyObject you can do something equivalent to the following:
myProperty = engine.NewPropertyObject(PropValType_String, false, "", 0);
myProperty.SetValString("", 0, theActualString);
// enqueue it.
Close the ref to myProperty after you are done with it (i.e. after enqueuing it) to avoid a leak.
Thank you Doug! When I added the LabVIEW equivalent of your CVI property object statements, the VI can enqueue an item and subsequent TestStand steps can see that item.
See attached zip with the working VI and test seqeunce.
Next task for me is to incorporate this into or custom LabVIEW OI and TestStand test sequence and verify it works with an exe. I'm now confident it will.
Thanks again Doug. You are the Sync Manager Man!
Our GUI code is too big to post with many VIs and callbacks. We use the ALOHA framework and that is tied into our GUI as well. Sorry to take so long to post and sorry to not be very helpful on this.