Plug-in Architecture using Packed Project Libraries (lvlibp)

[mike_nrao]

Features

Plug-ins:

  1. Abide by a specified interface.

  2. Are independent of each other.

  3. Don’t result in name-conflicts when used in a built application.

  4. Installation is independent of main application installation.

Main Application:

   1. Is extensible without code modification to main application.

   2. Depends only on plug-in interface, not on specific plug-ins.

   3. Loads plugins dynamically.

   4. May utilizes plug-ins as UI elements or OO Design Pattern such as Strategy or Command.

   5. Requires no modification to successfully run in development or run-time environment.

   6. Installation is independent of plug-in installation.

Instructions

• Download the PowerPoint presentation to follow step-by-step how to create a plug-in architecture using packed project libraries. 
• Download 'PluginArchitecture_2011.zip' to get the source code created in the demonstration. 

The download is available for LabVIEW 2011.  If you want it in a previous version, follow the steps in the presentation to implement it yourself.

I'm interested in receiving community feedback, so please comment or ask questions.

Comments

In response to questions about displaying plug-ins in a sub-panel and communicating with message queues, I attached a version that does this in the simplest manner I can imagine:

• Communication mechanism is string messages using front panel control value change events.
• Plug-ins are given a reference to the sub-panel so they insert themselves and run using Asynchronous Call-And-Forget.
• "Exit" message (sent automatically on Panel Close event), signals the plug-in to safely end execution.

[dsavir]

Jpina wrote:

                       

Hi Danielle,

Reading your problem I couldnt tell what is happening but it sounds to me as if you were trying to use in you 5th plug in something that is already in memory and that causes the crash.

Keep in mind that this architecure uses the factory pattern and that LabVIEW cannot kill the clashes that you load, so the reamin in memory (there is a VI shot chapter about this) and that LabVIEW keeps its items in memory till you close all. It my happen that you are having a conflict fo this reason...

I pass you this link where Elijah talks a bit more about this architecture and gives some handy tips.

http://ekerry.wordpress.com/2013/12/07/the-nuances-of-deploying-plugins-in-labvi ew/#comments

                   

Hi Jpina,

Thanks for the link. I did think of this option, but as I said the only things that the new plugin used is stuff already used by two or more plugins – utility VIs to create a folder with the current date and time, for example. This is standard in almost all of my plugins. There was no VI used by this plugin and only one more plugin (at least not one that I put on the block diagram). I added a framework plugin to my plugins project just to for testing, and it uses the utility Vis etc and causes no problems.

My plugins trigger measurements in various instruments, using a simple framework that loads the plugins and triggers the measurements at the correct time. I thought at first that the problem might be with the specific instrument, but I couldn't debug the problem without running the code J

After moving it to a separate project, I could run the code without crashes and debug the other problems there were. Perhaps now that there are no bugs in the plugin I can try and move it back and see if it works…

Danielle

[Jpina]

This is more of an FYI note than a question for the group, but this issue made me work quite hard for some time and I thought it was interesting to share it with all of you.

I am loading my plug-ins in a supanel and I pass the plug-in class using the invoke node "control value -> Set" . From this plug in I load 2 VIs in the mentioned subpanel.

My surprise was that for any reason I could load the first VI without problems, but when I tried to load the second for some reason, I reaceived the error 91 constantly telling me that LV could not pass the plug-in class to this VI. After trying everything to find out what was the reason I decided to build the plug-in step by step to find out what caused the error. Surprisingly, the reason of this problem was that I was using a Polymorphic VI to drive the enqueue action of a queue in my plug-in and I forgot to untick the "Remove unsused Polymorphic instances" when I was building my PPL.

I still don't understand the reason why if I don't add a VI that I am actually not using in my plug-in the PPL crasses, but I thought it was nice to share this issue whit you all.

Sumarising, if you are using a Polymorphic VI in your plug-in, I would recommend you to add all the instaces of it!

I hope this helps

[elisita1991]

Hi!

I have this error

what is the solution?

I see the solution, but I don't understand, please explain in detail.

Note: http://digital.ni.com/public.nsf/allkb/10F1D411ACBAD3D9862572FF0064C801

[vishots.com]

I can answer this. You are trying to launch VIPM, to install a package correct? VIPM was compiled with SSE optimizations enabled and cannot run on your machine CPU. We (JKI) will be releasing a patch for this soon. I'm sorry.

