Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Does someone have a Send Batch example?

I have a need to send four messages of the same type but with different data. Does someone have an example of how to do this with Send Batch? I can't seem to be able to bundle the message data into the message class before building the array of messages.

0 Kudos
Message 1 of 10
(5,127 Views)

a) Is there a reason not to just call Send four times instead of building a batch? A batch is for creating a guarantee that no other messages are inserted in between the elements. That may not be needed in your case.

b) But if you really need a batch ... you have to modify your message classes to have some sort of Init VI. Currently, when a message is scripted by the Message Maker, the Init and the Send are the same subVI. This is generally highly desirable. But when you create a batch, you need to edit your XYZ message to separate those functions so that you can call XYZ:Init, build the array and then call Send Batch instead of Send XYZ.

0 Kudos
Message 2 of 10
(4,393 Views)

In that case, there doesn't appear to be any advantage to using it. Thanks.

0 Kudos
Message 3 of 10
(4,393 Views)

AristosQueue wrote:

This is generally highly desirable.

I that actually highly desirable?  I had assumed that was just for the convenience of one less VI to wire up. 

0 Kudos
Message 4 of 10
(4,393 Views)

Yes. It eliminates confusion about what to do for a given message. When I originally separated Init from Send, that was a lot of extra wiring on the diagram. Then I tried a model where I had Init and Send and an Init&Send... and I got feedback about that being too confusing an API. When I went to just having the Send, that eliminated the message wire entirely and THAT was a huge breakthrough in the usability of the AF overall.

0 Kudos
Message 5 of 10
(4,393 Views)

I guess in the AF there is never a reason to have a multi-step creation of a message, nor to have more than one standard "send" method, so there is no reason not to combine them**.  Though I'm surprised that "write a message, then send it" would have caused confusion, rather than just annoyance at the extra wiring.

**In Messenger Library I have multiple send methods, including the core ones "Send", "Reply", "Query" and "Notify".  I also sometimes use messages to wrap other messages.  So I usually need to keep "write" separate from "send".

0 Kudos
Message 6 of 10
(4,393 Views)

Time Delay and Self-Addressed messages need to be pre-loaded with relevant data.  But writing accessors for a message class is near-trivial.

0 Kudos
Message 7 of 10
(4,393 Views)

It's not that there's no reason, it just isn't a common thing*... exceptional enough that users can write it when they need it (often by doing "create subVI from selection" from the inside of Send).

* in my observation... and the request comes in rarely from the forums.

0 Kudos
Message 8 of 10
(4,393 Views)

I would not write accessors since you probably have to define which data are optional and which are needed. You do not want to create a message class object which is lacking important information and send it accidentially.

I prefer in many cases not to use the send method from message maker and use an constructor (or init as AristosQueue writes) instead.

Sometimes I even encapsulate message data in a dedicated class in order to be able to send different object types (from the same class hierarchy). Per esempio I have a test result class and subclasses for string value test and numerical limit test. The callbacks, which create these classes in some subactor are different and each one is calling a constructor. But by propagating my test result to the root actor I do not care what type of test result I have. Thus I can simply view upon it as a test result.

Messages are something you can store, keep for later and send it multiple times to different actors with the same parameters. For me it is somehow unnatural to use a send method which has been build automatically, assuming that all paramters are needed (or not).

Sorry I seem to have the different opinion to you both, which makes me feel really unsecure. Why is a dedicated send method the best practice and using the enqueue VI only for experienced user?

0 Kudos
Message 9 of 10
(4,393 Views)

Don't feel nervous... there is a plethora of right answers in this domain. 🙂

In general, a message should only be carrying the payload that it needs to carry. So in the vast majority of cases, every field of the message object will be required. This is consisstent with the fact that the VAST majority of terminals on VIs should be Required <<< Should Be. I encourage all developers to turn on the Tools >> Options setting Front Panel >> Connector Pane Terminals Default To Required ... you'll quickly discover your code improves in quality... I've been trying to make that the default for years. >>> So that's one point... but it is possible to have terms that are only Recommended because some value of some terminal is almost always the same. You may have more of those than most people. No harm there.

Just using Send means you never ever see the message wire itself. It completely eliminates a whole concept from the AF framework so users do not have to understand what a message is or how it is transmitted. That makes the actual values of messages an advanced concept. It simplifies the work of sending messages. Saving message objects implies state to my sender that is a lot of unnecessary work most of the time. Just send a new value. With the way dataflow works, it's a highly preferable model to not store information that can be recomputed for a long laundry list of reasons, so I only move to a "store to use later" if I have severe performance issues arising from recomputing. Putting values into an object is going to cost the same whether I do it every send or try to hold onto "the same" object and repopulate its fields. I put "the same" in quotes because with by value types, there's no such thing, really, as the same object anywhere but on the same wire on the next iteration.

So that's the reasoning. You're not wrong, just different. And possibly advanced. Welcome to level 2. 🙂

0 Kudos
Message 10 of 10
(4,393 Views)