I have a rather peculiar problem I'm running into with using a COM library from a company to read proprietary binary files. I'm not very familiar with this type of Labview programming, I just followed their examples and experimented, a lot. I have talked for hours with the software engineer at the company who provides the "FSCOM Server" as they call it (Orbit F/R) and he can't figure out what is going on either. His expertise is not in Labview, but in text-based languages (I had to explain how to wire things in Labview over the phone).
I use this FSCOM to read the contents of antenna pattern files stored in a binary format (frustrating). Everything works fine and as expected after weeks of experimenting and direction from Orbit. The problem is when I shut down Labview completely and open the code in a brand new instance, I run it on a data file and It errors out with "The server threw an exception." The weird part is nothing has changed from when it worked 30 seconds ago when I was programming it before I shut down Labview. The way to get it working again? Delete just 1 wire somewhere, anywhere then re-wire it. Now it works, everytime.
Does anyone that knows COM/ActiveX have any idea how I can get this to work so I can make it an executable to distribute to other workstations?
PS. It currently won't run in executable form, I've tried.
Can't really help you with this at the moment but looking at the diagram picture I notice several problems with references not being properly closed.
First of all I make it a rule to not close the parent reference before having closed any returned child references. ActiveX being reference counted objects should always take care about this themselves, but many ActiveX implementations have serious trouble with proper refcounting their objects so closing an object to early can have undesirable by effects. So I would not close the IFileSystem refnum before I'm done with all the rest.
When reading Calibration Data and Calibration Table you enumerate all the Items in the ICalDataList and ICalTableList but never close any of them but instead try to close the List object in every loop iteration. The Close for the list object should be outside of the loop and even outside of the case structure to attempt to close the object even if you have gotten an error somewhere.
In Read Comments/Documentation/Date you wire the ITestDescription refnum to three different property nodes and then try to close each of the three output refnums but they are all the same object so the second and third close will have to fail. You also close the IOFR949File refnum in that case and then try to close it again in the next case frame.
Last but not least, each of those case structures doing some operation should be really a subVI that you can call. That makes you diagram a lot cleaner and easier to view.
Thank you for the tips, like I said I'm new to ActiveX objects so it's good to know how to properly handle them. I was using the attached code as my example on how to use their COM server so anymore information on how to use them or if they were not following a "best practice" is welcome.
However, I don't think the closing references out of order explains this problem because when the code works, as in when I delete a wire and re-wire it, it works perfectly.
If I open it in a fresh Labview, it won't get past case structure "4" (Read Azimuth / Elevation Angles) as in it doesn't seem to successfully read the data file as that is the first bit that looks inside the actual file. This made me think its a file/COM server issue which is why I spent over an hour on the phone yesterday with the developer of this COM server and he actually re-created this problem. Sadly he couldn't figure out why it would work if you just played with the wires a bit first.
So this is why I'm here to see if there is anything blatently wrong with how I'm doing this according to Labview standards and not MatLab or some other languages' standards. I'm hoping that whenever you or someone else gets a minute to try my .vi's they will run into the same problem and can maybe direct from there.
It is a strange thing to have working code, but only if you change it first.
Also I know this would be a lot cleaner if the case structures were subvi's instead but I tried that when I first started programming this and couldn't get the reference of the COM Server to read out/read in correctly from on subvi to the next. I wired it up like I do any other vi and like so many NI drivers are out there, but it wouldn't work with this COM server and I just had to get it working so I moved on. I may revist the subvi aspect later after its built and working for everyone and just make it an update later to clean up the code a bit.
To try your VI, wouldn't we have to install the FSCOM server?
If so, there is no way, I would risk my work laptop on that.
Well, I don't know if you would have to install it. I did, but thats because Orbit sent it to us on a disc. I included the .DLL's that are the actual COM server so if you can call them without installing them I guess it might work. But I don't know if that would work as I don't really know how ActiveX stuff works. There is a "Redist" folder in the FSCOM folder that includes a ".msm" file but I don't know what that is or how to use it. Otherwise I guess just combing through my code and making sure I am doing everything correctly with the objects.
By installing Visual Studio and creating a project in one of the Visual Studio programming languages (Visual Basic, Visual C/C++). Most likely not C# as that was introduced with .Net.
If you want to create a component in LabVIEW instead, you can create .Net assemblies from LabVIEW code, but no ActiveX components.
.msm are Microsoft Installer merge modules.You can integrate them into your own application installer when using Install Shield or another compatible installer builder. They are not meant to be directly installed.
I'm pretty sure that the code as you have it, won't work properly with the several not properly closed object references. It's not necessarily the cause of your main problem, but I have seen much more strange correlatons between programming errors and seemingly unrelated runtime errors. At least the enumeration of your data properties is not likely to return more than one propertyy per list without erroring out.
Do you have any files about it? if you have ,please share with me.
Well, I'm not sure what you are asking for. It would anyhow be better to post your own topic instead of attaching your cause to a fairly unrelated thread. If your question is about creating .Net assemblies in LabVIEW then then the online help in LabVIEW has a section named "Building a .NET Interop Assembly (Windows)" that explains the steps to do it. It does however assume that you do know what an assembly is and how its functions can be called.