4th Axis rotation angle limit problem
- E_M_C_user
- Offline
- New Member
- Posts: 8
- Thank you received: 0
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.
Possibly "wrapped rotary" though I have never tried it.Is there a solution to this?
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.
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.
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.
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.
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.
Please Log in or Create an account to join the conversation.
I hit something very similar to this when implementing a toolchanger routine using G Code some while back.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 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.
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.
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.