[elisita1991]

ok. Thank you

I hope you can help me with this problem soon

[Jpina]

Hey all,

I will ask this here, because I do not know where else I could do it.

I was trying a packed library today, where I had a conditional disable structure based on the run time engine, surprisingly the condition Run Time Engine == True within the packed library did not seem to work. Is that a expected behaviour?

I mean, a packed library is compiled code, so shouldn't that condition be true after you build the library?

[TimBotsM]

I'm not 100% shure if this will solve your problem but I'm using this VI to check if I'm in runtime.

At the moment i'm not able to check it against my actual code but if I recall correctly this works OK.

[shew82]

I got caught by a similar one the other month: a Packed Library had a conditional disable based on runtime engine. This was then used in a built application but the runtime engine case did not occur. I'm presuming that it's because when the packed library is built it is not necessarily for the runtime engine. Then, when an application using the packed library is built, the packed library is not changed (by design), leaving the structure as false.

The workaround is as TimBotsM correctly showed just now: use the Application property node "Application.Kind" and a case strucure. It means that your code does not get compiled out, but for the most part will achieve the same result.

[Jpina]

Tim,

That looks like what I did to solve the problem . Thank you.

My question though was more conceptual than looking for a solution. I would like to understand why is this happening.

shew82 wrote:

                       

I'm presuming that it's because when the packed library is built it is not necessarily for the runtime engine. Then, when an application using the packed library is built, the packed library is not changed (by design), leaving the structure as false.       

Not sure of if I understood this part. As I see it, a packed library is a piece of compiled code, which means that it should be using the run time engine to run. Don't you think so?

[BrianGShea@NGC]

I believe the case is, LVLIBPs contain compiled code, the conditional structures are not evaluated at execution time but rahter at compile time. And since at compile time the runtime engine is not true this case get discarded in the compiled code. Only the case that is true at compliation gets included.

My rule of thumb is to not use conditional disables in Packed Project Libraries because they are evaluated based on the values of the variables at the time of build. This can lead to confusion about what code is being executed.

Remember, PPL's are like DLL's they are compiled code only.

(I'm not sure how coditional disable work with debugging enabled)

[James_McN]

Certainly I would expect the conditional symbols to be evaluated and compiled out at build time but the run time engine one is interesting because in an exe the code is not under the run time engine.

The exe build must have a special case for the run time symbol and compile for run time since that is the only environment it will run under. A PPL however could be run under either run-time engine or as part of the development environment. Since the conditional structures compile out I guess there is no (current) way for them to handle this case well.

[Jpina]

James,

Thank you, that was a good explanation

[TimBotsM]

Just a quick note to make the plug-ins a bit better.

A new feature in LV2014 during build is "Exclude dependent packed libraries". (see: here).

Using this checkbox for the plug-ins removes the need for the post-build action. (also, the post-build action seems to be broken in LV2014)

[jon_mcbee]

This seems like a good place to ask this question, has anyone built a tool for visualizing dependencies between PPLs (vi.lib, other PPLs, classes...) and automating the PPL build/test process?  I am working on building one now but definitely don't want to reinvent the wheel if it's already out there.

[tyk007]

TimBotsM wrote:

                       

(also, the post-build action seems to be broken in LV2014)

                   

Don't know if this helps but the Post-build still works for me in the f1 patch.

[jlokanis]

Amiri wrote:

                       

AristosQueue wrote:

As hard as this sequence of steps is, even harder is the steps needed to build the plugin architecture when the code is already written without that in mind -- i.e., there's one project with the application, a parent class that isn't in its own library, and a bunch of already written child classes that are successfully doing dynamic loading. Making the conversion at that point is more complicated -- something I've tried to do a time or two and always botched. It's really important to have the end design in mind when writing the original code. It is my hope that in the years to come LV gets some better tools for making that transition (that really is a hope, not a backward way of saying anything like that is in the pipeliine; I don't know the roadmap for the packed project library features).

                   

AristosQueue,

What you describe above is exactly the situation that I am in and would appreciate any suggestions/advice.  How would you suggest going about this transition (especially since you said that in the past you have seen lots of difficulties with this process)?

Right now, we have a newly developed plugin architecture and we did not anticipate these types of challenges with creating successful EXE builds, thus we did not plan for this.  However, at the moment, this seems to be about the best option for creating EXE’s that allow for: 1) leveraging the power of the plugin architecture and 2) keeping the build file structure clean and we would like to once again start creating EXE builds.

