Issue creating plug-in for executable which utilizes FieldPoint Drivers

[Redrabbit]

In my code I pass in the path for my hardware class (which utilizes FieldPoint Drivers) to the "Generic Create" method  in order to dynamically load the class into my executable.  When I do this in a development environment there are no issues, also, if I pass in a hardware class which uses no FieldPoint drivers there is no issue.  It appears as if when utilizing the fieldpoint drivers within the class it causes the class to break (the error from the Generic Create method is "G#: The blahblahblah is not idle or reentrant and could not be executed!", this is probably because it is coming back as "bad" from the VI state.  I've been able to recreate the issue somewhat with new "launcher" executable which acts similar to the generic create but allows me to load the FP of the class I'm launching.  When I do this with this particular class the FP comes back with a broken arrow and when I press it I get a 22A8 error (no idea what this is or what it means).  Any ideas would be appreciated, I've been banging my head on this the last couple of days.

Thanks,

Randy

Edit:  After further review, classes using mxDaq drivers have the same issue however anything utilizing serial drivers does not seem to be affected.

[Mattias_Ericsson]

Hi Randy,

Yes, these problems are really annoying. I must admit it was a long time since I worked with FieldPoint. I don't actuall think this is a G# specific problem, but rather a LabVIEW issue, but I would like you to check a few things. I've seen similar problems using LabVIEW classes, working perfectly in LabVIEW development, but not in runtime, even when there are no "dirty dots" in the code. Even mass compile didn't help. However, it seems sometimes, that VIs need to be forced recompiled and resave. This solve my issues.

I have a list of things I would like you to try:

1) Force a recompile of the Create VIs that you try to load dynamically. Open the VI, press "CTRL + <run button>" and the VI will be recompile and you get a "dirty dot" and then resave. There is a shortcut that will force all VIs in memory to be recompile, but I am not sure about the combination, perhaps "CTRL+ALT+<run button>"?, I know that it was another key to be pressed as well. Maybe anyone reading this knows?

2) Be absolutly sure that you will include the VI that is going to be loaded dynamically and that the frontpanel of that VI is included. I seems from you question above that you have already check this though.

3) I would actually recommend you to use the "Generic Default Constructor" instead over "Generic Create". There is a G# example called: "G# - DependencyInjectionUsingDefaultConstructor.vi". This will use a different technic of dynamic loading the VI and one major difference is that this VI will not be executed as "run top level", but instead as "running" (just as any sub VI). This will have hugh effect on e.g. LabVIEWs internal garbage collector.

If a VI is executed as "run top level", all resources created (queuese, VISA sessions etc.)  by this VI will be garbage collected by LabVIEW when this VIs stops executing, this is not the case when a VI executes as "running". This is usually the way you would like a dynamic VI to be executed. However, in order to make this work, you must override and implement the "G#Object_Create.vi" method in your subclass, that "wraps" the ordinary constructor of the class, to the more generic connector pane of the "G#Object_Create.vi". If you have a very complex structure you might end up setting you ordninary constructor as "reentrant". I always use the "Generic Default Constuctor" over the "Generic Create".

By the way, which LabVIEW version and OS are you using?

Hope this helps,

Mattias

[Redrabbit]

Mattias,

Thanks for the quick response.  As you suggested, it does appear to be something native to Labview, I've posted on the main board as well (http://forums.ni.com/t5/LabVIEW/Get-LV-Class-Default-Value-Error-1498/td-p/1129973).  I tried the recompile to no avail, I also tried again (and in the example posted on the discussion on the main board) to load the various vis into the executable.  I also tried implementing the Generic Default Constructor (I could have sworn that I tried using this when I originally designed the code, months ago, and ran into issues but it seems to work fine now) however it did not clear up my issue.  At this point I'm sure the problem isn't with G# but with LVOOP (or perhaps something I'm doing with the implementation).  If you want to check out the example I posted at the link above just to see if there is anything obvious I'm missing I'd appreciate it but thanks for your help thus far.

Randy

P.S.  Labview 2010SP1 and XP

[Mattias_Ericsson]

Hi Randy,

I did check your example and I did just a minor modification in your build specification to get it to work. I used your "PluginWithObjects" and just modified this slightly. In this example, you set "Always include" on the two classes, this is the correct way, but in the "Source Files Settings" tab in the build specification, I also set the "Destination" of the two dynamic plugin classes to "Support Directory" instead of "Plugin.exe", else you doesn't get a ".lvclass" path that can be used. Rebuilding this works for me. Just select the .lvclass file that appears in the /data folder of your build.

I attach your example again, where I had added the new build specification at the end.

Mattias

[Redrabbit]

As was alluded to in previous posts, the root of this issue was the location of the plugins in relation to the compiled code.  The final issue that I needed to resolve to fix the problem I was seeing with my application was that the plugins were associated with libraries (I had done this to try and organize the code).  I needed to break them out from the libraries for path associations to work in the compiled code (along with the items mentioned by Mattias above).