Provide API to TestStand/LabView - advice needed

[tonyzheng]

Hello,

I am a developer to collect shop floor data, and I need to create an API to TestStand/LabView. The API will receive from TestStand/LabView an XML string which carries the UUT serial number, test result and measurement data etc. The API will be used as an enterprise-wise standard by all test engineers in my company.

Here are a few questions I want to ask. Thanks in advance for any help -:)

1). I can choose between Visual C++ (to produce an unmanaged DLL), or C# (to produce a .NET Assesmbly on .NET 2.0 or 3.5). From NI's point of view, do these options provide the same power and flexibility? What will be the trade-off?

2). For multi-threading situation, do I need to handle thread safety inside API myself, or I can just develop my code as if it would be called by a single thread?

3). Is there any special requirement for the API? For example, do I need to expose it as a COM or ActiveX DLL?

Thanks and Regards,

Tony

[Snowman 6008]

Hey Tony,

I'm assuming that you are trying to create
this API so that it can be called from within TestStandor LabVIEW. If
that is correct, then whether you use C++ or C# is simply a matter of what you
are more comfortable with, however, you will want to be aware of the
following caveats with each option.

For C++ please see the following link:

https://www.ni.com/docs/en-US/bundle/teststand/page/exporting-class-methods-and-functions-in-micr.ht... 

For C# please see the following links:

https://www.ni.com/docs/en-US/bundle/teststand/page/net-adapter.html

 It is best to handle thread safety from within your API Tool, since it
will be difficult to handle that externally, with the possibility of
multiple instances of the TestStand Engine or multiple LabVIEW VIs.

 There is no special requirement for the API tool, both TestStand and LabVIEW have the ability to call c/C++ DLLs and .NET assemblies so you will not necessarily need to expose the API via COM or ActiveX

Message Edited by Richard S. on 03-06-2009 09:32 AM

[Jervin Justin]

Hi Tony,

I'm not sure what you mean by creating an API to TestStand. Typically creating an API refers to creating an abstraction layer over something low level, so that other people can use your interface to communicate to the low level layer.

However, you mention that your API will receive data from TestStand and/or LabVIEW. Does this mean that TestStand and/or LabVIEW will call your API, which will then call some low level code? Or do you mean that you will provide an abstraction layer over TestStand and/or LabVIEW so that other people can call your API to talk to TestStand/LabVIEW?

Can you please explain the architecture to us? Its hard to make a recommendation (especially for question 3) without it.

As far as VC++ vs. .NET, for the most part, as Richard mentioned, it comes down to personal preference. I personally prefer C# because its based on .NET, while many others at NI prefer VC++ because of its efficiency. We don't really have a recommendation over all as far as power and flexibility.

Thanks!

[tonyzheng]

Hi Richard and Jervin,

Thanks for your reply. This has been very helpful.

To explain to Jervin, by "API", I mean that TestStand and/or LabVIEW will call my API, which will then connect to some database via ODBC

or ADO.NET. In our facilities, test engineers will import the API into their LabView environment. They will pass the measurements to the API, and

the API then pass the measurement data (which are formatted as XML) to remote database. We later run report script to calculate yields etc.

Now I understand TS or LV can import both .NET assemblies and native C++ Win32 DLL. I guess native code will be more efficient under

TS/LV because TS / LV will be able to avoid interoperability issues. TS / LV are not .NET application, but native application, correct?

Thanks and Regards,

Tony