Actor Framework Discussions

I do not see anything special that you would need to worry about. Just build it and use it. I don't even think it matters which packed project library owns the message classes. Your choice (though we generally recommend putting them in the same library as the actor that receives those messages).

LVB: Did you successfully build your packed project libraries using actors?

AristosQueue wrote: LVB: Did you successfully build your packed project libraries using actors?

No, I went with the monolithic packed project library approach (a single packed project library).  Builds, debugging and deployment were too combersome with multiple packed project libraries.

I will work on a proof of concept over the next few days and post back my results...

I finally had a little more time to spend on this.

AristosQueue wrote: I do not see anything special that you would need to worry about. Just build it and use it. I don't even think it matters which packed project library owns the message classes. Your choice (though we generally recommend putting them in the same library as the actor that receives those messages).

Please let me know if I am missing something, but I am experiencing a lot of difficulty implementing the use case in my original post.  Everything works fine until I build the packed libraries and replace them in the source project.  When I open the code with packed libraries, there are "wire class conflicts" for messages and actors.

• A and main are still source (lvlib)
• B is lvlibp (Packed)
• C is lvlibp (Packed)
• Main.vi passes a "callback" message and enqueuer handle from B to C and launches all three actors

I believe the following occurs which causes the "wire class conflicts":

Building B and C to PPL cause "Actor Framework.lvlib" to be namespaced under B.lvlibp and C.lvlibp.  Due to this, the actors no longer inherit from a common class and no longer from Actor.lvclass in vi.lib.  Note how both of the lvlib actors have a class conflict to the vi.lib "Launch Actor.vi".  This also causes the message classes to be namespaced under B and C.lvlibp and prevents messages between packed project libraries.

Any solutions?  The monolithic approach becomes quickly unmanageable as the project grows larger.

Some useful information here, and Nancy's linked article from there: https://decibel.ni.com/content/docs/DOC-20274

One general pitfall that must be avoided, when multiple build specifications must work together in a single application, is colliding library reductions. It happens this way:

When the check mark(s) are set to remove unused poly instances and/or to modify libraries, in the build specifications, you risk ending up with incompatible versions of a library or missing instances within a poly-VI, within the final application. Since only one instance of each library and poly-VI can be in memory, this will be the instance that loads first in the application flow. If this particular instance isn't   compatible with all code executing from that point onwards either a runtime error occurs or a broken arrow stops the application loading due to a datatype mismatch or a missing VI (typically error codes 10xx, 22xx or similar). A variation on this type of error is the situation where a VI breaks during the build due to a private method being called from a public scope due to a build optimization (can't remember the exact error code off the top of my head, maybe 1508?)

Cheers,

Steen

Matt,

Thanks for the link.  I am already using that technique for our re-use libraries.  However, it depends on an inheritance chain that maintains the packed libraries.

The technique mentioned in that article would require inheritance from Actor Framework.lvlibp (thus not using vi.lib anymore).  Are you suggesting replacing Actor Framework.lvlib in vi.lib with a packed library?

In addition to this, some message classes are not in the Actor Framework.lvlib (Batch Msg, Reply Msg, Self-Addressed Msg, Time-Delayed Send Message).  What would be the suggested method for placing these into a packed project library (and associated lvlib)?

I disabled these items in the build.  Unfortunately, the did not make a difference.  I believe the problem is due to the namespacing issues of the packed libraries.  Still looking for solutions....

I have attached my reference project at https://www.dropbox.com/s/api05b2njt0vkjg/Packed%20Library%20Actors.zip

You built your whole project before you built any of your packed project libraries. We will refer to this hereafter as Mistake Number One.  🙂

Aristos Queue's Recipie For Component Development With PPLs or DLLs:

If you are going to write an application that comes in multiple discrete chunks, do the following:

1. Create a new project.
2. In the project, write the VIs/libraries for Chunk 1.
3. Test the VIs/libraries in Chunk 1. Repeat steps 2 and 3 until Chunk 1 works.
4. Build Chunk 1 as a PPL or DLL.
5. Create a second new project.
6. Use the second new project to write Chunk 2. If Chunk 2 uses Chunk 1, do NOT refer to the VIs/Libraries of Chunk 1. Instead, use the Chunk 1 PPL or DLL.
7. Test Chunk 2. Repeat 5 and 6 as needed.
8. Build Chunk 2 as a PPL or DLL.
9. Repeat steps 6, 7 and 8 for all remaining chunks of your application
10. Create yet another new project.
11. In this new project, write the VIs for your EXE. Use the PPLs and/or DLLs in this project. I assume by now you know to do the testing here.
12. Build your EXE.
13. If at any point after step 4 you need to make a change to  Chunk 1, open Chunk 1's project, make the change, rebuild the PPL and then go back to what you were doing.

No, I am not kidding. No, I am not trying to make your life miserable. This is the pattern of component development that software engineers know and hate in every other development language I can point at. Some IDEs are better at recognizing that the other components need to be rebuilt because they have changed code. LabVIEW doesn't do this. But you are still expected to have declared up front that you want to make this code as a component. Trying to generate components from a coherent source code base is a bad strategy doomed to cause more despair and fist shaking than any pain caused by opening multiple projects and dividing everything up.

Sorry. That's the only way I know to make component development viable. I don't suppose there's time in your project schedule to undo Mistake Number One? *wry grin*