modelsupport2.dll labview parallel model

[bilby42]

Software: Teststand 4.1, Labview 8.5
Process Model: Parallel

I've been searching all the posts re replacing modelsupport2.dll with a Labview equivalent - without success.

I too want a dialog that shows all the socket serial number entries on one common form (like modelsupport2 does), but want some extra functionality that doesn't come with the default modelsupport2. I don't have the cvi compiler to change the original modelsupport2.dll code, so want to make a labview replacement. This appears quite complex due to the thread synchronisation between executions for the parallel model.

The two usual alternatives appear to be...
1/ Add serial number entry dialogs to the user interface code...... I definitely don't want to do this as I want the same serial number behaviour when using the sequence editor. This also goes against the recommendations in the "Best Practices for TS UserInterface Dev" whitepaper.

2/ Use a concept similar to that shown in the "OverrideSerialNumForParallelModel.seq" found on the NI website. Unfortunately this launches a new dialog box for each parallel execution, i.e. if you have four parallel executions running, four separate serial number entry dialogs popup (launched by the preuut and postuut callbacks).

I'm thinking of a third method that behaves like modelsupport2, but uses a Labview replacement. It would work like this....

3a/ Build a Labview VI that has a custom UI Message handler. Also add the ability to read/write teststand globals using the Teststand API GetProperty/SetProperty VIs, and the "TerminationMonitor" subvi so your VI knows when to shutdown.

3b/ Add any special functionality to your vi by placing code when your custom events fire, i.e. use the TS UI vis to modify global variables inside Teststand engine to set flags, statuses, statevars etc.

3c/ Set ParallelModel_ShowUUTDlg=false in your ModelOptions callback to disable modelsupport2 from popping up and ruining everything!!!

3d/ At the start of parallel testing when creating all your instrument handles etc, launch your new vi in a separate execution. The vi will then sit in its event loop waiting for custom UIMessages to fire. Using events here means no polling is required, hence the vi should be light on cpu resources but won't miss any requests from the process model.

3e/ Modify the PreUUT and PostUUT callbacks in your parallel process model to post custom user events to your waiting vi's event loop. I've picked these model callbacks because they will run during the "serial number entry" and "result display periods" for each socket respectively. The custom messages could be things like "WaitingForBarcodeEntry", "SocketPassed", "SocketFailed", "DisableThisSocket" etc.


