12-19-2013 03:10 PM
Hi, maybe this is a stupid question but IMO AF would benefit a lot if it was based on Timed Loop in the Actor core instead of a normal while. We could just add an extra configuration method for the caller of the actor to invoke, and this method could specify all the inputs for the Timed Loop to be usable.
I wanted to ask if there allready is an idea like that and if not I can gladly implement it.
Solved! Go to Solution.
12-19-2013 03:34 PM
IIRC, Timed Loops are not available in the Mac version of LabVIEW (at least as of LV 2012).
12-19-2013 03:36 PM
Well yeah, that would break everything. I was not aware of this limitation. Do you know if its going to change?
12-19-2013 03:47 PM
Consider designing an RTActor, derived from an Actor, that would spin up a Timed Loop responsible for the RT work (the Actor core loop is handling messages, so doesn't need to be RT).
12-19-2013 03:49 PM
Processing any message with a variable-sized array or string will blow up your determinism. So will casting to a different Message on every call of Do.vi().
12-19-2013 03:51 PM
Perhaps this was meant for the other thread posted by OP in the last few minutes?
David Staab wrote:
Processing any message with a variable-sized array or string will blow up your determinism. So will casting to a different Message on every call of Do.vi().
12-19-2013 03:53 PM
1 timed loop per CPU core is all that is recommended in RT.
http://zone.ni.com/reference/en-XX/help/370622K-01/lvrtbestpractices/rt_priorities/
I do have one actor that needs to pet a FPGA watchdog and I spin up a parallel timed loop in an Actor Core.vi override.
Phoenix, LLC
CLA, LabVIEW Champion
Check Out the Software Engineering Processes, Architecture, and Design track at NIWeek. 2018 I guarantee you will learn things you can use daily! I will be presenting!
12-19-2013 03:55 PM
MattP wrote:
Perhaps this was meant for the other thread posted by OP in the last few minutes?
No.
12-19-2013 03:58 PM
My mistake, then. Carry on
12-19-2013 04:55 PM
David Staab wrote:
Processing any message with a variable-sized array or string will blow up your determinism. So will casting to a different Message on every call of Do.vi().
Can you explain this a bit more? (By "casting" I assume you're referring to dynamic dispatching.)
My understanding is dynamic dispatching is a fixed time operation, and I read your comment as meaning the dynamic dispatching itself will destroy the determinism. I can see how different code in each Do method would cause the time to vary on each iteration through the message handling loop. I don't understand why dynamic dispatching itself would cause problems.