Robot arm stops unexpectedly when attempting to real-time control it

Hi all!

I am using a CS8C robot controller controlling a TX60 robot arm.

I have a Siemens S7-300 Profibus master PLC communicating with the CS8C which is Profibus slave.

I am attempting to simulate the alter() option on the controller using the PLC. In other words, I am attempting to use PLC as a quasi-controller for the real-time robot path control.

To do this I have 2 tasks, communication() and movement().

The communication() task simply collects the profibus data, and so its code is as follows:

begin
while(true)
...
Pos.trsf.x = aioGet(IO:BLOCKA_IF10)
Pos.trsf.y = aioGet(IO:BLOCKA_IF11)
Pos.trsf.z = aioGet(IO:BLOCKA_IF12)
...
endWhile
end

The movement() task is simply robot movement to Pos:

begin
while(true)
movej(Pos, tTool, mNomSpeed)
endWhile
end

The tasks are run with priorities N and 3 respectively, where N is the number of lines of Val3 code (including the while(true) and endWhile) in the communication() program.

Unsurprisingly the robot motion in the beginning is a little jerky, before all the calculations are made. But then it appears to move real-time controlled. Upon touching the robot arm the feel is not at all smooth as it would be if proper movement was used, the controller-controlled one instead of the PLC-controlled one, but that is also unsurprising.

What is surprising, however, is that robot stops after some time. According to the isEmpty() there are still movement commands present in the controller, and checking the movement data it is still changing, but the robot is stationary. There are no errors or messages on the pendant or in the log and no task is suspended. The robot simply stops.

I am at a loss as to what is going on.

Thank you all for taking your time to read this.

In an attempt to solve the issue I have put in my code resetMotion() command inside the communication:

begin
...
if(isSettled())
dioSet(io:BLOCKA_QX0, 1)
else
dioSet(io:BLOCKA_QX0, 0)
endIf
if(isEmpty())
dioSet(io:BLOCKA_QX1, 1)
else
dioSet(io:BLOCKA_QX1, 0)
endIf
...
motionReset = dioGet(io:BLOCKA_IX0)
if(motionReset==1)
resetMotion()
endIf
...
end

With the PLC code being (written here in pseudocode):

if BLOCKA_QX0 && !(BLOCKA_IX0) for more than N ms {
BLOCKA_IX0 = true}
if BLOCKA_QX1 {
BLOCKA_IX0 = false}

In essence, what the code does is that if the robot stops for more than a set amount of time in ms resetMotion() function is triggered until the movement command buffer is empty. In practice N was set to 10-20.

This made robot not stop for more than some amount of ms, longer than N which was set because of the amount of time needed to clear the buffer. But the result was incredibly stuttery motion, as if the motion was viewed under a stroboscopic light. The motion is continuous and fast, then robot stops for just a few ms (the resetMotion does not trigger) but it is visible because of robot braking, then motion is resumed again continuous until another braking point.

I will do further analysis, but this behaviour eludes explanations. Any of you know what could be going wrong?

Hi Galet, thank you for your answer.

Unfortunately it is not that the robot executes same position instruction over and over again. In fact, the task is running, in fact the position Pos is changing in the memory of the robot, I have confirmed that. In fact, it is changing because of the open communication link.

One more thing, when I set blend to off (previously it was equal to joint with reach and leave both being 0.1) the robot is extremely slow in the beginning, I can see the stopping on every single individual point that was sent to it, the motion is jagged. After a while it returns to the old fast-for-a-while-but-stuttery motion.

In my attempt to further solve the issue I was annoyed by the fact that the feel of the motion is not nice. I wanted a pretty motion, so I changed movej, which is optimized movement and so it is not necessarily smooth in space, with the movel command, the linear movement in space.

The change from movej to movel inside movement() task solved all my problems. The robot no longer stops randomly and the motion is not stuttery, it is smooth. How exactly this change solves my problems I have no idea.

It might have something to do with the fact that I was giving point position in joint movement command, but that would mean bad coding on the side of Staubli themselves. It might be blending problem, because blending is designed to be in space, but that would also be bad coding from Staubli side.

Hi Galet, I have tried with the synchronous task with 4ms and 8ms to no avail.

I have not tried alter function because that is exactly what I want to simulate, the whole point is not to use alter function.

Hello Galet, thanks again,

Yes, I do know that I can activate demo licenses for almost all options on CS8C.

