Rotary buffer

[kandauru]

Hi,

 

I am trying to use rotary buffer in my application to move axes. But the problem is that axes are not moving at all. All axes are homed and enabled.

Please, advise, what is wrong.

 

The following lines of source code are how I am trying to do that:

 

 

&1a

Define rotary BUFFER_SIZE

open rotary

Coord[1].MaxFeedrate = FEEDRATE

Coord[1].Tm = -SPEED

x-283.000 Y202.000 Z305.000 V90.000 U-84.000

x-285.000 Y202.000 Z305.000 V93.000 U-84.000

x-287.000 Y202.000 Z305.000 V96.000 U-84.000

x-289.000 Y202.000 Z305.000 V99.000 U-84.000

x-290.000 Y202.000 Z305.000 V100.000 U-84.000

x-289.000 Y202.000 Z305.000 V99.000 U-84.000

x-287.000 Y202.000 Z305.000 V96.000 U-84.000

x-285.000 Y202.000 Z305.000 V93.000 U-84.000

x-283.000 Y202.000 Z305.000 V90.000 U-84.000

close

&1b0r

[kandauru]

Hi,

 

I am trying to use rotary buffer in my application to move axes. But the problem is that axes are not moving at all. All axes are homed and enabled.

Please, advise, what is wrong.

 

The following lines of source code are how I am trying to do that:

 

 

&1a

Define rotary BUFFER_SIZE

open rotary

Coord[1].MaxFeedrate = FEEDRATE

Coord[1].Tm = -SPEED

x-283.000 Y202.000 Z305.000 V90.000 U-84.000

x-285.000 Y202.000 Z305.000 V93.000 U-84.000

x-287.000 Y202.000 Z305.000 V96.000 U-84.000

x-289.000 Y202.000 Z305.000 V99.000 U-84.000

x-290.000 Y202.000 Z305.000 V100.000 U-84.000

x-289.000 Y202.000 Z305.000 V99.000 U-84.000

x-287.000 Y202.000 Z305.000 V96.000 U-84.000

x-285.000 Y202.000 Z305.000 V93.000 U-84.000

x-283.000 Y202.000 Z305.000 V90.000 U-84.000

close

&1b0r

[Omron Forums Support]

Maybe a Clear Rotary command needs to be issued so that pre-existing lines in the buffer are not being unexpectedly executed.

 

Is BUFFER_SIZE greater than 2048?

[Omron Forums Support]

Maybe a Clear Rotary command needs to be issued so that pre-existing lines in the buffer are not being unexpectedly executed.

 

Is BUFFER_SIZE greater than 2048?

[steve.milici]

Also check for any motors in the CS not in closed loop.

[steve.milici]

Also check for any motors in the CS not in closed loop.

[kandauru]

Thank you for replies!

1) The buffer size is 4096. And may be greater.

2) All motors are in closed loop. But to get feedback I need them to be in closed loop.

It looks like it moves, but very very slowly.

[kandauru]

Thank you for replies!

1) The buffer size is 4096. And may be greater.

2) All motors are in closed loop. But to get feedback I need them to be in closed loop.

It looks like it moves, but very very slowly.

[Omron Forums Support]

Are the following set up correctly:

 

Linear mode

 

Coord[1].Ta, Coord[1].Td and Coord[1].Ts

(Set time in acceleration, deceleration, and S-curve accel)

 

Motor[x].MaxSpeed

 

Frax

(Use Frax command to choose which axes are used in vector feederate calculations)

[Omron Forums Support]

Are the following set up correctly:

 

Linear mode

 

Coord[1].Ta, Coord[1].Td and Coord[1].Ts

(Set time in acceleration, deceleration, and S-curve accel)

 

Motor[x].MaxSpeed

 

Frax

(Use Frax command to choose which axes are used in vector feederate calculations)

[curtwilson]

A "feedrate" value is a commanded vector speed of your "feedrate axes". The intent of this functionality is to get a constant tool-tip speed in 2D or 3D Cartesian space without the user having to compute the individual axis speeds. PMAC does this by first computing the vector distance of the feedrate axes by Pythagorean theorem, then dividing by feedrate to get the move time.

 

