Dear All,
I have a problem if I want to control the Operation Call from another thread. I try to check if the Component is avalaible and acquire their status on a Periodic event. But in compile time appear a problem usign an Enum as a type returned from the send() method. (it is working usign a simple call() method, but I want to control more states without blocking nothing).
if (this->operationGetStatus.ready()) { //this->componentStatus = this->operationGetStatus.call(); SendHandle<model::ComponentStatusEnum(void)> nhandle = this->componentStatus.send(); SendStatus ss = nhandle.collectIfDone(this->componentStatus); yield; //for non blocking operation. if (ss == SendSuccess) { LOG_DEBUG_STREAM(this->getName() << ", status: " << this->componentStatus << "] "); retries=0; } else { LOG_DEBUG_STREAM(" ... checking status << retry: " << retries++); } } else { LOG_DEBUG_STREAM(" ... checking status << retry: " << retries++); }
the error in compile time appear as:
/apps/ugv/core/watchdog/src/core/MonitorizedActivity.cpp: In member function ‘virtual void core::MonitorizedActivity::step()’: /apps/ugv/core/watchdog/src/core/MonitorizedActivity.cpp:43: error: request for member ‘send’ in ‘((core::MonitorizedActivity*)this)->core::MonitorizedActivity::componentStatus’, which is of non-class type ‘model::ComponentStatusEnum’ /apps/ugv/core/watchdog/src/core/MonitorizedActivity.cpp:45: error: statement cannot resolve address of overloaded function
Somebody knows if I need to declare the Enum as Type Lib or something like this? I readed tones of documentation on Orocos and I can't found nothing more complex returned than the base types (int,double, etc..)
Thanks in advance Toni
Problem Using OperationCaller<> with Enum type
On Thu, 10 Nov 2011, Antonio Castellon wrote:
> Sorry for the before top_post
> As you said, is more logical that if the component is alive then it should call to the watchdog, truly I
> developed the both methods for the Observed components: from the Component across a data-flow connection
> and, in the other hand, from the WatchDog to the rest of Components.
>
> The reason to implement the other inverse methodology is because the control of the fatal errors of the
> component, what's happen if a fatal error is generated? the deployer is shutdown?
The real question to answer first is: which component in your application
has (or should have, or is allowed to have) the knowledge to make this
decision. The second question is: based on what information this decision
will be made. And the third one is: how is the decision realised in the
running system.
These are _three_ different aspects of the whole safety problem. And you
can only discuss whether a certain design fits if you have clear answers to
these three issues.
Anyway, "shutting down" a component from the outside is never a good idea;
let the component know that it should close down itself, via an event.
> if not, I understand that my watchdog is replaceable directly for the
> deployer, then how I can access to the Core of the deployer in order to
> assign some logical business associated with the fatal error in order to
> relaunch the component instance?
Your English is very difficult to really understand, so I am not sure
whether my answer is answering your real question. But I suggest to think
in terms of events that inform components that they should react in a
particular way.
> In other case, if a fatal error are not accesible/detectable on runtime
> for the deployer then how I can do it?
By definition of the meaning of "accessible" and "detectable", you can't!
> many thanks,
> Toni
Herman
Problem Using OperationCaller<> with Enum type
The first of all, sorry for my english, sometimes I written too quick
without checking the style.
I understand that from the logical point of view, the correct solution is
that each component has a MachineState definition where is declared the
different options to execute methods like (restart blocked device, restart
configuration component, etc. ).
If some fatal exception is produced in one of the components then the
container deployer is dropped (shutdown) ... the unique solution is outside
of the Orocos framework via another process on O.S.
thanks for all,.
toni
Problem Using OperationCaller<> with Enum type
On Thu, 10 Nov 2011, Antonio Castellon wrote:
> The first of all, sorry for my english, sometimes I written too quick without checking the style.
Posting to orocos-dev will be good practice :-) We'll do our best to
support you :-)
> I understand that from the logical point of view, the correct solution is
> that each component has a MachineState definition where is declared the
> different options to execute methods like (restart blocked device,
> restart configuration component, etc. ).
It is indeed one of our "best practices" to give each component its own
state machine (for this kind of purposes, but of course also for the
"nominal" behaviour).
> If some fatal exception is produced in one of the components then the container deployer is dropped
> (shutdown) ... the unique solution is outside of the Orocos framework via another process on O.S.
Another "best practice" is never to design a system that is "closed", that
is, no "error" is "fatal", but just a state your components are in until
a higher level of component composition provides an event to get you
started again.
> thanks for all,.
You're welcome!
> toni
Herman