The reason I do not want to do this, as mentioned above, is that I am doing an alter simulation, that is I want to make a program such that it modifies position sent to robot, this is only the beginning and a necessary step in the process, because if I cannot real-time control robot using the PLC the task is doomed.

The data variation is roughly 2mm/4ms, that is, the sent position of the robot changes roughly by 2mm during 4ms (1 cycle time), but I varied from 0.4 to 4 mm per 4ms.

Thank you for running the simulation, but I need such precision so that 0.5mm of nStep is at the very boundary of barely usable, the precision of the robot that I would need is 0.2mm at max, so I aim at 0.1mm.

Also, yes, the not simultaneous variations is expected, but that is why, in program, I use a vector of changing direction, not individual axes.

I might give it a try making sure that position is changing, I do have slight problem with being forced into using movel (because of singularities). But I have other operations that need testing first.

However, none of this explains why the robot would stop if using movej and never when using movel (and in movel is also faster, more continuous and has nicel motion).

Hi Galet,

I do not know the exact speed of profibus, but for a fact I know that data transmission is < 10ms (both-ways speed) because earlier I monitored some things like arm position and joint forces over profibus. That should be enough, but even if it is not, if it was 100ms speed the robot should not stop.

The arm has precision of 0.02mm, so 0.1mm it should have, it is a whole order of magnitude larger.

If I understood correctly your test was a simulation in SRS, and was not downloaded to actual robot controller? From my experiences with other simulation software, like KUKA and Motoman the simulation is not complete and the robot controller behaves differently during edge cases than simulation would suggest.

Quote

I think the difference is in the approximation calcul between Joint or Linear mouvement.

Singularities : 500 mm/s is a problem for singularities positions !

That is interesting, thank you. The singularities are not problem for movej, and yet it is movej which fails, not movel.

Quote

The Alter function don't move the robot to a absolut position but modifie the position with an offset or vector.

Precisely the strength of alter function as opposed to any simulation. It is quite impossible to use third-party controller to make the CS8C alter the position real-time, as opposed to simply adding a new position.

Quote

What the position of Stäubli Services about your (medical ?) question ?

I have not yet got a response from Staubli regarding this question, which is why I posted here.

Thank you, Galet.

I ran the program with the following code:

posDist = distance(Pos, Pos_LC)
if posDist > posDistTrig then
movej(Pos, tTool, mNomSpeed)
endIf
Pos_LC = Pos

In essence this code makes sure that only such movements are calculated which are sufficiently different from each other. I have set posDistTrig to 0.1mm.

Still, if I use movej the robot stops unexpectedly.

It did, however, increase the responsivity of robot by a noticeable amount. I still have to use movel to make the robot not stop randomly.

Quote

The repetability is 0.02 for this arm ... but not the precision !

I understand the difference, but the robot precision cannot be far off repeatability. I am unable to find the precision for TX60 arm, would you have it? Not a single data sheet I have available has that info, only repeatability.

Quote

On SRS, if you load the good Emulator and use correct Payload, the simulation is the same as the real robot. I use SRS because I don't have always the robot...aned the PLC with Profibus.

The simulation is only ever a simulation. The physical robot controller and arm are the ultimate authority on what is possible. In my example, no matter what I do, if I use movej in this way the robot unexpectedly and randomly stops. Movel functions fine. So there is a fundamental problem here.

Thank you Galet.

Quote

My opinion is that, for your test, it's not possible to have the same value in the blending and in the posDistTrig. Can you try with posDistTrig=0.3 mm ?

For my test here it does not matter, the position changes in steps of 3.1 mm on the PLC (the encoder has few impulses), so that fundamentally cannot be the problem here. This code only ensures that the movement is calculated if and only if the position changes, but the change is fundamentally always way more than blending distance.

Quote

For you application, you need a relative movement or an absolut position ?

I need to track the position of an object to a certain precision, at least 0.5mm precision, so I would like to have a leaway so my goal is 0.1mm.

Hi Galet,

Quote

Have you lookeed from the side of Tracking function ? The mobile frame can be a good solution...

We want to simulate tracking, not use already existing controller option.

In the meantime the Staubli have reached back and said that "simulation works only for higher controller, 7.6 and onward". I am working with s6.8. I am not fully sure what that means.

Thank you for your time, it has been most helpful.

Have a good day!