Independent Motion Task

    So, diving down yet another rabbit hole... I'm trying to use MultiMove Independent to control a custom (non-ABB) multi-axis positioner as a separate Task, independent of the robot's motion Task. Ideally, I'd like to achieve something like a cross between a SemiStatic "background" Task, and a Motion Task.


    Right now, I'm doing this as a simulation in RobotStudio (RW 6.13) before I make any attempts in hardware, so I'm free to experiment without fear of destroying anything. :uglyhammer2:


    After a lot of reading and some back&forth with ABB, I worked out how to create my custom positioner, and give "custody" of it to a second Task in the robot. But now I'm not sure where to go from here. I've been able to achieve something similar to a SemiStatic Task behavior, by creating an infinite loop in my "background" Task's Main routine, and then assigning routine to a PowreOn event. Then the "foreground" and "background" Tasks handshake if needed using virtual I/O or Intertask variable.


    So it works, but I can't help feeling that it's overly janky. Is there a better way to go about this? For example, instead of starting the background Task with PowerOn, are there any means in RAPID to have one Task start/stop/monitor another?

  • Jump to the most helpful post

    Could you please describe what characteristics you are looking for in a seeming pseudo-hybrid task?


    Also, is there something undesirable about 2 motion tasks?

    Using pure guesswork, I am wondering if the instruction WaitTestAndSet might be of use for your project.

    Edited once, last by SomeTekk ().

    I don't see any reason why you would not just make the task Normal. In it, just use the good old WHILE (TRUE) DO loop. I was of the same opinion as SomeTekk about WaitTestAndSet, there is also a very similar function to use a boolean semaphore between tasks. I have used it before.

    So, I had an assignment to create a detailed simulation in RS that included a multi-axis positioner moving parts between different robot and operator stations. I built a Mechanism that worked, and controlled it using Station Logic and a SemiStatic Task in the robot that was doing double duty as the positioner controller. It had to be a SemiStatic Task b/c the positioner had to operate autonomously from whatever the robot was doing.


    But I didn't like the lack of granular control using Station Logic and PoseMovers. Plus Station Logic does not scale well as the complexity of the motion increased. So I started digging into how to achieve the same effect with the positioner mechanism as a group of external axes.


    I eventually learned that a SemiStatic Task cannot be a Motion Task, which surprised me, but it is what it is. I still needed my "background" Motion Task to run like a SemiStatic Task, which lead to my kludge described above. But I'm not sure it's a good kludge.


    For example, starting an endless-loop Normal Task with a PowerOn event seems a bit... weak? For one thing, if the background task ever got stopped somehow, would a reboot be the only way to start it again? I guess I'm looking to see if there's a better way to do this.


    I may be thinking too much from my KUKA background, here, where it's possible for any "task" to to check the status of, or start/stop, any other "task". I haven't found a way to do the same in RAPID, so far. My default fallback for monitoring, at least, was to create a virtual DO signal that the background Task would keep Pulsing every loop, so that if the background Task ever stopped running, the robot task would see that DO turn False and react appropriately. I've never encountered the TestAndSet commands before, I'll have to try them out.

    • Helpful

    A normal background task will start and stop at the same time the foreground task does. You should not have to use the poweron event at all. If you need to stop should the background task faults and stops, you assign it the appropriate trust level. You probably want syshalt.

    Well, ideally the free-running background task should never crash. But I'd like to be able to have the foreground task at least check, on the off chance someone stopped it manually or something.


    Regarding the start of the background Task... I guess I'm not very clear on the foreground/background relationship. What "links" them? My reading in the RAPID reference manual lead me to believe that setting the "Task In Foreground" on a Task caused the "background" Task to only be scanned/executed when the "In Foreground" Task was idled. Which sounded less than ideal for what I was trying to accomplish. I didn't find anything that implied setting "Task In Foreground" would cause the "background" Task to start/stop along with the "foreground" one. Is that how it works, or are you referring to something else?

    Addendum: Okay, I think I see what you mean about the "background" Task running along with the "Foreground" Task. I didn't set the "Task In Foreground" setting, but when I set up a counter loop in the "background" Normal Task, then ran the "foreground" Task through some robot motions, the counter in the "background" Task definitely incremented. So, it looks like any "start" event (like the pendant Run button) starts any Normal Task?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now