Jump to content

Accesing COM child object


Recommended Posts

Hello,

 

I'm trying to use a library to interface some LVDT gauges from Marposs. It's implemented through COM objects and I have it working in Excel with VBA with this code:

 

Private Sub CommandButton1_Click()Dim oSmaoMain As SMAO.SMaoMainDim clsInfo As SMAO.InfoDim sInfo As String'Initialize the SMAOMain ObjectSet oSmaoMain = New SMAO.SMaoMainoSmaoMain.Initialize'List all the Installed DriversFor i = 1 To oSmaoMain.DriversCount   sInfo = sInfo & "Driver Name : " & oSmaoMain.Driver(i) & " " & oSmaoMain.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Installed Drivers"'List all the Enabled DriversSet clsInfo = oSmaoMain.InfosInfo = ""For i = 1 To clsInfo.DriversCount   sInfo = sInfo & "Driver Name : " & clsInfo.Driver(i) & " " & clsInfo.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Enabled Drivers"Set clsInfo = NothingSet oSmaoMain = NothingEnd Sub

When I port this code to LabVIEW I get answer from the SMAO.SMaoMain, correct initilization and even I can read the main objects properties. The problem comes when I try to access it's child object SMAO.SMaonMain.Info. When I get the reference and I make calls to the methods/properties, I get different results, always 0 drivers enabled.

 

I've attached the LabVIEW code I'm using and some captures of the creatable objects I can see from LabVIEW.

 

Any idea of what could be happening?

 

 

post-50325-0-37873600-1390386768_thumb.p

post-50325-0-98302700-1390386776.png

post-50325-0-98969700-1390386778.png

post-50325-0-11794200-1390386780.png

Link to comment
Hello,

 

I'm trying to use a library to interface some LVDT gauges from Marposs. It's implemented through COM objects and I have it working in Excel with VBA with this code:

 

Private Sub CommandButton1_Click()Dim oSmaoMain As SMAO.SMaoMainDim clsInfo As SMAO.InfoDim sInfo As String'Initialize the SMAOMain ObjectSet oSmaoMain = New SMAO.SMaoMainoSmaoMain.Initialize'List all the Installed DriversFor i = 1 To oSmaoMain.DriversCount   sInfo = sInfo & "Driver Name : " & oSmaoMain.Driver(i) & " " & oSmaoMain.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Installed Drivers"'List all the Enabled DriversSet clsInfo = oSmaoMain.InfosInfo = ""For i = 1 To clsInfo.DriversCount   sInfo = sInfo & "Driver Name : " & clsInfo.Driver(i) & " " & clsInfo.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Enabled Drivers"Set clsInfo = NothingSet oSmaoMain = NothingEnd Sub

When I port this code to LabVIEW I get answer from the SMAO.SMaoMain, correct initilization and even I can read the main objects properties. The problem comes when I try to access it's child object SMAO.SMaonMain.Info. When I get the reference and I make calls to the methods/properties, I get different results, always 0 drivers enabled.

 

I've attached the LabVIEW code I'm using and some captures of the creatable objects I can see from LabVIEW.

 

Any idea of what could be happening?

 

Well, the code you claim causes problems in LabVIEW is commented out in the VBA code. So are you sure it does anything else in VBA than in LabVIEW if you enable the code?

Link to comment

Looks to me like you close the ref to SMAOMain in parallel with the loop you use to try collect the Enabled Drivers info. Once you close that ref, your SMAOMain object gets cleaned up and you're likely looping on a closed ref to the SMAOMain.info property when you try to get the enabled drivers.

 

Mark

Link to comment
Looks to me like you close the ref to SMAOMain in parallel with the loop you use to try collect the Enabled Drivers info. Once you close that ref, your SMAOMain object gets cleaned up and you're likely looping on a closed ref to the SMAOMain.info property when you try to get the enabled drivers.

 

Mark

 

Shouldn't really happen, since the error cluster is wired through (at least it looks like it is, didn't check in the actual code).

Link to comment

Rolf,

 

