How can I talk to an instrument using DCOM?

[dhfx]

I need to be able to talk to an Agilent 8363B/C PNA (vector network analyzer). Certain functions are remotely accessible only via DCOM. What is the best way to do DCOM function calls from within CVI?

Yes, I did do a search, and saw a lot of posts here that mention DCOM, but I can't tell what's relevant. Thanks in advance for any helpful replies.

David Friedman

Sr. Principal Engr.

Symtx, Inc.

Austin, TX

[dhfx]

(Continuation to my previous post)

Result of research on the Agilent site:  A file  "pnaproxy.exe"  is provided on the local drive of the instrument. When copied to a networked PC and executed, this file registers a type library (.tlb) and proxy stub (.dll) on the PC.  The next step is to create an ActiveX server in CVI as a wrapper around the COM object (presumably referring to the .tlb and .dll registered by "pnaproxy.exe").

I downloaded the NI document "Building ActiveX Servers in LabWindows/CVI" which gives a good explanation of ActiveX but seems oriented toward coding new servers. It's not clear to me how to use the CVI ActiveX tools to build a server as a wrapper around an existing object.

Also (pardon my ignorance) it's not clear to me how to call the ActiveX server in CVI. Any help with these points would be appreciated.

David Friedman

Sr. Principal Engr.

Symtx, Inc.

Austin, TX

[JumperBones]

David, I knew the day would soon come when the LMSTAR's PNA would need to step away from its GPIB interface and enjoy the full-features and speed of its DCOM interface!