As you mentioned, I do hope better tools come out soon for managing this, please keep us posted if anything pops up on the horizon.

Amiri

                   

This still seems to not be addressed.  I am at the same point now.  I have created the source code versions of my plugin classes but now want to switch to the PPL design.  What are the steps to make the conversion?  Can I just move my parent plugin class to a PPL and then tell the main app and the plugins to link to that instead of the original class (that is not in a PPL right now)?

I see some comments about how the code in the PPL runs in a separate application instance, preventing the sharing of Queues and DVRs between the main application and the plugins.  This seems incorrect to me.  Is this true?  If so, can someone at NI explain why this would be the case?

Finally, I am wondering what would happen if my plugins wrote to a global VI that was part of the main application?  Would they use the instance of the global that was already in memory from the main application or would they use their own separate instance from the PPL file?  (which would be bad).  This seems to come back to the lack of an exclude feature in the PPL build spec.

[tstahl]

I am using LV2012, so there may be differences with whatever version of LabVIEW you are using.

If you haven't already, separate out the source for parent, executable and plugin into their own projects. This is a way to keep from crossing source with compiled and makes for cleaner projects, plus there was some issue (besides load time and performance) that was time consuming to repair that I had with keeping source for parent and executable in the same project which I don't recall at the moment.

I have been able to pass DVRs, queues and events to VIs in PPL. I believe generating a reference by name for a queue does not work.I have been able to call VIs in an executable inside VIs in a PPL, but only by passing a reference the the VI to call into the PPL.

You may want to think of a PPL similar to a DLL. There are ways to share memory and pass values between the two, but each is compiled and operates in its own memory space.

[tyk007]

Named queues are ok - the name (and unique queue it refers to) are tied to the Application Instance that calls the primitive. If the named queue is used in a PPL, then the named queue exists in the Application Instance that calls the PPL ie. the executable in this case.

[jlokanis]

Thanks.  I have been playing with the example projects to make sure I fully understand how to make this work.  Seems there is no issue passing references, but you cannot use a common VI, like a global.  So, the PPL and the EXE share the same memory space.

I am running into a weird bug with the newer example.  I keep getting error 1571.  It seems to think that the PPLs were built in a previous version of LV and do not want to load.  I have deleted all the PPLs and rebuilt the interface then each plugin separately but I still get this error.  Has anyone seen this before?

[AristosQueue (NI)]

jlokanis wrote:

I have deleted all the PPLs and rebuilt the interface then each plugin separately but I still get this error.  Has anyone seen this before?

                   

I can't believe this, but... I asked around and learned that, yes, there's an existing (recently reported) CAR on this... it occurs if you are missing a PPL. For some reason, sometimes (not always) LabVIEW gets confused and come up with the "built in wrong version" error instead of the "PPL is missing" error. Check that you rebuilt all of your dependencies when you hit the big delete button. That's all the info I have on it -- if you need more info, you probably need to open a support ticket with an AE.

[AristosQueue (NI)]

Updated information -- never mind... that CAR was closed as user error... the user forgot to delete a PPL from the old version. So, I'm afraid, jlokanis, I have to send you back to your machine and ask, "Are you *sure* you deleted all the old PPLs?"

[jlokanis]

You are right.  I found the old PPLs hiding in the ../plugins/build folder while the new ones were in the .../build/plugins folder.  Got it to work finally.

