Fly-by points

larstoc

In my current project we update the robtarget for the movement about ten times a second (the limit of instructions RAPID can handle) but to ensure that we do not try to update faster we have a little sleep in there (WaitUntill 0.1). Due to the rapid updates the targets are not far from each other, however, I would like to use the fly-by points option to avoid the stuttering but I have not been able to. As far as I have understood you define the fly-by points by increasing/decreasing the zonedata, but it doesn't seem to have an affect. Any information on the subject would be welcome.

PerSvensson

How close are the points? becuase that will define how large zones you can have.

Ex.

If you have 2 targets where the distance between them are 10mm the largest zone you can have on the targets is z5 becuase otherwise they will intersect with each other. so having larger zones will not have any effect. 

In RS 6 you have the possiblity to show the zones and also optimize them.

PerSvensson

The robot do execute motion ahead, which means that the program pointer is ahead of the motion pointer. The conc attribute kind of makes the calculation even more ahead so that you don't get unwanted stops when points are close to each other (lot of calculations that has to be done in short time).

svoldgaard

around 200 ms sounds right, but haven't made any calculation on it.

It was with zonepoints(fly by points) and without waittimes in between.

If you have any wait conditions the robot might convert the zonepoints to fine points.

you can reduce the delay by adjusting some of the path planning parameter if I remember correctly.

svoldgaard

I can't remember them exactly, but you should be able to find them under help -> system parameters in robotstudio. Then you should be able to find the parameters that makes the robot update more often and so on.

larstoc

The points can be quite close as the robot is tracking head movement. I've also read that having a sleep (WaitTime) can negate the effects of fly-by points, however, we have found them necessary as to not update the controller more than 10 times a second, which seems to be the limit. Is there a way to avoid this?

PerSvensson

Have you tried to add the Conc attribute to the move instructions? but be aware that you can't have more than 5 in a row.

larstoc

I've looked at it, but I might have misunderstood it previously. Originally I thought that it meant that it could only take 5 commands a second, but after re-reading it that doesn't seem to be the case. Is it so that it can't be updated again until one of the instructions is done? We want to update as much as possible as to create good tracking. 

svoldgaard

I have created a project, where I just executed the same move instruction over and over again. The move instruction have an offset, that is updates by another task.

This made it possible to jog the robot with a 3D mouse smoothly, but with a small delay...

larstoc

What kind of delay where you experiencing? The current delay of my system is about 160 ms in regards to the headmovements that is made. Did you utilize fly by points? 

larstoc

160 ms is actually a bit too much for us, so we will have to do some adjustments. What kind of path planning parameter are you talking about?

kazoo

I'm experiencing the same issue. I keep sending a new MoveL instruction around every 200msec. The robot moves smoothly with a few instructions and then gets stopped for a while (then iterates this process). How can I make a smooth movement by feeding the new position & MoveL with less delay? How many instructions can the robot handle in a time?

Hi @svoldgaard, I'm interested in what you created. Can I see your code somewhere?

kazoo

I tried \Conc option, but ended up with getting "Unknow error".

svoldgaard

My code is basically:

    PROC moveRobot1(num X,Num Y,Num Z)

        VAR jointtarget jTmp;

        Additor x,y,z;

        TriggL offs(initTarget,-Y/factor,-X/factor,-Z/factor),vmax\T:=moveTime,readData1,z20,tool0;

    ENDPROC
I can not remeber all the detaile at the moment, but I use the trig to tell when I'm at the point.

VsaMpaio

As long as you are using MoveABsJ (the fastest move function), the only parameters are Path Resolution (set to 0.1667), Queue Time (0.290304), Process Update Time (1.9535). You can mitigate the Move function delay to a minimum of 0.12 seconds. You can always turn off every motion and safety supervisor, and things will get faster. but I wouldn't advise you to do so

lemster68

I see that you are using the optional argument \T:=moveTime.  When using that argument the robot makes a fine point.  I have seen it before.