This is actually very easy to do (I've done it before at BAE in Nashua for JSF's in-process MIPLRC tester, before some old-timer said he wanted to use GPIB instead).  However, only do this if you are allowed to temporarily install CVI on the Agilent PNA (in eval mode).  Here is a procedure that I am conjuring up off the top of my head (I did this back in 2004, so I'm going from memory).

Rip an ISO of the CVI CD-ROM (many CD ripping tools can do this. I use the Open-Source "ImgBurn", it is free).  Put it somewhere on a network share file system.  Put the PNA on the same network (ideally, on another port on the same network switch) so it can see that network share.  Install a tool on the PNA to mount the ISO to a drive letter on its file system (I use Slysoft's Virtual CloneDrive, it is proprietary but there is no cost).  Mount the ISO to a drive letter on the PNA.  Install CVI with minimal features (don't need them).

Now launch CVI.  Under the Tools menu select "Create ActiveX Controller...".  (Note: the word "ActiveX" is Microsoft's marketing-speak for DCOM, but the acronym DCOM, or the word "automation" are actually more accurate names for it).

When the ActiveX Controller Wizard window appears, hit "Next" to get to the list of ActiveX servers that are currently installed on the PNA's Windows operating system.  By the way, if you want to learn how to do this stuff before you go play on the PNA, you can first experiment with CVI's ActiveX Controller Wizard on a separate Windows platform, and test it out with some other application (for example, Excel 2003).  It is basically the same.

On the list of ActiveX servers in the Wizard (these appear because they have been "registered" in the Windows registry, either as part of the operating system, or from when these applications were originally installed), you will want to look for the items in that list that begin with the word "Agilent" and have the words "type library" in them.  Here is where I forget exactly what the PNA program's type library was called, and there may be multiple items in that list that begin with the word Agilent, so you might have to try more than one in order to figure out which one it really is if there is more than one in that list.

One thing is for certain, however.  The API that the CVI ActiveX Controller Wizard will display to you when you hit "Next" again must match the COM API that Agilent documents in their help file that is on the PNA.   That help file is in compiled HTML format, I think it was called pnahelp.chm, and I think Agilent puts in the C:\Windows directory.  You will want to copy that file off to a USB stick (or use your network share since you already got it hooked up) and use that on your desktop PC.  Poke into the help file's menu and look for the COM API documentation section.  There is also a very nice tree diagram of the PNA's COM API hierarchy in there as well (it is worth printing that out in the largest paper you can find).

One you have successfully  created your Agilent PNA instrument driver (you can uninstall the CVI evaluation from the PNA), and you will have a CVI function panel along with a header file and source file.  Essentially, this C source code contains all the "wrapper" functions that tap into each exposed method and property of the PNA's COM API.  Unfortunately, because the PNA is a very complex vector network analyzer, there are a multitude of C functions that represent every possible object-oriented path down to each of the PNA's API to each of its methods and properties.  So the C API you must use can get tedious as you descend down that API each time (and in some cases, obtaining object references along the way in order to descend deeper down still).  On some Agilent instruments, the path down this tree is so deep that when the CVI ActiveX Controller Wizard creates a function name for that unique path, it results in a name that is too long for the Wizard to handle, so you have to poke into the Wizard's Advanced Options on its "fourth" screen to hand-edit these names to something that will allow the Wizard to complete its job.  Adding to the tediousness is when you go to use this PNA DCOM instrument driver, because the fact is, ActiveX wants to talk in data types that might be quite foreign to you (SAFEARRAY, BSTR and VARIANT).  The legacy of ActiveX is tied to being binary agnostic to support software component development and interoperability between C/C++ and Visual Basic (and others), so you might have to do some reading to catch up, but it is worth it.  Here is one on the data types to get you started...

VARIANTs, SAFEARRAYs, and BSTRs, Oh My! 

When you use this COM API for the first time to talk to the instrument via DCOM, you will need to use the IP address or "handle" that you provided when you ran that "pnaproxy.exe" program that you pulled off the PNA on your test system controller.  You will need to use that handle when you attempt to "instantiate" the PNA application "over the wire" from your remote CVI program on the test system controller via the PNA COM API instrument driver that you just created from the ActiveX Controller Wizard.  Once you are successful at doing that, then you have to go from one object reference (to the PNA application itself) in order to get an object reference to the first item in the PNA API (I forget what that was, but it might have been a "measurement" object) and then to PAN the next object down (again, I'm guessing here) such as a "calibration" object.  Look at the PNA COM API tree diagram to help you here, which is why you should print it out very large...

At this point, if you have never done any COM programming from CVI, the best advice I can tell you is that you would do well to read and truly understand the CVI samples for ActiveX, such as the ones that they provide for Excel.  For example, the object references in Excel go from the Excel application object (or course) to a workbook object (your XLS file) to a worksheet object (a tabbed page in your workbook) before you can even think about what to do about the contents of any one cell or a cell range on that worksheet object.

Hope this helped,

JB

[JumperBones]

I hit the submit on this posting a bit too soon: I wanted to say that the "pnaproxy.exe" that you are using now might be newer than what I used years ago.  So you might want to try pointing the CVI IDE's ActiveX Controller Wizard that is on the PC system where you ran the pnaproxy.exe file from, and try locating the Agilent type library item that is in the Wizard's list.  In fact, I think you should try this first before you install the CVI IDE on the PNA (temporarily).  But I know I did it before the way I described, even though my memory is fuzzy on the details of how I did it.

JB

[dhfx]

JB: Thanks for the response. I don't have the PNA in-house, and the pnaproxy.exe that I have is a recent one that was provided to me for experimentation purposes by one of the responders on the Agilent forum, after I couldn't find it as a download on the Agilent site (this is because it's normally provided with the instrument, customized to the firmware version).

My understanding is that it should be possible to build the ActiveX server on the networked PC without the instrument being present, and that the instrument name can be entered later if not entered into pnaproxy.exe at time of installation; this is what I did, just left it blank. I now have the files 835xps.dll, 835x.tlb and fca.tlb in C:\Program Files\Common Files\Agilent\PNA\ on my local machine.

When I start the Wizard in CVI, it asks for the 4 file paths (specification, source, include, IDL) which it fills in with the project pathname suffixed with _axs, _axs.c, _axs.h, _axs.idl respectively. If I accept these and continue, the next screen asks for the server name and an optional .fp file import.

At what point do I aim it at the files installed by pnaproxy.exe? I believe the .dll is supposed to be a stub for building the server.

BTW, it's not LMStar, it's for a T/R module tester.

David Friedman

Sr. Principal Engr.

Symtx, Inc.

Austin, TX

[JumperBones]

First, call your Agilent sales engineer, get the pnaproxy.exe that will correspond to the PNA you will be getting soon.  The PNA's hardware/firmware and the "PNA application" that runs as an ActiveX (DCOM) automation server are potentially two separate entities.  The "PNA application" is the Windows application that runs on top of the enbedded Windows XP operating system that runs the instrument itself.  The pnaproxy.exe must match that application, and if I recall properly, is provided right there on the file system of the PNA instrument (probably somewhere under the "C:\Program Files\Agilent\yada-yada\...  location).  Your Agilent sales engineer has been making a lot of moola on Symtx because of the sales volume you represent, so this is an easy request to him or her.  Follow it up with the more difficult request of requesting a loaner PNA instrument of the same vintage that you are expecting on your loading dock...  Having a loaner in your possession will automatically answer a myriad of questions (and guesswork) that you would ultimately be fielding to this NI CVI forum or the Agilent ADN forum for all the weeks between now and when your PNA instrument arrives.

Second, you are using the WRONG wizard in CVI!   Maybe my previous two back-to-back postings were too long and you did not retain all of what they said (I got the same problem when talking with my wife, ya know), but you need to use the wizard that creates an ActiveX Controller that wraps around the PNA applications' ActiveX automation server that is RESIGTERED (via the Windows Registry) into the operating system you are writing the controller for.  So you need to use the "Create ActiveX Controller..." menu item under the Tools menu from the CVI IDE.  You inadvertantly used the other CVI Wizard that turns your CVI project into an ActiveX automation server.  Do not use that wizard for this solution.  Re-read my posting to note that I told you to use the "Tools>>Create ActiveX Controller..." menu item.  Re-read my previous two postings to understand why.

True, you will be able to "build the ActiveX server on the networked PC without the instrument being present".  This is because you are going to point the "Create ActiveX Controller..." wizard at the RESIGTERED application in the Windows registry on the external test system controller (networked PC), that appears in its registry right after you run the "pnaproxy.exe" program that you obtain.  However, unless you ignore to write error handling code for returned errors from the functions from the code that you eventually use from the wizard, then you will have errors until you stick an instrument in your system to communicate to...

The "controller" that the wizard creates is merely a hierarchical library of C functions (in source/header files, and leveraged into the CVI IDE via the FP file in order to support interactive execution, built-in function documentation, etc.) that allow you to tap into each of the "exposed methods and properties" of the PNA application.  You need to understand a bit about object oriented programming to know what those two terms mean, and how they fundamentally differ from functions and arguments.  I can recommend URLs on Wikipedia.org and MSDN, with or without targeted Google searches, to get to the meat of the technical information you need.  But ultimately, you have to want it, and have to want to make the time to absorb it.  When you do, you will finally see that CVI is tied tightly to the Windows SDK, which shields you from understanding COM/DCOM and .NET technology to a large extent, thanks to these ActiveX and .NET wizards that ship with the CVI IDE.

Even if you are just a hardware guy, you really would be doing yourself some good by doing some of this reading and then trying to understand object-oriented programming, and the how and why the progression of these COM/DCOM/.NET Windows programming architectures has advanced the way they did in the past two decades...  The short reason why is that in the 1980's, the world's academic computer science community forsaw that a new paradigm for all programming had to be created in order to economically support the ability of a small population of developers writing "tomorrow's" software solutions.  When these new oject oriented languages were introduced, it took time for them to get traction.  Later, when object-oriented principles were grafted onto the then-popular C programming language, the object-oriented momentum started building.  Microsoft just happned to be the big player at the time that was in the middle of it all as this object oriented paradigm took off, and of course they steered it in a Windows-centric manner.  If insead, Sun or IBM or HP was the big player, it would have turned out differently, don't you think?

Developing an ATE application that drives COM/DCOM components from CVI is a pain, but once in place, will run well in production.  Developing an ATE application that drives COM/DCOM from an object-oriented programming environment is of course much easier.  If you are an old-timer like me, you will have trouble unless your brain can morph itself to grasp the object-oreiented way of programming.   However, it is worth it, it is the way humans "think".  As an engineer, you probably think in C, but you got to temporarily flush out that "procedural" programming methodology of old languages such as C in order to get to the "ah-hah!" moment of understanding object-oriented programming.  COM/DCOM are binary agnostic packaging techniques for these kinds of software "components".  Example: think of Excel as a software component.  It is registered as a part of the Windows operating system.  Imagine that you could not drive it with a keyboard and mouse, and that you could only drive it from your CVI application.  Recall the object hierarchy I mentioned in my earlier post, and recall I recommened that you check out and understand the Excel ActiveX samples that ship with CVI.  If you do this task before you try to brute-force your way to talking with the PNA, you will be able to drive the PNA a lot easier than if you didn't...  And this task of just trying to get yourself set up to drive the PNA from CVI in the first place via the pnaproxy.exe installer would have gone a lot smoother as well..!

[dhfx]

Thanks again. I discovered by doing some more Web searches that the ActiveX Controller tool is the one I want to use. Tried it, and it found the registered Agilent stuff and built the instrument controller for me. Now at least I know how to do this part of the procedure.

David Friedman

Sr. Principal Engr.

Symtx, Inc.

Austin, TX