Jump to content
OMRON Forums

Delay when calling a motion program


luis.segalla

Recommended Posts

Hello

I'm having some problems when calling a motion program inside Delta Tau. It shows a delay between turning on all the motors for the coordinate system (The AmpEna flag being set to 1) and calling the motion program (in our case this is represented by setting the kinFlag to 1) as shown in the attached file (motion-delay).

 

This motion program calls the CfromScript function and inside it we implemented some calculations for the direct and inverse kinematics. We don't understand this delay because it is happening before the CfromScript function is called, could it be some kind of pre-processing when using C? There are some special flags that need to be set (besides UserAlgo.CFunc=1)? Or is this delay normal?

 

Another intriguing point is that it only happens in one of the coordinate systems. It does not have the delay when we run the coordinate system 1, as shown in the second attachment (mr7-Ipê2). Do you have any ideia why?

 

Anyways

Thank you for your attention

Best regards

Luis Fernando.

motion-delay.thumb.png.0c5f5a84484409266584b8169f489778.png

2125727500_mr7-Ip2.thumb.png.46e68c554f0fa05779ad4aafda000fb0.png

Link to comment
Share on other sites

  • Replies 7
  • Created
  • Last Reply

Top Posters In This Topic

It is normal to have some delay between putting enabling motors and starting the motion program. Trying to start a motion program will fail if the motors are not ready, so the motors must be enabled first. How much delay should be up to how these two operations were commanded. If a PLC is watching inputs to start the motors and program, it's logic would determine the delay.

 

How were these motors commanded? If a PLC starts a motion program, is there a check for Motor[1].InPos?

Link to comment
Share on other sites

Hi Eric

Thanks for the answer!

The InPos doesn't seem to be the problem. It is only is used in a readback PLC, but we tried disabling all the PLCs from the project and the delay still happened. We're using virtual motors now to test this and it shows the same problem.

The motors are being controlled directly by the motion program, we're calling it via terminal for now and passing the values calculated by the Kinematics implemented in C to the corresponding Axis in each Coordinate System and there is a specific Motion Program for each CS (we're using two).

 

I understand that the delay might be normal, but then, why does it only happen in one of the CSs? There is any field in the motor struct that could be set to change this?

 

Thanks for the attention Eric

Link to comment
Share on other sites

Enabling the motors and starting the motion programs are going to be different commands. If the first process is not done before the second is started, then the second will fail.

 

If commanded from the IDE terminal with no PLCs running, I would expect you to first be issuing a command like this:

#1,2J/

 

And then shortly later issuing a command like this:

&1B1R

 

However it sounds like you are issuing a single command for both. I thought this was a flag for a PLC, but no PLCs are running. Can you show me the command you are issuing in the terminal?

Link to comment
Share on other sites

Hi Eric

 

I was dragging the following commands from the note.txt to the IDE terminal:

#4,5,6,13,14j/
&2Q78=1
&2b2r

 

 

The kinFlag is a flag set in the motion program as soon as it is called:

open prog 2
 kinFlag = 1
 .
 .
 .
close

 

One interesting thing I found while trying to debug the problem was that when changing the values of jogTa and jogTs on the motors of the CS there was no delay.

The first image shows the movement when using JogTa = 6000 and JogTs = 2000, you can see that the time between enabling the motor and starting the motion program is approximately 8 seconds.

On the second test, I changed the JogTa and JogTs of all motors to 0 and the delay was gone.

Do you have any idea why? As I see it, Ta and Ts are associated with the movement time, do they have any special relation with the motion program being called?

delayTa6000Ts2000.thumb.png.167789699818258942047765b6338292.png

delayTa0Ts0.thumb.png.29ee77dbfb51be84fca3a8231e0109d7.png

Link to comment
Share on other sites

Hi Eric!

We have two files that configure the coordinate systems' motors. In the Forward Kinematics .kin file we have:

&2
open forward(2)
.
.
.
close

and in the Inverse Kinematics .kin file we have:

&2
#4->I 
#5->I
#6->I
#7->I
#13->I
#14->I
open inverse(2)
.
.
.
close

 

(The CS 1 files are configured in the same way, just using motors 1, 2 and 3 instead.)

 

There are any relation between the way this is configurated with the delay we're seeing? I still don't understand why the delay is the exact sum of jogTa and jogTs for the individual motors we configured.

 

Thank you for the attention Eric

Link to comment
Share on other sites

I was dragging the following commands from the note.txt to the IDE terminal:

#4,5,6,13,14j/
&2Q78=1
&2b2r

 

This is not best practice. The Jog command is not guaranteed to finish before the &2B2R command is run. If it does not finish, the &2B2R will need to be re-issued. That being said, it worked when I tried it just now.

 

One interesting thing I found while trying to debug the problem was that when changing the values of jogTa and jogTs on the motors of the CS there was no delay.

The first image shows the movement when using JogTa = 6000 and JogTs = 2000, you can see that the time between enabling the motor and starting the motion program is approximately 8 seconds.

On the second test, I changed the JogTa and JogTs of all motors to 0 and the delay was gone.

Do you have any idea why? As I see it, Ta and Ts are associated with the movement time, do they have any special relation with the motion program being called?

 

When you are in open loop (before issuing the jog command) encoder position is treated as trajectory position. When you issue a Jog/ command, a trajectory is created to bring that velocity to 0 based on JogTa and JogTs.

 

Because your JogTa and JogTs are positive, this is very slow. If you set them negative (to indicate a rate instead of time) this move will pass much more quickly.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...