Stopping tasks - NXT-g

[simonauv]

Is exiting a loop the only way to turn a task off without stopping the whole program in NXT-G once it has finished what it was intended to do? I'm wanting to turn an ultrasonic sensor off once it has finished its task so it doesn't conflict with future obstacles.

[felix2ch]

Is exiting a loop the only way to turn a task off without stopping the whole program in NXT-G once it has finished what it was intended to do? I'm wanting to turn an ultrasonic sensor off once it has finished its task so it doesn't conflict with future obstacles.

Any condition used to determine task off can be used to exit a loop.
So, what is the difference between exit loop and turn task off?
Btw:You can create a task without loop, when everything done, the task will be turn off.

[simonauv]

Thank you. As a newb to NXT-G programming I am finding some of it quite confusing. I am playing with setting tasks without loops by multitasking but they still seem to rely on loops to detect whether conditions are true or false before executing the task within a switch-block (set to flat view so more than 2 options can be defined). What I'd like to do is use the ultrasonic to run until it is needed and then turn off. Trouble is, I don't know when it will be needed as the course it has to do is variable and then once I get to the end I want to turn it back on again to do a different task. I can get my head around the last part but the first part is making my head hurt.

[HaWe]

the task control featured by the Lego fw is weird indeed.
The same issue was about NXC in the beginning, start/stop task control was not possible.
Only when JH's Enhanced Firmware (EFW) has been changed in this respect you could use

start [taskname]
or
stop [taskname]

from any task to control any other task.

To stop a task depending on a condition you can define a global variable, a so-called semaphore. This should be set to "1" if the related task should be able to run, and set to "0" if the task is meant to stop. This semaphore can be polled inside your task and so the task himselfs "knows" when to abort or not. There are a few runtime-dependent disadvantages associated with it, but nevertheless, it's a workaround.

Related to switching the US sensor on/off , there is unfortunately another issue:
once the USS has been configured to a certain port, the US sensor is steadily, continually running in a autonomous continuous mode, thus it can't be stopped, and it's independant from reading the US sensor value or not.
Crazy, but true, and a waste of computational power, a useless stressing of the i2c bus, and an environmental ultrasonic noise pollution on top of that.

You can only change this behaviour if you
a) reconfigure the USS port to sth like "NO_Sensor", or any other different sensor, and then reconfigure it as a USS again if ou once need it (but that switching there and back takes some time to work)
b) use the USS in a single shot mode, but I'm not sure if this is possible using NXT-G (with NXC it works).

HTH!

ps
my advice: drop NXT-G and switch to NXC.
nobody who can read and write - except maybe primary school pupils - needs an icon-based programming environment
https://sourceforge.net/apps/phpbb/mind ... p?f=3&t=49

[simonauv]

Thank you for your help. This does serve to clear a few things up and gives me a few ideas to try.

As far as dropping G and going to RobotC or NXC (etc) I have RobotC and am learning that as well because it seems like it will give me much more control... but you allude to my need to stay with G because I am a teacher who has a new interest in robotics and I am also trying to assist school children with no programming experience to develop G programs. So I've been making hundreds of different programs to get my own head around it so that I can help them more effectively. Just last Saturday I took them away to their first competition and they won 1st, 2nd, and fourth place... so I'm pretty happy with them. The thing now, as far as I se it, is to try and make their programs more reliable and it seems to me that to do this they need to be able to task-switch more effectively (which is easier in NXC or RobotC but they are not ready for it yet).

Another problem I'm having, which is related to switching tasks more effectively, is to get the robots to exit a basic line-follower task to detect a green 40mm,40mm square located at a line junction on one side that serves as a turn-left/right on green instruction. It seems to want to finish the line-follower task before detecting green and so works only sporadically... even with verification worked into it... another thing that is doing my head in at the moment.

Thanks again.