ActiveX automation with classid for Freemaster

[afacotti]

Hi all,

I'm trying to control a NXP Freemaster application inside a VI;

this application exposes an ActiveX class with a defined classid, and I can access it through web browser with this example code:

<object style="WIDTH: 0px; HEIGHT: 0px; " id="pcm" name="pcm" 
classid="CLSID:48A185F1-FFDB-11D3-80E3-00C04F176153">
</object>											

<label id="lbltipAddedComment">test</label>
<script>
  document.getElementById('lbltipAddedComment').innerHTML = pcm.GetAppVersion();
</script>

In Labview I've created an Automation refnum but i cannot find the right class as above.

Is there a way to declare the classid for an Automation refnum?

Thanks,

agostino

[afacotti]

Hi all,

I think I resolved the issue in this way using Labview 2015 32bit (with 64bit version gives errors):

right-click on Automation ref, selecting "Select ActiveX class -> Browse" and than "Browse"; now select the exe file "pcmaster.exe" and magically you'll see the class MCB.PCM wanted.

I've tested it using Automation open and then a GetAppVersion method and works as expected.

Regards,

agostino

[Labview_Junckie]

Hi, afacotti,

Thank you very much for your sharing. Would you mind to share your vi at this thread,too? I met the same problem on getting data from freemaster. I hope I could learn from your code.

[cbutcher]

If by the same problem you mean errors in 64-bit (or not being able to find the control in the Browse menu) it will presumably be because the ActiveX control is only installed in 32-bit (and quite possibly only available in 32-bit).

Running in 32-bit LabVIEW is your only choice in that case (assuming you can't get hold of the source code for the ActiveX control and compile your own...)

[rolfk]

The problem that you can't find it in the Browse dialog is probably because they don't register it as an ActiveX Automation object despite implementing a full ActiveX server. Instead they only register the ClassID, which is not enough for an ActiveX control.

If LabVIEW would also list every object that is registered by classID only, the browse dialog would be completely unusable, it already is almost impossible to find a specific ActiveX Server in the existing dialog.

Possibly the pcmaster.exe exposes a registration API so that you could register it properly through

regsrv32 pcmaster.exe

but that is not guaranteed.

I doubt you can get its source code unless you work for NXP. 🙂

And recompiling it to work as 64 bit process might be quite a challenge too!

[afacotti]

Hi Labview_Junckie,

sorry for the one-month delay but I'm been busy with VI corruption (but this is another topic 🙂 )

I attach a sample project that work for me: a simple variable read from target;

there are still a couple of notes:

- if the read don't work maybe the VI lost the correct ActiveX link; as a workaround I add an ActiveX Invoke node and select "pcmaster.exe" as in my first post; You'll see other invoke nodes correcting their layout; than delete the added invoke node. I don't know why really...

- this VI rely on communication stack of Freemaster, so first thing to do is manually open Freemaster and open communication; if communication is ok here it will be ok in VIs

I hope this helps,

agostino

[Labview_Junckie]

Hi, agostino,

Thank you so much for your help! The VIs are very helpful and impressive. Previously I was using the ActiveX of MSHTML to read the data of FreeMaster, which failed to work.

Although there was error "Errore nell'apertura/chiusura della porta" in the OpenCommPort.vi, but I believe I will figure the solution out later.

[afacotti]

Yes, you're right: there is still some initialization issue (eg. if freemaster has comm port already open an error is thrown)...

The best and most difficult way I think will be to implement the entire Freemaster protocol inside Labview but exploiting its ActiveX control hides most of the dirty work exchanging data (and let you use any communication plugin already implemented in FMSTR)

Regards,

agostino

[afacotti]

Thanks rolfk,

I tried executing the command you said but Windows than complains that there isn't a correct entry point and that probably it is not a DLL (right!)...

Regards,

a.

[rolfk]

---

@afacotti wrote:

Thanks rolfk,

I tried executing the command you said but Windows than complains that there isn't a correct entry point and that probably it is not a DLL (right!)...

---

In that case the DLL does not implement a registration interface. That could be intentional because it is part of a larger whole and never was meant to be used independently or it could be because of lazyness of the programmer.