4th Axis rotation angle limit problem

More
18 Feb 2012 22:09 #17804 by E_M_C_user
I have a 4 axis setup using a standard rotary table doing some work on continuous 4th axis milling.

During the finishing pass, I run a small ball nose end mill through the profile and it rotates many many many times around the A axis until the part is finished.

In step config I have the angle set to -9999 and 9999 but thats not even enough.

I find out recently in the middle of my run that the axis has hit the limit, which happened to be 6400 degrees even though I had set it to 9999 (which still isnt enough).

Is there a way to make EMC2 recognize that higher angle is an angle inside 0=<angle=<360 so that it never stops because it is 'out of limit'. Since my rotary table in reality has no angular limit.

How do I fix this? This is incredibly annoying. RIght now my temp fix is to split the gcode into small segments. So my finishing pass requires tens of files. I also have to re-zero the angle and run again.

Is there a solution to this?

Please Log in or Create an account to join the conversation.

More
19 Feb 2012 00:52 #17809 by andypugh
E_M_C_user wrote:

Is there a solution to this?

Possibly "wrapped rotary" though I have never tried it.
www.linuxcnc.org/docview/html/config_ini...b:%5BAXIS%5D-section

What limits appear in the actual INI file? You ought to be able to go up to about 10^308. It may be that stepconf has sanity-checked the limit, too sanely.

Please Log in or Create an account to join the conversation.

More
22 Mar 2012 15:31 #18711 by billooms
I ran into the same problem yesterday.

My temporary solution was to comment out the MIN_LIMIT and MAX_LIMIT lines in the .ini file. This doesn't give an error message. Clearly, there is some default limit, but I don't know what that is. At least I was able to finish my run (which needed about 60 turns) without running into the 9999 limit.

I tried the WRAPPED_ROTARY option (which sounds like just the right thing). However, I had nothing but problems with that approach. The first thing I discovered was that G90.2 and G91.2 don't work like the wiki documentation says. Use of G90.2 or G91.2 gives an error message. The next thing I discovered was that you can't make a full turn or more. You can only turn something strictly less than 360 degrees. Then I discovered that going to a negative rotation gives you something other than what you would expect. For example C-90.0 goes 3/4 of a turn to the equivalent position of 270 degrees (but turns in the opposite direction). This is really counter-intuitive -- I'm thinking that C-90.0 should give only 1/4 of a turn. The real killer for me was that wrapped rotary options in EMC2 and MACH3 behave totally different. So developing software that generates g-code that will run the same on both EMC2 and MACH3 is impossible if you use wrapped rotary axes.

If there are any other solutions, I would be most happy to hear.

Please Log in or Create an account to join the conversation.

More
22 Mar 2012 21:05 #18716 by BigJohnT
It's not possible to make one post processor work with more than one control system and even variations of that same control software will be different. That is why when you open up CAM software like Mastercam and Onecnc you find hundreds of post processors to pick from and then they may need to be configured to suit your machine in most cases.

To imply that LinuxCNC should behave the same a Mack is really funny...

John

Please Log in or Create an account to join the conversation.

More
22 Mar 2012 22:21 #18722 by billooms
Even after 40 years of engineering experience, I guess I'm still naive enough to expect standards (RS274D or ISO6983) to serve some useful purpose. I haven't shelled out the money to buy a copy of ISO6983 to see if it actually addresses the issue of wrapped rotary axis.

On a more practical note, the documentation on WRAPPED_ROTARY axis at wiki.linuxcnc.org/cgi-bin/wiki.pl?WrappedRotaryAxes is just plain wrong and needs to be updated. The use of G90.2 or G91.2 give errors.

Please Log in or Create an account to join the conversation.

More
22 Mar 2012 22:52 #18725 by BigJohnT
Everything on the wiki is user contributions and the go to place for documentation is the manuals for the version your running. If you notice something is not correct on the wiki anyone can change them.

When the NIST released EMC to open source and the programmers took over and started to improve on the the implementation of RS274/NGC and things started to change from the original RS274/NGC. So a standard in that case is just a launching point. There is even a section in the manual that describes the differences from RS274/NGC and EMC/LinuxCNC. I don't think that is up to date anymore... a quick google show two versions of RS274NGC not to mention LinuxCNC's version.

I don't have a rotary axis but do understand there are some compromises to be made when using one.

LinuxCNC does not have G90.2 or G91.2 and that may be the source of your error.

John

Please Log in or Create an account to join the conversation.

More
22 Mar 2012 23:19 #18728 by billooms
OK. Thanks for the additional information.

Please Log in or Create an account to join the conversation.

More
23 Mar 2012 11:16 #18740 by ArcEye
Hi

For example C-90.0 goes 3/4 of a turn to the equivalent position of 270 degrees (but turns in the opposite direction). This is really counter-intuitive -- I'm thinking that C-90.0 should give only 1/4 of a turn.

I hit something very similar to this when implementing a toolchanger routine using G Code some while back.

