Hey guys,
I’m new to the chat group but have been operating my 5x10 for 4 years now mostly cutting urethane tooling board for composite mold making. I recently built a custom rotary axis fixture to accommodate a large diameter part that required rotary to make it work. I’ll post some pictures from my phone in a comment below. The issue I am having, which will be viewable in a video that I post in a comment below(also from my phone) is that there is something causing a jerky motion of the rotary axis and I believe it’s slipping the motor, causing it to loose position slowly over time. I already changed the acceleration rates dramatically from 1000 unit/S’ to 200, but that didn’t seem to have any effect on what I’m seeing. The Z axis is traveling slowly up and down while the A axis rotates, so I assume that this is trying to adjust rotational speed to match a desired surface speed. Since the Z is moving a small amount, the radius is changing and thus the rotary speed must change as well. Am I reading this problem correctly? Any thoughts about smoothing this out? I know I may be pushing the limits of the motor with the weight of the part I’m spinning, but I believe I am within it’s capabilities after viewing the start and stop rates while jogging. The video I’ll post below has the spindle turned off so it’s really easy to hear the rotary axis noise. Appreciate any and all input!
Tim S.
An apparently Iphone videos aren’t supported formats… any suggestions on how to upload a video?
Initially it was slipping here. It has since been retorqued. But the jerking is commanded.
Here is a link to a video showing the issue.
Thanks guys!
More thoughts on my theory that this is the results of a linear acceleration controller attempting to maintain a specific surface speed(280in/min) while the Z is adjusting to maintain the profiles radius. If this is the case, is there a way to set an RPM and allow for a variable surface speed?
After some thought I came back to look at the G code (which I’m pretty novice at) to see if I could identify the issue. Sure enough it’s in the feed rate. Any time there is a drastic change in feed rate, it makes the noise which sounds like when you force the motor. In a quick search, I’ve seen the feed rate go from F3350 to F400 in one line of code, and back up to F3000 something. When I slow the feed down to 25%, it won’t make the noise, suspecting that the change in speed is not fast enough at that point to create a slip, or, over run of the motor, which ultimately causes it to lose degrees of rotation and it doesn’t take many to accumulate before your part is severely compromised in dimensional accuracy.
So can anyone suggest how I might manipulate the code or post processing to prevent these aggressive feed rate changes?
On my machine I ended up reducing the acceleration maximums until the undesired movements were gone.
Also, check if you’re in constant speed mode (F is in/min or mm/min) or “inverse time” mode (F is in operations/min). The “oddly changing feed rates” in your screenshot looks like inverse time mode, and in that mode, such variations are normal.
How do I switch to constant speed mode?
If you’re doing rotary work, you don’t. The problem with constant speed mode is - is the speed in/min or degrees/min ? Linear and angular moves have different units so it becomes problematic and confusing to have one F setting for both. Inverse time mode doesn’t have that problem because it doesn’t include a distance factor, it’s just “this operation should take this long” (or, more accurately, “you should be able to do this operation F times per minute”) regardless of whether the move is linear, angular, or both.
So inverse time mode is better for rotary work, but takes more file space as every move needs an F term. Constant speed mode means you have the same F term for all moves so it doesn’t need to be replicated, but doesn’t account for rotary moves well.
Note that both of these reflect the speed the CAM software wants! If the machine is using different speeds for different operations, it’s the CAM’s fault. I was just trying to point out that if you’re reading the G code directly, you need to know which mode you’re in in order to interpret the F codes properly.
I think I understand the logic behind this, but not sure where to go to prevent the drastic changes in F from line to line, which are causing slips in the A axis simply because the weight of the part doesn’t allow such quick changes in speed. I am surprised that there are such large changes in F from line to line because the Z profile, or radius doesn’t change much on this part as it rotates around. It’s almost like a stacking error that it computes to account for in one big chunk, or single line. I hope I’m explaining myself clear enough. I’m pretty new to all this…
My point is - in inverse time mode, large changes in F are expected but result in the same speed, because the meaning of F has changed.
If the commanded speed (NOT the F parameter) changes suddenly, that’s different.
Consider this gcode:
G0 X0 Y0
G1 X1 F12
G1 Y0.1 F120
Both F values mean “one inch per minute” in inverse time mode. In the first, it says “move one inch in 1/12 of a minute” and the second says “move 1/10 inch in 1/120 minute”. It’s the same effective speed even though the F parameter jumps 10x.
Now, I’m not saying you aren’t seeing speed jumps; we all agree you are. I’m just trying to help you understand the gcode properly. If it’s in inverse time mode the F values will be confusing.
Note: look for a G94 (units/min) or G93 (operations/min or inverse time) at the beginning of your file.
I’m pretty sure it’s the other way around. G93 sets inverse time mode in CNC12. G94 cancels inverse time mode.
Page 272 of the current CNC12 manual.
You may need to choose a different post processor. At least for ‘stock’ CNC12 I have a choice of one with G93 mode and one without it using Vectric. Avid’s could be different. I don’t know how you change this in Fusion, but there’s certainly a way.
I agree with @djdelorie, inverse time mode could be forcing some extreme feedrate changes.
Myt bad, you’re right. G93 - inverse time mode, G94 - units per minute mode. (note: edited to fix)
This is not quite what I’m saying. Either mode allows for smooth operation if the CAM software understands the machine’s rotary modes.
What I’m saying is that inverse time mode could be causing extreme F parameter values DESPITE those parameters causing smooth motion. It’s all about reading gcode, not machine operation.
I’m only harping on this because it’s easy to confuse the commanded speed, the feedrate, and the F parameter values. Saying “extreme feedrate changes” is ambiguous because it’s unclear whether you mean “commanded speed” or “F parameter value”.
It’s a very important distinction. Thanks for helping me understand it better.
I meant both. Inverse time mode could give large changes in F parameter values in the G-code, that could translate to inappropriate behavior in commanded speed.
Yes! However, a large change in F parameter in inverse time mode could also result in no change at all in commanded speed. Stay in school kids, math is hard 
In my rotary gcode, the F parameter is all over the place, but the machine’s motion is smooth as butter.
Looking at the screen shot I posted, I see the Z is traveling down(decreasing radius) and the line intervals are around .4 degree increments with consistent F values. Makes sense. Right as the Z reverses direction and starts back upwards, the increment goes to 2.5 degrees and thus a much smaller F value. Scanning through many lines, all of the problem areas are at Z reversals. Also I am calculating the feeds to be in the 3RPM range. The Z increments look to be consistently .0002"/line, so could this be a Z acceleration rate issue?