But, in the end I have decided that PPLs are not for me.  I was able to resolve the issue of passing data using FGV between the exe and the plugin (don't do it, use a DVR instead).

But the deal breaker for me was the fact that I pass some classes between my exe and plugin and my plugin uses the same architecture as my exe (a type of actor based message system).

The problem comes in that the plugin does not like the class being passed to it anymore.  My understanding is the interface PPL has it's own version of the class (in this case a wrapper around a config file) and does not like the version the exe is trying to pass (since they are no longer the same actual class even though they are from the same source code originally).  I suppose if I have build a PPL for this class first and had the exe and the plugin both use that PPL then it would work.

Next my plugin could not find the parent methods from the architecture one I changed it to inherit from the interface class in the interface PPL and not from the original source interface parent.  My guess is the interface PPL failed to pull in all the code needed to support the architecture since it only had abstract classes that were not calling all the methods in the architecture.  I suppose this could be resolved by first building my architecture into PPLs and then having my EXE and plugins referense those classes in the PPL.  But all this would have taken a lot more planning on my end and would have made my dev process very cumbersome.

So, in the end, since I cannot make the PPL rely on classes that will be in memory from the EXE when I call the plugins (like you could do with the old OpenG Builder LLBs) and since LLBs do not support classes (due to the file structure being flat inside) I have no other chioce but to use source distrubution for my plugin code.

I do hope that future versions of labview will support some sort of external file that can enclose a set of plugin classes but can also utilize classes and methods and VIs provided by the calling EXE without duplication.  It seems this use case did not get much attention with the introduction of LVOOP.

That said, if you can keep your plugins simple and decoupled from the architecture of your main application, Michael's process is solid.  Just beware of the pitfalls of complex code and not desiging for the plugin PPL before you implement any part of the plugin code in your application.

[Nate_Moehring]

If you haven't seen this video, you should take a look.  Also contains a link to the slides, which has a great process flow for doing what you describe.  Admittedly, I have never embarked on this because I don't like the workflow constraints.

https://www.youtube.com/watch?v=XEHPBRmDa7M

[jon_mcbee]

I second Nates suggestion, that video is a great resource.  I have gone down this path with success on a fairly large actor framework application, and yes you have to componentize everything (EXE side included) that any of your PPL's depend on.  However once its done you have a nice set of reusable components that you can modify without breaking anything in vi.lib, I'm working with a customized actor framework with Model-View-Presenter and Publish-Subscribe built in. 

The workflow is the main constraint, but we ended up building a set of tools to help us with that, including a custom AF Messge Maker for the componentized AF, and a tool that automatically rebuilds a tree of PPLs for you and does all the file moving betwen bin and lib.

[shew82]

The key in handling common classes is to put them in their own "support" packed library - that way your plugins and application will both reference support.lvlib:class.lvclass, and neither will "absorb" the parent class.

[BrianGShea@NGC]

I believe that the error is due to a linking problem. I.e. you built one PPL that relys on another PPL in a different path than is loaded in to memory by another PPL. Other issues I have seen have been with .NET controls, specifically the RTF document control when used in an Actor that was build into an executable.

I ran into problems like this before and solved them, they are tough, but it take time and patients and methodically steps.

I have a software that has 30+ PPLs of which most are dynamically loaded. Please reference this link for a NI Week presentation I gave: https://decibel.ni.com/content/docs/DOC-38550

The key to making all this work was to have a solid understanding of how NI links code. Relative paths are key. You must build all PPLs into a single folder structure, this is made easier in LV 2014 with the exclude dependant packed libraries. You can place PPLs into sub folders but the dependant PPLs must be kept relative the same on disk.

I started with Actor Framework as a Packed Project Library, as it is the core of my code base. Once that library is created, i replaced all instances of Actor Framework.lvlib with the PPL version. Built a new Project Provider to link to my shiny new PPL and proceed to build on that with my programs API. Those APIs where then turned into my HAL.lvlibp and SAL.lvlipb. Once those were created and tested, I began focusing on the main application and other plugins.

Finding issues, can be made simpler by creating blank project. Load the lowest level PPLs, ones that rely on no other such as Actor Framework. Then pull in the next higher PPLs. At this point I will check for any errors, or even create a blank VI and drop a few VIs from the PPLs in and ensure no broken VIs.

Continue on pulling in PPLs until an error is found, at this point you will have a very good idea of what exactly is causing the problem and you will be able to cleary see what dependencies are causing it.

If at any point in time when loading a PPL you are notified of a changed dependency path, you will need to fix that because the runtime engine will barf on those warnings, whereas the development environment will allow you to work around them.

One last big issues that I have. Disable diagrams are not good in PPLs. If they contain broken or mis-linked code they will cause you head aches. Remove them if you can or fix all the problems in each disabled diagram.

I can share some code if you would like, but I don't want to share too much as most of it is proprietary and contains years of work.

[jlokanis]

Thanks for the link Nate.  And thanks for the explainations.  I think I understand what needs to be done.  But I am now in the 'its not worth it' camp mentioned in the video. I don't have the time to go back and change everything to make this work.  Maybe for the next project.

[AristosQueue (NI)]

jlokanis wrote:
I do hope that future versions of labview will support some sort of external file that can enclose a set of plugin classes but can also utilize classes and methods and VIs provided by the calling EXE without duplication.  It seems this use case did not get much attention with the introduction of LVOOP.

I've discussed this with many at various points and it seems very unlikely. You'd need to be able to add an EXE to your source project and link against items inside the EXE, which is more than a bit strange.

We are instead looking in a direction of making the "right" solution (aka, the one used by 90% of the world's software systems where you declare your components and their build setups in the source model) easier to implement and manage.

[AristosQueue (NI)]

For the record, internal to NI, these sorts of componetization discussions and "what is the right way to do it" have consumed a fair amount of my time this year. We won't have anything to show for it in the short run, but there are longer plans to make this doable without the hoops. But it has also highlighted with actual use cases what most of us felt in our gut -- componentization is a freaking hard problem and there isn't an happy, painless solution, nor is there a "one solution of least pain to recommend." Instead -- even assuming that LV had every feature that we can brainstorm to add to it -- there are about four major strategies with infinite variation, each of which has some serious downsides and which downside is the right one for you is totally dependent upon your business environment and the predilictions of your development team. That will make it very hard to come up with a "LabVIEW recommended solution," which is what NI generally tries to do to help out users who don't have a lot of CS background.

Research is in progress.

[FabiolaDelaCueva]

AristosQueue wrote:

...

We are instead looking in a direction of making the "right" solution (aka, the one used by 90% of the world's software systems where you declare your components and their build setups in the source model) easier to implement and manage.

                   

This would be great! and it would probably work at the source code level as well. Because the problems described in this thread are not unique to PPLs. If a developer is using VIPM packages for the different dependencies in their project, they will eventually get to realize that circular dependencies are hell and that the code needs to be organized where the components everything depends on are built first and then the others and so on.

I understand we won't see anything like this anytime soon, but it would be much appreciated.

Thanks for letting us know our pain is known and something is being researched to ease it.

[dsavir]

Hi, I have come across a problem I have no idea how to solve.

I created a plugin that inherits from my abstract plugin parent. This is the 7th such plugin I have created. In the Init method I call the parent's Init method (as I do in the previous 6 plugins). In this plugin, after being packed, this causes the Init method to be broken. I tried creating a plugin that only calls the parent Init method, it is also broken. Even accessing the parent's data in Init causes it to be broken in the packed library.

The previous 6 didn't have this problem. The parent packed library is in the same folder as the child, and hasn't been changed since February. I tried recompiling the parent plugin and then recompiling the new plugin, and it didn't work. All the other methods work fine. They don't all call the parent methods, but some access the parent data and there is no problem.

Any ideas?

Thanks,

Danielle

[Ficare]

J

[mike_nrao]

Danielle,

Your batting average is good, 0.857  (6 out of 7), so it sounds like your approach is valid and mostly working.  A few things I'm unclear about that might point to a solution are:

-- Does the plugin override Init and make a call-to-parent?

  -- Are there shared dependencies between the parent and the new 7th plugin. 

-- Is parent data access through property node accessors or subVI calls to accessor methods?

Though answering these won't provide a smoking-gun, it might point you in the right direction.

[dsavir]

Hi,

Thanks for answering

-- Does the plugin override Init and make a call-to-parent?

Yes.

  -- Are there shared dependencies between the parent and the new 7th plugin.

Stuff from vi.lib and user.lib (openG and MGI toolkits). No dependencies of my own code.

-- Is parent data access through property node accessors or subVI calls to accessor methods?

I didn't access it yet. Just calling the init parent causes error 1498 in the compiled plugin.

Any help would be appreciated!

Danielle

[dsavir]

Hi,

A new question: My parentPlugin.lvlibp and all the children plugins were written in LV2011. Is there a way to write plugins in LV2014 without recompiling the Exe and ParentPlugin?

Thanks,

Danielle

[shew82]

Unfortunately not. One of the downsides of Packed Libraries is that they are locked to a LabVIEW version.

[dsavir]

Thanks for the answer. I heard that it might be possible to recompile only ParentPlugin and child plugins in a different LabVIew version and deploy the runtime of this new version as well as the runtime of the original exe, has anyone tried this?

Thanks,

Danielle

[tst]

Well, if you actually try adding a PPL in a newer version, it doesn't load, and when you right click and ask to load, it tells you that it can't load a PPL from an older version. Maybe you shouldn't listen to people who don't know what they're talking about...

[dsavir]

Thanks

[CoastalMaineBird]

I'm developing a plugin system, but my situation is different from what I've seen here.

I want my plugins to have TWO pieces - one piece runs on the host PC, and the other piece runs on a PXI target.

It's easy enough to run the host piece - I find the path, insert it into a subPanel, and I have a message system to feed it commands. I even manage preferences for it.

But for the PXI piece, it seems that there are two rules about PPLs that conspire to prevent me from making it work:

1... PPLs seem to be all-or-nothing: if you want to use one piece out of a PPL, the whole shebang has to be loaded.

2... If ANY part of a PPL is broken, then NONE of it is usable.  The LIST ALL FUNCTIONS operation simply complains about error 13 (missing dependencies), even if the piece you want is not dependent on those things.

That means that, on the PXI, the whole host piece has to be unbroken, which means that all pieces that IT needs have to be present, which makes the PXI piece dependent on stuff that it shouldn't be.

Is my understanding of the rules valid?

Is there an alternative to splitting the PPL into two pieces, one for each target?

[dsavir]

Sorry, I don't see an alternative to splitting the PPL into two pieces. Your summary of the rules is excellent.

[CoastalMaineBird]

Actually, as I stated it, it's not quite accurate.

I did a simple test:

Two VIs in a single PPL, one called "Call A" , and one called "Call B", which call two things OUTSIDE the PPL, A and B.

If A and B are standalone VIs, then it's OK to use the PPL to call CALL A, even if B is missing.

But if A and B are themselves PPLs, then if either A or B is missing, you cannot use the PPL, even for the other one which is intact.

[dsavir]

If I undesrtand correctly, you mean calling A and B dynamically, correct? because if A and B are subVIs in callA and callB, if B is missing the PPL will be broken.

That's a nice workaround, kudos!

[CoastalMaineBird]

you mean calling A and B dynamically, correct?

No - that's the surprising part.  A and B are just standalone VI files.

Call A and Call B just call them normally (simply placed on the diagram).

Call A and Call B are in the PPL.

If B is missing, you can still call Call A and it works.

[Jpina]

CoastalMaineBird wrote:

If B is missing, you can still call Call A and it works.

                   

Sorry I am getting lost, do you say that you are building your ppl without one of the VIs? and your are calling the VI statically and the PPL does not crash?

[Jpina]

CoastalMaineBird wrote:

1... PPLs seem to be all-or-nothing: if you want to use one piece out of a PPL, the whole shebang has to be loaded.

Hi, I am not sure of what you try to say/do here, but this is not exactly true. You can create folders outside your PPL and place VIs within. I believe that all the VI dependecies will be located within the folder, but I am not 100% certain. Then I suppose you could call this VIs outside the PPLs, but you may get into problems related to dependences...

[Jpina]

CoastalMaineBird wrote:

                       

But if A and B are themselves PPLs, then if either A or B is missing, you cannot use the PPL, even for the other one which is intact.

                   

Well, I would say that this is a plug-in within a plug-in if A and B are a PPL then you need an abstraction of both of them to avoid the dependences, which means another plug in and another factory parttern within your PPL, am I right?

[CoastalMaineBird]

Do PPLs work AT ALL on a PXI target?

I keep getting error 13.

A single VI, within a PPL.

My program transfers the PPL to the PXI.

The PXI program stores it, and then tries to run a VI within it.

Even if I boil the VI down to NO front panel controls and NO code, it still complains of error 13.

Even if I build the PPL under the PXI section of the LV project (rather than the host section).

If I FTP the copy that my program transferred over, back to the host, I can open it fine.

I know I've got the path right; if I alter it a tiny bit, I get error 7 (file not found), instead of error 13 (missing dependencies).

It looks like PPLs just flat out do not work on a PXI target.

[CoastalMaineBird]

Sorry I am getting lost, do you say that you are building your ppl without one of the VIs?

No, I build it with both A and B in place, so it all works.

Then I hide either A or B , and load the program again. 

The one that is not hidden still works (of course, the one that is missing does not).

[Jpina]

Well, those are few questions... :S

CoastalMaineBird wrote:

                       

Do PPLs work AT ALL on a PXI target?

Never tried a Plug-In across different targets, but I may not be possible.

CoastalMaineBird wrote:

                       

If I FTP the copy that my program transferred over, back to the host, I can open it fine.

I know I've got the path right; if I alter it a tiny bit, I get error 7 (file not found), instead of error 13 (missing dependencies).

                   

Can you explain this better?