On the attached picture, the ref wire from the _SmaoMain property node used to get the ref to the SmaoMain.Info property goes around the While loop where the Enabled Devices get queried  and into a Close Ref. There's no data dependency I see that would keep the Close from operating on the Initialized _SmaoMain object before the property of that object gets queried. If the object that contains the property data gets closed, wouldn't the data associated with that property likely get disposed as well? Am I missing something obvious?

 

Mark

Link to comment
Rolf,

 

On the attached picture, the ref wire from the _SmaoMain property node used to get the ref to the SmaoMain.Info property goes around the While loop where the Enabled Devices get queried  and into a Close Ref. There's no data dependency I see that would keep the Close from operating on the Initialized _SmaoMain object before the property of that object gets queried. If the object that contains the property data gets closed, wouldn't the data associated with that property likely get disposed as well? Am I missing something obvious?

 

Mark

 

 

The ref num goes around the loop but the error cluster goes through the loop and then to the two Close Refnum nodes. At least that is how it looks in the picture. Maybe the real wiring is behind the loop but that would be a major style fault. Unfortunately the VI Snippet resource seems to get lost between posting to LAVA and downloading it to my computer, so can't really check it.

  • Like 1
Link to comment
  • 3 weeks later...

After some time trying still stuck with this, even NI support couldn't give me a solution, probably the COM object isn't fully ActiveX compliant or compatible with LabVIEW implementation of ActiveX... I'm going to make a wrapper DLL in C++ that handles the COM calls and pass data into LabVIEW, but I've never done it before and I'm struggling to make it work.

Link to comment
  • 9 months later...

Hello,

 

finally I got the solution to my problem but I didn't post it here, so I do now to help anyone that could encounter this problem. I'm not sure if the COM object is non-thread safe, but the fact is that if I mark the VI to run in UI thread everything goes smooth...

 

Regards.

 

Well the COM automation server should have been installed with a setting that specifies what threading model it is happy with. LabVIEW honors that setting. The common threading models that are available in COM would be:

 

- single threading, this component can only be called from the main thread of the application that loaded the component. The LabVIEW UI thread coincidentally also is its main thread.

- apartment threading, this component can be called from any thread but during the lifetime of any object it must be always the same thread

- free threading, the component is fully threading safe and can be called from any thread at any time in any combination

 

Most Automation servers require apartment threading, often not so much because it is required than simply because it is the default and many developers are to lazy to verify if their component would run with a less restrictive threading and more serious, if their component might actually require a more restrictive threading model.

Link to comment
  • 3 years later...
On 1/22/2014 at 4:04 PM, FJ_Sanchez said:

Hello,

 

I'm trying to use a library to interface some LVDT gauges from Marposs. It's implemented through COM objects and I have it working in Excel with VBA with this code:

 


Private Sub CommandButton1_Click()Dim oSmaoMain As SMAO.SMaoMainDim clsInfo As SMAO.InfoDim sInfo As String'Initialize the SMAOMain ObjectSet oSmaoMain = New SMAO.SMaoMainoSmaoMain.Initialize'List all the Installed DriversFor i = 1 To oSmaoMain.DriversCount   sInfo = sInfo & "Driver Name : " & oSmaoMain.Driver(i) & " " & oSmaoMain.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Installed Drivers"'List all the Enabled DriversSet clsInfo = oSmaoMain.InfosInfo = ""For i = 1 To clsInfo.DriversCount   sInfo = sInfo & "Driver Name : " & clsInfo.Driver(i) & " " & clsInfo.DriverDesc(i) & vbNewLineNextMsgBox sInfo, vbOKOnly, "Enabled Drivers"Set clsInfo = NothingSet oSmaoMain = NothingEnd Sub

When I port this code to LabVIEW I get answer from the SMAO.SMaoMain, correct initilization and even I can read the main objects properties. The problem comes when I try to access it's child object SMAO.SMaonMain.Info. When I get the reference and I make calls to the methods/properties, I get different results, always 0 drivers enabled.

 

I've attached the LabVIEW code I'm using and some captures of the creatable objects I can see from LabVIEW.

 

Any idea of what could be happening?

 

 

TestMarposs.png

Creatable_objects.PNG

Creatable_objects_smaoinfo.PNG

Creatable_objects_smaomain.PNG

can you please upload this library and vis

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.