So...... that's what I'm going to try. My approach gives me complete control of the serialnumber entry/result display on a single form (note that this complexity isn't required for the batch model). Has anyone attempted this approach and does it work????????

I'm hoping someone has achieved something similar so I don't waste hours trying a flawed concept.

Regards,
Tom

[Dennis_Knutson]

I would like to see the same thing. In a couple of weeks, I'm going to start to convert the CVI code to LabVIEW. I don't know how much actual code I'll be able to share though since a lot will be proprietary.

[jsiegel]

Tom,

I think I am wanting to do the same thing.  It seems like you want to put all (or most) of the UI functionality into the process model (as part of the serial number display).  If I can do that, then I wouldn't even need a regular UI, since I just want the operator to run a program that starts the Test UUTs execution and quits when the execution is complete.  The client sequence files will be selected automatically based on the serial numbers.  I'm surprised that I haven't been able to find examples of this.

The parallel process model synchronizes UUT executions with the SN interface from modelsupport2.dll via TS queues.  Why not keep that infrastructure in the sequence and create a LabVIEW VI that writes to the queues, rather than writing to TS variables?  This would adhere to the structure of the original process model a little better, and you could leave ParallelModel_ShowUUTDlg alone (and continue to use it as it was originally defined).  You will need to replace calls to the Dll with equivalent VIs to communicate with the SN VI, probably like you say in 3e, but I think you wouldn't need to use UIMessages--perhaps a LV queue or notifier.

I don't know if you want this or not, but I think I would want each test socket to display sequence execution information, such as the current step.  This is where an Application Manager event handler (including a UIMessage handler) and ExecutionView Managers would be necessary.  But I'm not quite sure that these managers work well within code modules rather than in an external UI.  Anyone else have any opinions?

[bilby42]

Hi jsiegel,

Re using a LV queue or notifier instead of using TS variables. Good suggestion. I haven't yet tried to share the same named queue between TS and LV, but from your comments it appears you have used this method successfully. Its probably more elegant than using station globals.

I'm still intending to use the OI and sequence editor to display the sequence execution information. My s/n interface VI is just an attempt to combine all the sockets statuses togther in one place (rather than having them all jump up in separate forms like modelsupport2.dll does, and to have a common display mechanism for both seq. editor and operator Int. modes.

There's a similar discussion going on in this thread......

http://forums.ni.com/ni/board/message?board.id=330&message.id=16026&query.id=452852

Appears lots of people have need to change the default parallel behaviour of modelsupport2.dll.

Tom

[bilby42]

Hi jsiegel,

Sounds like you have more experience sending notifications and queues between TS and LV than I do, but of interest here are two very informative "devzone" articles I've found......

Using TestStand Queues in Labview
http://zone.ni.com/devzone/cda/epd/p/id/5108

Using TestStand Notifiers within Labview
http://zone.ni.com/devzone/cda/epd/p/id/5111

Regards,
Tom

[jsiegel]

I actually haven't really used TestStand notifications and queues within LabVIEW, but I did see those links, and they  (along with this link: http://forums.ni.com/ni/board/message?board.id=330&message.id=11906#M11906) convinced me that it's easily doable.

One of my suggestions was to have your LabVIEW replacement for the modelsupport2.dll SN dialog put messages on a TestStand queue in order to basically duplicate the DLL dialog's behavior.  But there are other calls to modelsupport2.dll in the parallel process model that configure the SN dialog.  My other suggestion was to have the VIs that replace the other DLL calls communicate to the LabVIEW SN dialog VI via LabVIEW queues (not TestStand queues).  You had proposed in your earlier post to have a custom UI Message handler--I had thought you meant TestStand UIMessages, but I think you were probably referring to messages to the UI in a more general sense, and LabVIEW queues are a good way to implement such a message handler.

By the way, there have been a few other threads discussing replacing modelsupport2.dll with LabVIEW, but I assume you have seen them.

[bilby42]

Hi Jsiegel,
The link you gave was posted by "paulmw" who appears to have built something similar to our requirement.

One of his earlier comments said its easy to get messages in the direction TS -> LV by using UI messages and events, but it was harder to go back the other way LV -> TS. He had used the Synchronisation manager for this direction with queues and notifications (hence the graphics in your link). Maybe we could used queues and notifications for both directions?

Re my earlier posts, yes I had intended to use custom UI messages from TS -> LV.

Regarding the other calls to modelsupport2.dll, I assume these are all disabled when you set ParallelModel_ShowUUTDlg=false in ModelOptions. Hence any functionality that's missing will be added to your new LV code - in your case your custom OI, and in my case my combined system status/barcode display panel. I'm still intending to make the status/barcode entry via a separate VI and leave the OI pretty much the standard out of box "Operator Mode". That way everything will behave in the same manner when I used the sequence editor mode.

I've also been searching for anything on modelsupport2.dll, and it appears everyone either puts up with it as is or modifies it using CVI. For now I'm going to get more familiar with the LV callback event structure, and the Synchronisation manager before I design my final topology.

Good luck,
Regards Tom

[jsiegel]

I agree that the best way to send messages from a LV UI to TS is probably via a TS queue or notifier. The recommended way to send data from TS to the OI (external to TS and code modules) is via UIMessages.  But I think communication between one TS step to another should not be done with UIMessages.  That's where you should use a queue or notifier.  I'm not sure if it is considered good practice to have a UIMessage handler in a code module, or to even use Manager controls in a code module (see http://forums.ni.com/ni/board/message?board.id=330&thread.id=22358).
 
Even if you set ParallelModel_ShowUUTDlg=false, you will still need a way to communicate back to your status/barcode entry VI from various locations in the process model (e.g., to tell it that it should send a new SN).  In the parallel process model, that "communication" occurs via calls to different functions in the DLL.  What I was suggesting is that you keep ParallelModel_ShowUUTDlg set to true, and replace each DLL function call with a VI call that sends a different message to the status/barcode entry VI.  Each VI call would send a message (via, say, a LV queue) to the status/barcode entry VI.  The messaging mechanism could be completely encapsulated in LV--no TS messaging mechanism necessary.  However, the status/barcode entry VI would still have to put commands on a TS queue, because that is the parallel process model mechanism in the ProcessDialogRequests sequence expects to receive commands.

The dialog in modelsupport2.dll basically puts commands on the TS queue in response to button pushes, and updates its display based on the states of the testsocket executions.  It seems like it wouldn't be too difficult to create an equivalent in LV.  But then again, I'd have thought that someone would have done this already.

[bilby42]

Hi Jsiegel,

Maybe I'm trying to oversimplify things but...

Re your comment "Even if you set ParallelModel_ShowUUTDlg=false, you will still need a way to communicate back to your status/barcode entry VI from various locations in the process model (e.g., to tell it that it should send a new SN)."

The only two places I was going to communicate the s/n and status entry points to my new VI was in the PreUUT and PostUUT callbacks. Effectively all I'm doing is combining all the individual "popup" s/n dialogs in the example "overrideSerialNumForParallelModels.seq" with a single combined VI.

I'm still using the standard operator interface vi unmodified.

When I searched the parallel model for modelsupport2.dll I found 18 distinct call points. Some of these are disabled with a precondition when you set ParallelModel_ShowUUTDlg=false. The others I was going to leave as is, i.e. some just collect the report options etc.

I need to rethink where I'm going incase I've missed a crucial point. I do however get your point about calling a custom VI which in turn does all its communication to the custom s/n entry form via LV queues completely encapsulated in LV - sounds quite elegant.

[bilby42]

Hi again Jsiegel,

I've been searching though the parallel process model for all the modelsupport2.dll calls, and I get your point. There are lots of things in the standard modelsupport2.dll form that my simplistic approach would miss out. i.e. indicating the run conditions etc.

The NI "overrideSerialNumForParallelModels.seq" basic approach would only signal my s/n vi at the PreUUT and PostUUT callbacks. Events happening at other points would be missed.

Guess I have to get more conversant with modelsupport2.dll.