Using an Actor in non-AF code

[Todd_Lesher]

I have an actor that is an instrument driver (I wish I could post the code, but I've made it too product-specific). There is a non-classed Create.vi that accepts:

  - Transport Type (simulated, com port, or virtual com port DLL)

  - Protocol Version (1, 2, 20120731, hack-test)

  - Instrument Actor Type (headless, dev GUI, simple GUI)

  - Transport info (com port number or an index for the DLL - likely to be subsumed into detection)

The Instrument Actor launches a Transport Actor, Protocol Actor, and (if specified) a Simulated Instrument Actor.

I'm happy with the very simple Transport Actor. All it does (when told to by the Instrument Actor) is read availble Bytes from the interface and report them to the caller. (There is no termination character, but one could be supported. All reports are zero-coupled.)

When the Instrument Actor gets the Bytes Read report, it sends a message to the Protocol Actor to parse the Bytes. When the Protocol Actor gets enough Bytes to make a packet, it parses them and reports them to the caller. Framing error, checksum error and unknown packets are also reported.

The Protocol Simulator Actor is currently just a GUI that allows injection of packets into the "simulated" type of Transport Actor. Those Bytes are what is reported when Read Available Bytes message is sent to the simulated Transport Actor. This helps with debug and with error checking of the Protocol Actor.

Everything works fine and dandy! (Even some of the error handling.) However, there are two reasons I need to call this code from non-Actor code:

  1 - Allow non-AF devs to use the driver (thank you for not reminding me that training is a good thing)

  2 - I can't figure out how to write a test sequence with AF (so this may be my training - I'll follow through here, anyway)

So, I made a non-OOP API:

  Create.vi:  spins up the actors

  Open.vi:  send the Instrument Actor's "Open" message (which allows Bytes to be read by the Transport Actor)

  Get Version.vi:  send the Instrument Actor's "Get Version" message

  Destroy.vi:  trigger all actors' Stop Cores

Calling these in order (such as in main.vi) brings up the appropriate Actor Core GUIs, and the operations all work - but now I'm trying to figure out a good way to have reports show up in the scope of main.vi. For example, if the wrong com port is selected, I want the error reported by the Transport Actor to show up on the Error Out terminal of Open.vi. The instrument API wire (somewhat analogous to the "VISA resource name" and "VISA resource name out" terminals on VISA primitives) is a cluster of:

  - Instrument Actor's send queue

  - Transport Actor error notifier

  - other notifiers for all possible data that needs to be present in main.vi

When the Transport Actor gets its Handle Error called, it reports an error to the calling Instrument Actor, but I want non-error notification, too - so I have the Transport Actor's "Open" method directly send the notifier. Due to the nature of the instrument, and due to only waiting on notifiers or Reply messages in the main.vi scope (and properly handling notifier errors in the actors' scopes), I am only slightly concerned about the architectural issues AF solves (race conditions, locks, etc). What I am mainly concerned about is the sanity level of creating notifiers for every Actor output and passing those notifiers into the Actors so they have them available.

Thank you for any thoughts - including guidance on how to make an AF-based Create/Open/Get Version/Destroy sequence.

[Daklu]

No answers for your specific questions, but this did jump out at me:

1 - Allow non-AF devs to use the driver (thank you for not reminding me that training is a good thing)

IMO it is probably a mistake to create code using the AF unless everyone in the organization is on board with the decision.  Developers like to dig into code, and when they dig into your driver code and find all this stuff they don't understand they are likely to loudly complain to superiors.  (This is especially true if you are working where I think you are working.)  Sometimes keeping your job means you need to conform to the majority opinion, even if you believe that opinion is flawed.

[Todd_Lesher]

I knew a guy whose team wrote C code. He did not allow anyone to use structs since he wanted "anyone off the street" to be able to understand the code. That code got quite hairy.

I'm not entirely convinced AF is the proper use for my needs, but it's fun to learn. And I just can't (yet) beat the convenience of swapping out actor's faces. I'll keep trying to understand how to write a Test actor.

[AristosQueue (NI)]

> Developers like to dig into code

Three words: Save Without Diagrams.

Mwuhahahahaha!

[AristosQueue (NI)]

On a more serious note to Todd: niACS just left on a (well-earned) vacation for a week, and he left his laptop behind deliberately. But when he gets back a week from today, he's going to be polishing up and posting an AF example for a host talking to an RT box. That conversation happens over the network and the same strategy that he has working there will work for non-RT network communications. I'd guess about a full week for him to get it polished to the point that he can post the example.

[Todd_Lesher]

AristosQueue wrote:

> Developers like to dig into code

Three words: Save Without Diagrams.

Mwuhahahahaha!

I'm (slowly) working on vipm files for the drivers. (Source in SCC, of course.) Maybe I'll start with SWD.

[Todd_Lesher]

AristosQueue wrote:

I'd guess about a full week for him to get it polished to the point that he can post the example.

Thanks for the heads-up, AQ. In the meantime I'm playing with implementing the test flow in a state machine such that each state can be replaced with an actor's method. At run-time, send a sequence of messages as the test flow, and allow errors to notify an actor to skip the remaining messages (in the methods). Not the final solution, but at least I'm getting in up to the elbows.