Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor Framework and Requesting Data from Instrument

Hi all, apologies if this has been asked and answered before. I've done a bit of searching and couldn't see anything conclusive with respect to my situation.

 

I'm using Labview as the basis for my test system software, and currently a PNA for our instrument hardware. I'm using SCPI and VISA to communicate to the instrument.

 

I have a 'PNA' actor, which handles communication to the instrument, such as sending commands and queries, and also launches nested actors based on the mode we're using the PNA in. The nested actors are sub-types of the PNA, and have the appropriate SCPI and methods, as these can be different depending on what mode the PNA is in. When I need to send a command from one of the nested actors to the instrument, I have a 'Send Command' message that carries a string up to the calling actor (the PNA actor), sends it to the instrument, which then executes the command.


This has worked really well. However, I have come to a problem that I need some assistance with.

 

There are going to be occasions where I will need to read data back from the instrument after a request. This could range from trace data, to requesting a status byte query, and I might need the nested actor to use that information for a task. For example, I might need to check the previous command has finished before proceeding, or check the power level on the PNA before turning the power on.

 

If anyone has any advice or insight in how to overcome this hurdle, it would be really appreciated.

 

Thanks very much

 

0 Kudos
Message 1 of 11
(2,227 Views)

If you only ever use 1 nested actor depending on the state, you might consider using the NI State Pattern. Instead of launching a 2nd actor (PNA launches A, B, or C modes), the State Pattern Actor will morph your PNA into A, B, or C depending on the mode. Then your child class will have direct access to everything in the parent (specifically the SCPI & VISA interfaces).

 

Original announcement about the State Pattern Actor library:

https://forums.ni.com/t5/Actor-Framework-Discussions/Implementing-the-State-Pattern-in-Actor-Framewo...

 

VIPM package:

https://www.vipm.io/package/ni_lib_state_pattern_actor/

 

0 Kudos
Message 2 of 11
(2,217 Views)

It almost sounds like this doesn't need to be an actor. Does the instrument interface need a constantly available loop to run all the time? If not, maybe just make it a regular object. You can still implement a HAL this way, you just lose the messaging, which you may not even need.

0 Kudos
Message 3 of 11
(2,198 Views)

@OneOfTheDans wrote:

If you only ever use 1 nested actor depending on the state, you might consider using the NI State Pattern. Instead of launching a 2nd actor (PNA launches A, B, or C modes), the State Pattern Actor will morph your PNA into A, B, or C depending on the mode. Then your child class will have direct access to everything in the parent (specifically the SCPI & VISA interfaces).

 

Original announcement about the State Pattern Actor library:

https://forums.ni.com/t5/Actor-Framework-Discussions/Implementing-the-State-Pattern-in-Actor-Framewo...

 

VIPM package:

https://www.vipm.io/package/ni_lib_state_pattern_actor/

 


 

One of the advantages of this is that we can have multiple nested actors representing a different channel on the PNA, something we have done in the past.

 

I'll definitely look into the State Pattern though and bookmark it for future use, thanks

0 Kudos
Message 4 of 11
(2,194 Views)

@BertMcMahan wrote:

It almost sounds like this doesn't need to be an actor. Does the instrument interface need a constantly available loop to run all the time? If not, maybe just make it a regular object. You can still implement a HAL this way, you just lose the messaging, which you may not even need.


That is something I had considered, and may indeed be the route I need to take.

 

I just wanted to make sure I had considered all options before committing to one direction.

 

0 Kudos
Message 5 of 11
(2,191 Views)

Gotcha. If you're sticking with multiple nested actors for the channels, you could include the Nested's "Self Enqueuer" with the Send Command(string, reply-enqueuer). When the caller gets a response, it can send that as a new message, Send Reply(string), back down to the nested. It's a bit cumbersome because the nested might need to internally track what type of response it's expecting. But I think that's the nature of tight request/response messages in AF (and perhaps any asynchronous framework).

0 Kudos
Message 6 of 11
(2,181 Views)

I like that idea, definitely something I'll look to use as my current method is more cumbersome than that.

 

I have another question actually. Is it ok practice to include another message in a Do.vi?

 

For example, if I have a 'read data' message, sent from nested actor to calling actor, is it ok to modify the 'Do.vi' of 'read data' to queue another message, something like 'write data'? This 'write data' message would have a control input with the data. In my mind this would be a quick and easy way of sending the data read to the correct place.

 

This would solve my problem I think, but just wanted a few opinions of doing it this way.

0 Kudos
Message 7 of 11
(2,148 Views)

Do.vi doesn't have the message source's enqueuer, so you can't just send a response back. You'll need to explicitly include the "self enqueuer" somehow for that to work (if I'm understanding your idea correctly). I wish the AF included the source address in all messages. You might look into  "Address Message" and "Send Self-Addressed Message", which are on the AF palette. I'm not sure how they work though, I've only seen they exist.

0 Kudos
Message 8 of 11
(2,141 Views)

@OneOfTheDans wrote:

Gotcha. If you're sticking with multiple nested actors for the channels, you could include the Nested's "Self Enqueuer" with the Send Command(string, reply-enqueuer). When the caller gets a response, it can send that as a new message, Send Reply(string), back down to the nested. It's a bit cumbersome because the nested might need to internally track what type of response it's expecting. But I think that's the nature of tight request/response messages in AF (and perhaps any asynchronous framework).


Note that if you provide the Reply message in the original request, then then you can include the context of how to interpret the response as part of that (such as by providing a child class of Reply, or prefilling the response with what the original request was).

0 Kudos
Message 9 of 11
(2,107 Views)

@OneOfTheDans wrote:

But I think that's the nature of tight request/response messages in AF (and perhaps any asynchronous framework).


If I may be critical, this is the Actor Framework not having proper replies built in, causing Users to have to implement the missing functionality ad hoc.  Email, as a real-world asynchronous framework example, handles both replies and context of the reply quite intuitively.

Message 10 of 11
(2,104 Views)