By default, the "feedrate axes" are X, Y, and Z. It is possible to change this with the FRAX command, but very few people do (and I don't think you have changed this). The idea of a constant vector feedrate regardless of direction does not make geometric sense with more than 3 dimensions.

 

In your example, your vector distance is zero. Since you also have "non-feedrate" axes (U and V), it instead computes the move time by dividing the commanded distance of each non-feedrate axis by the saved parameter Coord[x].AltFeedrate, and taking the largest of these times. The resulting motor speeds are then compared to Motor[x].MaxSpeed for each motor, with the move time extended if any of these limits are exceeded.

 

So you first need to check your value of Coord[x].AltFeedrate, then the values of Motor[x].MaxSpeed as Greg said.

[curtwilson]

A "feedrate" value is a commanded vector speed of your "feedrate axes". The intent of this functionality is to get a constant tool-tip speed in 2D or 3D Cartesian space without the user having to compute the individual axis speeds. PMAC does this by first computing the vector distance of the feedrate axes by Pythagorean theorem, then dividing by feedrate to get the move time.

 

By default, the "feedrate axes" are X, Y, and Z. It is possible to change this with the FRAX command, but very few people do (and I don't think you have changed this). The idea of a constant vector feedrate regardless of direction does not make geometric sense with more than 3 dimensions.

 

In your example, your vector distance is zero. Since you also have "non-feedrate" axes (U and V), it instead computes the move time by dividing the commanded distance of each non-feedrate axis by the saved parameter Coord[x].AltFeedrate, and taking the largest of these times. The resulting motor speeds are then compared to Motor[x].MaxSpeed for each motor, with the move time extended if any of these limits are exceeded.

 

So you first need to check your value of Coord[x].AltFeedrate, then the values of Motor[x].MaxSpeed as Greg said.

[curtwilson]

More precisely, if the time for any of the non-feedrate axes, as calculated by (AxisDistance/AltFeedrate), is greater than the time calculated for the combined vector feedrate axes (VectorDistance/Feedrate), it will use this longer time, and the actual vector feedrate used for the move will be less than what was commanded.

[curtwilson]

More precisely, if the time for any of the non-feedrate axes, as calculated by (AxisDistance/AltFeedrate), is greater than the time calculated for the combined vector feedrate axes (VectorDistance/Feedrate), it will use this longer time, and the actual vector feedrate used for the move will be less than what was commanded.

[kandauru]

Thank you for support!

I am going to check all you said here.

[kandauru]

Thank you for support!

I am going to check all you said here.

[Omron Forums Support]

I know this might be obvious, but have you actually defined axis definitions in coordinate system 1?

 

For example:

 

&1

#1->X

#2->Y

#3->Z

#4->V

#5->U

[Omron Forums Support]

I know this might be obvious, but have you actually defined axis definitions in coordinate system 1?

 

For example:

 

&1

#1->X

#2->Y

#3->Z

#4->V

#5->U

[JohnR]

I know this maybe a little off topic, however I’ve seen this issue several times in the forum and it’s happened to me many times.

Is/could there be a way to determine the limiting parameter in a motion move?

[JohnR]

I know this maybe a little off topic, however I’ve seen this issue several times in the forum and it’s happened to me many times.

Is/could there be a way to determine the limiting parameter in a motion move?

[curtwilson]

The best way to figure out what is going on is to plot the desired velocity profile through data gathering.

 

There are many different limiting factors that could occur at different stages in the calculations. I don't think it would be feasible to flag all of them.

[kandauru]

Hi,

 

I am facing a new problem using rotary buffer: the rotary buffer stops running after first line was executed.

Please, advise how to fix this problem.

 

Here is my source code:

 

CS defined as below:

 

&1

#1->x

#2->0 //position follower of #1

#3->xx

#4->0 //position follower of #3

#5->y

#6->yy

#7->z

#8->zz

#9->u

#10->uu

//#11->a //not used in current configuration

//#12->aa //not used in current configuration

//#13->b //not used in current configuration

//#14->bb //not used in current configuration

#15->v

#16->vv

 

Then in my application written on C#:

 

//buffer initialization

cmds.Add("&1a");

cmds.Add("&1 delete rotary");

cmds.Add("&1 define rotary " + ROT_BUF_SIZE); // ROT_BUF_SIZE = 4096

cmds.Add("&1open rotary linear abs close");

cmds.Add("&1b0r");

 

SendCommands(rotComm, cmds, out res);

 

//buffer filling

cmds.Add("&1open rotary X92028 Y1089221 Z1631730 U-500011 V173488 close");

cmds.Add("&1open rotary X92087 Y1089385 Z1636252 U-500125 V172850 close"); //at this line the execution stops

cmds.Add("&1open rotary X92152 Y1089550 Z1640774 U-500238 V172212 close");

cmds.Add("&1open rotary X92221 Y1089714 Z1645296 U-500352 V171575 close");

cmds.Add("&1open rotary X92296 Y1089878 Z1649817 U-500465 V170937 close");

cmds.Add("&1open rotary X92376 Y1090042 Z1654338 U-500579 V170300 close");

cmds.Add("&1open rotary X92461 Y1090206 Z1658858 U-500692 V169662 close");

cmds.Add("&1open rotary X92552 Y1090370 Z1663377 U-500806 V169025 close");

cmds.Add("&1open rotary X92648 Y1090533 Z1667895 U-500920 V168387 close");

cmds.Add("&1open rotary X92749 Y1090697 Z1672411 U-501034 V167750 close");

cmds.Add("&1open rotary X92855 Y1090860 Z1676927 U-501147 V167112 close");

cmds.Add("&1open rotary X92966 Y1091024 Z1681440 U-501261 V166475 close");

cmds.Add("&1open rotary X93083 Y1091187 Z1685953 U-501375 V165837 close");

cmds.Add("&1open rotary X93205 Y1091350 Z1690463 U-501490 V165200 close");

cmds.Add("&1open rotary X93332 Y1091513 Z1694971 U-501604 V164563 close");

cmds.Add("&1open rotary X93464 Y1091676 Z1699478 U-501718 V163925 close");

 

SendCommands(rotComm, cmds, out res);

[steve.milici]

Check motor status and CS status- more than likely this is the cause - the program is being aborted or maybe stopped by a feed hold.

[kandauru]

I see in CS1 Error Status "RunTimeError". What to check?

[JohnR]

I see in CS1 Error Status "RunTimeError". What to check?

 

Check the Error Status to determine what caused the RunTimeError

 

Coord[x].ErrorStatus

 

Power PMAC Software Reference Manual - Page 667