09-26-2014 07:16 AM
I just want to creat an OCX control with Labview.The function of it is to get much date with the RS232 string and show it with text files according to the type.
09-26-2014 07:28 AM - edited 09-26-2014 07:34 AM
An OCX control is an ActiveX control or automation interface server. LabVIEW can only import ActiveX interfaces but not create them. What you can do in LabVIEW is creating a .Net assembly from within a project. The end effect is similar to an ActiveX automation server but using .Net instead (and requiring any possible client to access it through .Net and not ActiveX).
Also note that unlike a real .Net assmbly where the code is usually .Net bytecode and therefore platform agnostic, LabVIEW .Net assemblies contain the compiled assembly code from the original VI which is always CPU specific and just creates thin .Net wrappers to call that compiled code. As such a LabVIEW .Net assembly is only callable from applications that have the same CPU architecture as the LabVIEW version that was used. That means you end up with seperate assemblies for both x86 and x64 architecture which you have to create seperately in the according LabVIEW version if you want to support both architectures for other applications.
09-26-2014 07:49 AM
First of all,thank you very much.In your opinion i can't creat an OCX control with Labview and just creat a .Net assembly whose effect is similar to an ocx control,does it right?
09-26-2014 08:34 AM
I guess I'll have to figure that out when I get to it about using the .msm file to install FSCOM with this programin an installer.
I have updated the code with your reference close recommendations (I hope I got them right this time). What you are saying makes sense about closing the child before the parent, etc. I was just experimenting and seeing what works for me but I'd rather have it programmatically correct (If it's worth doing, it's worth doing right).
I am still getting the error I intially explained, however. I attached some pictures of what I mean.
Jamie
10-01-2014 11:13 AM
Is anybody willing to help me debug my problem? I'm at a loss. This COM works fine in visual basic but labview has issues with it.
Jamie
10-01-2014 12:32 PM
@kornyguy06 wrote:
Is anybody willing to help me debug my problem? I'm at a loss. This COM works fine in visual basic but labview has issues with it.
Jamie
They provided the LabVIEW sample VI.
They need to figure out why it doesn't work.
Otherwise, I'd return the equipment.
10-01-2014 01:04 PM
@nyc_(is_out_of_here) wrote:
They provided the LabVIEW sample VI.They need to figure out why it doesn't work.
Otherwise, I'd return the equipment.
This is true but there isn't any labview people there to figure it out and its not that easy to return an installed 20+ year old tapered antenna chamber with 15 year old equipment. It'd be easier for me to write completely new software to run the chamber and save it in a format I want rather then to return it
I don't believe the problem resides in the COM library as it works reliably in MatLab (tried today) and Visual Basic. It works perfectly in Labview too, AFTER I change the code so I can't see how its a problem with the COM.
Jamie
10-01-2014 01:10 PM
I would take the VI that sorta works and either remove everything to bare essentials and then start adding in pieces until it stops working or remove piece by piece until it works every time.
Or you can compare the VB.NET code that works to the LabVIEW VI.
I'd pay special attention to the connect and disconnect portions.
10-01-2014 01:47 PM - edited 10-01-2014 02:07 PM
@kornyguy06 wrote:
I don't believe the problem resides in the COM library as it works reliably in MatLab (tried today) and Visual Basic. It works perfectly in Labview too, AFTER I change the code so I can't see how its a problem with the COM.
Jamie
Well, that edit causes LabVIEW to recompile the VI and that also can cause the ActiveX DLL to be reloaded.
One clue is the error code that you get (-2147417851) which in Hex is 0x80010105. The 8 indicates an error (surprise) the 001 indicates that it is from the RPC (Remote Procedure Call) subsystem and 0105 is the error code. Much in ActiveX internal operations works through RPC so it seems that when your ActiveX component tries to read the file it somehow runs into some RPC hickup. Suspects here could be that the ActiveX component relies on other DLLs (ActiveX components that it doesn't automatically find and then throws an error.
This is definitely an issue in the ActiveX component itself or the way you installed it on your computer. Have you tried to copy ALL the files that belong to the driver into the same directory as your LabVIEW project file and then reassign the ActiveX class in the main refnum to the according ActiveX DLL that you placed in that directory?