Replacing modelsupport2.dll with LabVIEW

[EJS]

Hi,

I am presently developing a user interface using LabVIEW 8.2 and TestStand 4.0.  I would like to incorporate the functions of the modelsupport2.dll for the parallel model in my custom user interface using LabVIEW.  The program will be handling 4 UUTs simultaneously with optional bar code SN entry.  I do not have CVI and wonder if anyone has done this before or if there is any documentation to this dll that I can access for me to use to develop my program.

Thanks,

Eric

[~jiggawax~]

Hey Eric,

I'm trying to figure out why you need the modelsupport2.dll for your user interface?  The modelsupport2.dll is primarily used for the process models that ship wtih TestStand.  I'm not aware of much documentation on the modelsupport2.dll but you are correct in assuming you do have the source code for it. 

I assume that when you say program you are talking about your custom process model?  If so then you can simply make function calls to the modelsupport2.dll the same way they do in the default process models.  All of this is located in C:\Program Files\National Instruments\TestStand 4.0\Components\NI\Models\TestStandModels   I recommend copying everything from the C:\Program Files\National Instruments\TestStand 4.0\Components\NI to the C:\Program Files\National Instruments\TestStand 4.0\Components\User folder and working from that one.  If you didn't know already then the way TestStand works is it looks in the User folder first and if it doesn't find it there then it goes to the NI folder.  You'll see this hierarchy scattered through the TS folder.  The reason they do this is so that customizations can go in the User folder and then you still have all the native stuff in the NI folder. 

Even though the modelsupport2.dll was written in CVI you can still call it from wherever you want.  A CVI runtime engine is installed on your machine when you install TS.  This is necessary because otherwise the process model wouldn't run.  Therefore you are able to use the modelsupport2.dll from any language.  If you want to customize it then you have to have an ANSI C editor and compiler.  Of LabVIEW is your choice of programming language then you can create your own dlls, vis, whatever and call those from your process model using the LabVIEW adapter. 

I guess it really comes down to understanding what you want and how to get there.  The user interface does not use the modelsupport2.dll.  It simply calls into the TestStand engine and executes your sequences by calling the process model.  When you are developing your user interface are you editing one located here: C:\Program Files\National Instruments\TestStand 4.0\UserInterfaces\NI  Again you should copy to the User folder and edit the one in the User folder.

Hope this helps.  Please let me know if I am not on the right path.

[EJS]

Sam,

I understand how the user interface works and how TestStand works.  What I wish to do is incorporate much of the functionality of the modelsupport2.dll into my custom user interface written with LabVIEW.  The dll cleanly handles multiple threads for a parallel model starting, stopping, terminating, entering new Serial Numbers for UTTs, etc.  I wish to be careful writing my code to imitate these functions.  Not handling these threads correctly could lead to unexpected results.

I hope this gives you a better understanding of my request.

Eric

[~jiggawax~]

Let me see if I understand correctly then.  You want your user interface to call functions from the modelsupport2.dll?  What is your user interface doing that it needs the modelsupport2.dll functionality? 

You want to rewrite the modelsupport2.dll in LabVIEW? 

I'm really having a hard time wrapping my head around what you are saying.  All of the multithreading is handled by the process model which calls the modelsupport2.dll.  So why are you doing multithreading in your user interface? 

Here's what I understand:

You are creating a custom User Interface written in LabVIEW. You want to mimic functions in the modelsupport2.dll in your custom user interface and skip the process model altogether.

If this is true then why not just call the modelsupport2.dll from labview using the LabVIEW native library calls?  You can call C dlls from labview directly.

Sorry if I'm missing the picture here but I've never seen an application quite like that.  Sounds very interesting though.

Let me know if that's correct,

[Dennis_Knutson]

I have replaced some of the functions in modelsupport2 with LabVIEW code. For example, I wanted a slightly different serial number entry for the batch model. The way I did this though, was to use a PreBatch callback in my sequence. It's also quite easy to replace some of the calls to modelsupport2 in the process models. I did this in the PostUUT callback to display different Pass/Fail banners. Is this the sort of thing you are thinking of doing?

[dowNow]

IForgive me if I'm misunderstanding the approach here. The standard way to run four UUTs in parallel is use the batch or parallel process model. Generally the OI should be a very thin application that is used to start and stop executions and view execution progress. You should be able to run your sequences from both the Sequence Editor and your custom OI in (almost) the same way. Will you be able to do this with what you have in mind? Putting too much extra code into the OI application bypasses native TestStand components, thus the application will be less portable, scalable, and more difficult to develop and maintain.

[paulmw]

EJS,

I understand what you are trying to do.  I have took the same path in making an OI for the parallel process model with only two test sockets running.

The thing I wanted (and I think you want the same) was the modelsupport2.dll dialog popup for executing a parallel execution is a bit inconvenient that it is not part of the OI.  I also wanted a window that traced multiple executions at the same time.  The modelsupport dialog only give a basic status and you had to go to the OI and switch between executions to see the tracing.

What I did was to disable the modelsupport calls all together an made a custom OI with two exection view managers.

The task was not simple.  I also had the UUT serial number entry as part of the OI.  That lead to challenges in getting the serial number from OI to the running sequence in the test socket. 

I also had the same concerns as dowNow, in that I didn't want to require my sequence to only be compatible with this OI.  What I did there was create a UI message that would return a made up "OI Version" string.  This return value would only exist in my OI.  If it didn't detect my OI then I ran with the default modelsupport2.dll dialog.

I have considered creating a scalable version of a parallel OI but I will probably never get around to it unless my company needs one.

In this thread I posted a version of the two socket OI I once created.  You can also get a description of how it worked by reading the thread.

Paul

[dowNow]

Paul's post is ringing a bell for me. If in fact the parallel dialog is getting in the way, creating your own parallel process model is easier than you would think from looking at the TestStand default parallel model. In fact, most of the complexity in the parallel model is notifiers and synch stuff that handles that big dialog. I made a pm once that had four sockets and it was a sequence with about five or six steps. It fired up four sockets or less at startup and they each had their own SN prompt dialogs. It used the technique of nested execution entry points. You could use it with any OI. I guess it all depends on your requirements, let me know if you'd like to check out the 4 socket pm seq.

[EJS]

Paul,

You have a lot of good ideas.  I am relooking at what I wish to accomplish and what is really necessary from the user interface.  I believe I can simplify my request.

For my parallel model, can someone show me how to initiate each of my 4 sockets individually and terminate them individually from within my operator interface.  I will handle SN entry, stopping and starting tests, etc. through local variables.  Once the socket terminates, that socket will restart, requesting a new SN. 

All 4 sockets will remain independent until I enter a Terminate all and Exit.  These I know how to do.

Thanks for your help.

EJS

[Paul.Boucher]

I know this is an old thread, but it's the one I found while trying to do the same thing as the original poster.   in TestStand 2014 the above suggestions are overly complicated.

Based on some unit tests I did this is all you need to do:

• Override PreBatch -
  •  Display a UI to let the operator enter SN and batch info
  • optional Set Parameters.ModelData.BatchSerialNumber
  • Set Parameters.ModelData.ContinueTesting - Set to false when operator is done (clicks cancel)
  • Set Parameters.ModelData.TestSockets[0].Disabled - True will stop this socket from running but does not affect other sockets
  • store serial numbers in Parameters.ModelData.TestSockets[0].UUT.SerialNumber
• Override PostBatch
  • Display Pass Fail Results  from Parameters.ModelData.TestSockets[0].MainSequenceResults

There are other things you can set or get but this seems to be the minimum