topic_solved G1 not slowed to respect limits on rotation axis?
I've a mid size Workbee that I've added a rotational axis, about the z-axis. I'd set up the config file as degrees per minute rather than mm per minute and as you may expect the axis is capable of high rates, of 120,000deg per min, or just over 5.5rev/sec.
I've been breaking up linear moves into sections with the half of the required angle between two vectors being buried in the last fraction of the former move, and the second half being included in the first fraction of the second move. The intention here is to avoid a very stuttered move-rotate-move-rotate-etc motion, and allow the machine to make use of instant speed etc.
In my first example I stuffed up a bit and didn't include a long enough stretch of the vector to complete the rotation. My understanding of the way G1 moves are supposed to behave is the feedrate is based on the linear axis, but the move would be slowed down if the rotational movements can't take place in the time the G1 move takes. This isn't happening. The rotation axis squeaked at me on each corner and lost position.
I've found my error (yeah mm/min vs mm/sec got me again...), as I was trying to ensure there was comfortably enough time to complete the rotation without capping the speed, but my understanding of is this shouldn't of happened as my config limits are set to prevent loss of position?
Using RRF3.3rc3 on Duet 2 Ethernet with rotation axis connected to a Duex5.
@doctrucker, RRF does respect the movement speed limits on all axes, including rotational ones. If you do some more tests, I think you will find that this is the case.
@dc42 does G1 commands through the DWC control use instant speed and acceleration in the same way that it will be used during a build?
@dc42 Found the route cause of the problem. Entering single G1 commands into the DWC is not enough to test the acceleration and jerk settings. I swapped to a build file with G1 commands that swung the rotation axis side to side over 10, 45, 90, 180, and 340 degrees and that required me to drop the jerk and acceleration to lower values.
Not having the high jerk value does however make it much harder to merge the rotation into the end of the vector as the linear axis is decelerating and the rotational speed at the jump in point must be no higher than the jerk setting of the axis... Going to think this over and write it up a little before asking more questions on that in a seperate thread!