Queuing of commands

Hi,

I am using Orocos 1.10.

We have a non-realtime TaskContext called dataLogger, which will receive
custom dataobjects from other TaskContexts and serialize them out via a
TCP socket.

I plan to use Orocos Commands to implement this functionality, as follows:

The dataLogger TC will have a Command: logData(customDataObject &data);

TC's A and B which will be peers of dataLogger will call this command
with the customDataObject they want to log.

In TC A's startHook(), the command from the dataLogger() will be
acquired [TheLogCommand = getPeer()->getCommand<>()] and then
TheLogCommand will be used within A to log customDataObjects

Now my question is:

I know that TheLogCommand needs to be around when dataLogger tries to
execute the command. But what happens if TC A calls TheLogCommand
multiple times, before the dataLogger gets a chance to execute (this is
quite likely, since dataLogger is non-realtime and TC A is a realtime,
high frequencey task). Will dataLogger still queue & execute the
commands in order, so that all customDataObjects are logged? Or do we
need to acquire the same command multiple times in TC A (via
getPeer()->getCommand() ) ?

Is there a problem with this approach? I specifically want to avoid
using dataports since in reality, there are many more taskcontexts which
need to log data and having a single command in the dataLogger which
other TC's can call whenever they want to log data seems very elegant.
The customDataObject is a wrapper class that includes all the different
data structures that other TC's may want to log.

Regards,
Sagar

Queuing of commands

On Wednesday 09 March 2011 14:15:31 Sagar Behere wrote:
> Hi,
>
> I am using Orocos 1.10.
>
> We have a non-realtime TaskContext called dataLogger, which will receive
> custom dataobjects from other TaskContexts and serialize them out via a
> TCP socket.
>
> I plan to use Orocos Commands to implement this functionality, as follows:
>
> The dataLogger TC will have a Command: logData(customDataObject &data);
>
> TC's A and B which will be peers of dataLogger will call this command
> with the customDataObject they want to log.
>
> In TC A's startHook(), the command from the dataLogger() will be
> acquired [TheLogCommand = getPeer()->getCommand<>()] and then
> TheLogCommand will be used within A to log customDataObjects
>
> Now my question is:
>
> I know that TheLogCommand needs to be around when dataLogger tries to
> execute the command. But what happens if TC A calls TheLogCommand
> multiple times, before the dataLogger gets a chance to execute (this is
> quite likely, since dataLogger is non-realtime and TC A is a realtime,
> high frequencey task). Will dataLogger still queue & execute the
> commands in order, so that all customDataObjects are logged? Or do we
> need to acquire the same command multiple times in TC A (via
> getPeer()->getCommand() ) ?

Yes. You need to build multiple Command<> objects that do this queueing for
you. The storage of the command's arguments is done in this object, until the
function is executed. You can not re-use a command object until it's function
has been executed. This is a thing we solved in the RTT 2.x series, where an
asynchronous operation object ('OperationCaller') may be invoked multiple
times.

Since logging requires buffering, I doubt the command is going to lead to an
elegant solution...

>
> Is there a problem with this approach? I specifically want to avoid
> using dataports since in reality, there are many more taskcontexts which
> need to log data and having a single command in the dataLogger which
> other TC's can call whenever they want to log data seems very elegant.
> The customDataObject is a wrapper class that includes all the different
> data structures that other TC's may want to log.

In 1.12 and 2.x, we solved logging using the Logger component, which does use
data ports behind the scenes to transmit log messages. It's the only sane
solution given the classes RTT provides. See
http://www.orocos.org/wiki/rtt/rtt-20/real-time-logging/using-real-time-
logging
for the whole story. For your case, you'd only need to wrap your TCP/IP code
in an Appender component you write yourself, and you'd be where you want to
be.

Peter