hmmmh...
I thought the sensor watchers induce background tasks by themselves - otherwise you won't need them, so why put them into an endless task?
(Or could this be another bug?)
Otherwise you just could pack your sensor value query and assignment into your extra task and forget about all the sensor watchers (that's the way I'm doing... )

I wonder if the monitor-while-loop is really needed.
There are similar constructs in LeJos and NQC, and there you use it in a different way:
- you once start the Sensor listener, maybe at the program start; this causes a hidden endless task;
- you ask anywhere in any subroutine or different task, if there has happend a sensor event, e.g., in this case maybe in a while loop...;
- you react to the event if there was one, otherwise do sth else("try...catch...")

or am I completely wrong?
BTW: isn't there any a code example source ?

my fault: I misunderstood "monitor", I thought it was for starting the monitoring thread, not for "if no event", and I was used to "catch" for the exception, not for "if event", now this seems to me kind of other way around...

Thanks for your contributions, people. True, in attempting to figure out the events I neglected to assign the sensor.

So let me see if I have this straight, because the event monitoring seems a little pointless in the way I understand it now. It seems that if you want to be monitoring an event, then the main body of your program must either be inside the code for this, or be a routine called from here.

This is what I mean:

Code:

task main(){ SetEvent(TouchEvent, EST_SENSOR_2, eventTypePressed); while (true) { monitor (EVENT_MASK(TouchEvent)) { //main body of program or a call to it // do this while there is no event } catch (EVENT_MASK(TouchEvent)) { PlaySound(soundBeepBeep); // do this when there is an event } }}

It makes more sense to me to be able to initialise the monitoring code, then just leave it alone until the event triggers, as such:

I must be missing the point, but would appreciate having it shown to me. I can only assume that it must be started in a separate task, but as Ford stated, why have another task to look after a task...?

If this is the way to use an event, surely this code is simpler and just as effective (sonar mounted on motor - monitors for it being knocked by an object the sonar missed, eg sound absorbant material):

hi,
I doubt if it's possible to leave both the listener initialization and the event checking outside any loop.
As I understand this issue, the initialization indeed has to be started once.
But anywhere there has to be made a decision what to do, either if this event has happened ("behavior 1)", or not ("behavior 2"). This could happen in your motor steering routine. Sure, if you want to react only once in your program at all, there doesn't have to be a loop, but if you want to do this maybe several times or each time during run time, this
monitor...catch switch
surely will have to be queried in a loop.

If the "event-behavior" is additional to the standard behavior, you may do it by an extra task. In case of an event then both behaviors are running simultaneously.
And if there isn't anything to do in case of no event (no behavior 1), you may let the program or task wait until there will be one.

Otherwise, if you have 2 "excluding" behaviors and you want to put them into 2 different routines, you will have to program a sort of "behavior handling". I myself did this before using a subsumtion (subsumption) architecture. By this one the "higher level task" is idle if no event happens, so the lower task got the control; if the event happens, the other, higher level tasks takes the control and the lower one becomes inactive - I can't imagine how to do it by an other way...

But, to be honest: I think that the event listeners are made for people who wish to avoid to write their own multi tasking programs. If you want to handle sensor events in different tasks, I'll suggest to write the sensor checking routines by your own.

(sorry for my English, I might have explained this in a better way in my native language)

Yes, I think we are on the same path. I don't know the fancy terminology, but I have a hiearchy of 'modes' which the robot steps through, depending on the result of an attempt to complete the previous task. I think this is similar to your subsumption architecture.

Of course, I do want my sensors to be monitored continuously, but I want this to happen in the main part of my program, not in the 'monitor' or 'catch' bit of the event code.

Thanks for your input. I will be ditching events and stick to monitoring the sensors through my own tasks.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum