Conversion from (QMH + LV2 Globals) to AF

[Todd_Lesher]

To (hopefully) speed up the learning curve, I'm trying an all-actor approach. (If I go any slower, I should probably just be trying this project in the land of pretty AF icons.)

I know picture and words are best, but the project is attached. I stripped it down a bit and added an attempt at zero-coupling.

The idea is that there is a Serial Device actor that can send and receive Bytes. The Bytes can come via a com port, a dll, or a software simulation. I made Transport actors for those three instances to see how the messaging can be the same.

The Serial Device actor's core continually sends a "Read Available Bytes"  message to the Transport actor, which puts any Bytes into a zero-coupled message. Upon receiving that message, Serial Device puts them into a queue of Bytes. At the moment, those Bytes are only displayed on the actor core FP, which I've set to open.

I imagine there are lots of better ways to do many of the things in this code. Ithink I need to throttle the simulated Byte injection.

[jdebuhr]

I just wanted to comment that this discussion is also helping me as I work through to understand the Actor framework and how I might implement it.

[Todd_Lesher]

My zero-coupled message was way off-base. Here's an update. It still doesn't work, though. In the callee Transport actor, when "Read Available Bytes.vi" sees there are Bytes available, it calls its own Send method (Send Report Bytes From Device.vi) which I had hoped would dispatch the caller's Do.vi. That do (in Serial Device.lvlib/Report Messages From Other Actors/Report Bytes From Device Msg.lvclass/Do.vi) never gets called.

[Todd_Lesher]

Here's a version that works (so far). It does not have the LV2 globals/data storage in place, but I needed a starting point. I'll clean up the actor spin-ups, and look for a good way to destroy the queue pair - then start adding data storage. I'll quit clogging up the attachments folder, though.

[Todd_Lesher · Accepted solution]

These zero-coupled messages now work. I started adding simulated device functionality, too. (Run Test.vi and click New, if you want to play.)

It will be interesting to see if instrument drivers developed in AF can easily be wrapped in an API actor so non-LVOOP internal customers can use them.

[AristosQueue (NI)]

ToddLesher wrote:

It will be interesting to see if instrument drivers developed in AF can easily be wrapped in an API actor so non-LVOOP internal customers can use them.

I've seen one non-NI group do exactly that. The custom send queue wire was the only trace of OO on the final API. I think their solution could be generalized, but I do very little instrument driver work, so I'm not going to assert this.

[massimo1167]

I'm considering to migrate my application, based on QMH with extensive use of LV2 Globals, to a LVOOP programming model.

I believe that AF can help me to achieve my goal.

I'm trying to better understand how to make and I would like to take a look also to this project.

I downloaded the project and opened with my LabVIEW 2015, but I had different errors for VI or classes do not find (Message Queue Pair.lvclass:Read Send Queue.vi; Send Queue.lvclass; etc ...).

Does anyone have this sample project already converted for LV2015?

Thanks