The ATC would try to take the shortest route to the commanded rotary position, which sometimes would mean it trying to rotate backwards against the pawl when the commanded movement angle was over 180 degrees.

Think I solved it by making all moves incremental from the current position.

May not be wholly useful for your situation as no move would be > 315 degrees ish for an eight station turret.

regards

Please Log in or Create an account to join the conversation.

More
16 Apr 2012 14:53 #19240 by SvenH
I am also trying to get my 4th axis to spin continuously.

Here is what I have found so far:

www.linuxcnc.org/docs/2.5/html/hal/rtcomps.html
linuxcnc.org/docs/html/man/man9/stepgen.9.html

seem to say I should add the following
ctrl_type=p,p,p,v

to .hal ->

loadrt stepgen step_type=0,0,0,2 ctrl_type=p,p,p,v

At line 8 (in my case)


I have changed the bottom section from:
Code:
setp stepgen.3.position-scale [AXIS_3]SCALE
setp stepgen.3.steplen 1
setp stepgen.3.stepspace 1
setp stepgen.3.dirhold 35500
setp stepgen.3.dirsetup 35500
setp stepgen.3.maxaccel [AXIS_3]STEPGEN_MAXACCEL
net apos-cmd axis.3.motor-pos-cmd => stepgen.3.position-cmd
net apos-fb stepgen.3.position-fb => axis.3.motor-pos-fb
net astep <= stepgen.3.step
net adir <= stepgen.3.dir
net aenable axis.3.amp-enable-out => stepgen.3.enable

In to:

setp stepgen.3.velocity-cmd [AXIS_3]SCALE
setp stepgen.3.maxvel 7200
setp stepgen.3.steplen 1
#setp stepgen.3.stepspace 1
#setp stepgen.3.dirhold 35500
#setp stepgen.3.dirsetup 35500
setp stepgen.3.maxaccel [AXIS_3]STEPGEN_MAXACCEL
#net apos-cmd axis.3.motor-vel-cmd => stepgen.3.velocity-cmd
net apos-fb stepgen.3.position-fb => axis.3.motor-pos-fb
#net astep <= stepgen.3.step
#net adir <= stepgen.3.dir
net aenable axis.3.amp-enable-out => stepgen.3.enable

there is some more code below that that I have not touched about estop and toolchange.

After these changes the emc actually starts up, which is already something.

But when I turn the machine on I get a joint 3 following error.

The .ini file looks like this:
[AXIS_3]
TYPE = ANGULAR
#HOME = 0.0
MAX_VELOCITY = 120.0
MAX_ACCELERATION = 1200.0
STEPGEN_MAXACCEL = 1500.0
SCALE = 19.2585459798
FERROR = 1
MIN_FERROR = .25
MIN_LIMIT = -99999999.0
MAX_LIMIT = 99999999.0
HOME_OFFSET = 0.0

Now when I turn the emc on the a-axis immediately starts to move and stops at what seems to be just after the MIN_FERROR

Please Log in or Create an account to join the conversation.

More
16 Apr 2012 15:22 #19241 by andypugh
SvenH wrote:

setp stepgen.3.velocity-cmd [AXIS_3]SCALE
setp stepgen.3.maxvel 7200
setp stepgen.3.steplen 1
#setp stepgen.3.stepspace 1
#setp stepgen.3.dirhold 35500
#setp stepgen.3.dirsetup 35500
setp stepgen.3.maxaccel [AXIS_3]STEPGEN_MAXACCEL
#net apos-cmd axis.3.motor-vel-cmd => stepgen.3.velocity-cmd
net apos-fb stepgen.3.position-fb => axis.3.motor-pos-fb
#net astep <= stepgen.3.step
#net adir <= stepgen.3.dir
net aenable axis.3.amp-enable-out => stepgen.3.enable


I don't see any reason not to set the stepspace and other parameters, so I would uncomment those lines.

You have commented out the line which gives a position command to the stepgen:
#net apos-cmd axis.3.motor-vel-cmd => stepgen.3.velocity-cmd
So it may be that the stepgen command pin is pointing to uninitialised memory. You need to uncomment this line.
commenting out the stepgen.step and stepgen.dir lines _ought_ to stop the motor moving at all... so uncomment those lines too.

If you still have the problem, try:
setp stepgen.3.velocity-cmd [AXIS_3]SCALE
setp stepgen.3.maxvel 7200
setp stepgen.3.steplen 1
setp stepgen.3.stepspace 1
setp stepgen.3.dirhold 35500
setp stepgen.3.dirsetup 35500
setp stepgen.3.maxaccel [AXIS_3]STEPGEN_MAXACCEL
net avel-cmd axis.3.motor-vel-cmd => stepgen.3.velocity-cmd
net apos-fb axis.3.motor-pos-cmd => axis.3.motor-pos-fb
net astep <= stepgen.3.step
net adir <= stepgen.3.dir
net aenable axis.3.amp-enable-out => stepgen.3.enable

Please Log in or Create an account to join the conversation.

Time to create page: 0.365 seconds
Powered by Kunena Forum