Not sure if this should go in the TestStand or Labview board, so I'll try TestStand first...... I'm building a TestStand test rig that's using the Parallel process model. I want to replace the standard uut dialogue with a custom dialogue built using Labview (as an aside, the test rig requirement needs custom barcode entry screens). I have a working system now. Basically I set the TestStand ModelOptions parameter "ParallelModel_ShowUUTDlg=False", and interact with my own Labview UUT Dialogue in the PreUUT and PostUUT callbacks. I send data from TestStand>>Labview using wrapper vis around standard Labview sychronisation objects. These work lightning fast! The main issue was how to cleanly get information from my Labview UUTDialogue (barcodes and control tags etc), back into each TestStand parallel execution, i,e. Labview>>TestStand. I have successfully done this by connecting to the Synchronisation Manager and Enqueueing my messages to the relevant TestStand execution. I've attached my Labview VI that does this task. This works but my only issue is the speed of the Enqueue call (specifically the IQueue.Enqueue invoke node). This single steps takes about 1 second to execute each time. I've tried setting the "processMsgs" parameter to true but this doesn't help. Calling the invoke nodes to the NewPropertyObject, the SynchManager and the GetQueue are fast. Only the Enqueue invoke node is slow. Everything else seems to work as expected - all data structures pass into the TestStand parallel executions as intended. Any ideas why the Enqueue is so slow? Regards,Tom

Tom, That's an interesting discovery. I've seen a few references to global queues (with the asterisk) performing more slowly than local, but hadn't seen any mentions of THAT slow. Glad that you at least have found a workaround. I was initially thinking you were right, that LabVIEW and TestStand would be running in different processes, but I believe that's only true if you've configured the LabVIEW adapter to run in the Development environment. I think, if you're running the adapter in the run-time engine, then it's actually an instance of the RTE opened in the TestStand process. See the TestStand help here: http://zone.ni.com/reference/en-XX/help/373892E-01/tssemiconductor/performancelvrte/ "The TestStand LabVIEW Adapter can execute VI code modules in the LabVIEW development system process or in the TestStand process using the LabVIEW Run-Time Engine (RTE)" And in this white paper: http://www.ni.com/white-paper/14335/en/ "By default, all VIs are called in the main application instance of the LabVIEW Run-Time Engine module loaded by the TestStand process" So, IF you've configured your adapter to the RTE, then I think ti makes sense that you're able to access the queue without the asterisk. Of course, if you're running in the dev engine, then I would imagine you'd have to use a global queue. Hope this helps! Cason Applications Engr., NI

NI TestStand

SyncManager Enqueue in Labview

Solved!

Author

Hi Cason,

Just been reading the white paper in your last link http://www.ni.com/white-paper/14335/en/.

It appears to explain the general issues, although I need to study it further to gain a full understanding.

Regards,

Tom

Message 11 of 11

(1,203 Views)

NI TestStand

SyncManager Enqueue in Labview

Re: SyncManager Enqueue in Labview