Varying rotational axis max speed?

[MRob]

Yeah its not good on my system . Makes it fly off to X0 Y0. But even with that swapped for G53, I'm getting an unknown gcode error - havent had time to check precisely what yet though

[MRob]

Reply from Autodesk!!

"We are going to implement that into the generic post soon, watch for updates on the post library within the next 2 weeks."

[MRob]

Autodesk team changed the post, and then messaged me to ask if I wanted to test it! Which I have just been doing. All looks good from their side, but I am seeing some slightly odd behaviour from UCCNC. I did a shape below, so it started at D5mm and progressed along until moving to D10mm and then D20mm. It runs OK at 100% feedrate, however, when I reduce the feedrate down low with the override to say 10%, it gets buggy. The feedrate is then not constant, in that it will suddenly increase, then go back down again, with sudden and seeming random jumps forward. Sometimes the jumps are quite large, like a whole rotation. Also, on the other end of the scale, there seems to be a cap regarding the maximum speed I can make it rotate at - even though the axis itself is capable of going at 2000rpm, when running with G93 it maxes at around 60rpm. This seems to be irrespective of whether I increase the feedrate in fusion, or if I increase feedrate manually above 100% with the override. I have checked the gcode, and copied sections of the A co-ordinates with F numbers, then run them through excel to calculate the rotational deg/ms speed, and the output from fusion seems to be constant. Also, although the behaviour is most noticeable when I set the feed override low, I can put my finger on the axis and feel it doing tiny little jumps as it progresses when at normal speed. Sometimes it also sticks a little once per turn.

There is a slight oddity from the fusion produced code that could be related, in that the cylinders are simple in the model, but the gcode has tiny movements in the Z position up to 0.004mm. I cannot see it is an issue with my Z axis feedrate, as the axis is capable of going fast enough, and the moves are really really tiny. I can put my finger on the axis, and feel the stepper making tiny adjustments, but these seem to be unrelated to the random A axis movements. Also I can see on screen, each time it jumps forward the feedrate likewise jumps upwards, and UCCNC jumps through multiple lines of code. Finally, I just tried running the code on my desktop in demo mode and offline (latest version), and set the Z axis to the max speed and acceleration that I could, and that doesnt give me a constant rotational speed either. It would be interesting to strip all these tiny Z moves out the code and see if it still does it, but I am unfamiliar with the type of programming that would be required to go through a text file and do that. Also, I only copied small sections of the code over into excel to check, so it is still possible that the problem is there, but I dont think so.

I've attached a picture of the model and toolpath, the nc file wouldnt upload but I've made a link to it here if you want to check: https://1drv.ms/u/s!Auwy2_XWmERmm3mR3e6iFo8Lj_Od - can also upload a video of the behaviour if helpful.

Anyway, I'll try running an actual carving file tomorrow. Maybe it wont have so much of an effect, so long as I dont try to override the feedrate. Above looks like a bug to me, but apologies if I have missed something obvious. Still learning!

[MRob]

In case anyone is interested, I did more testing and I'm sure this is a bug. Compared to mach3, which ran the same model with g93's smoothly, no issues with feedrate jumps or caps. If anyone tests the linked file, issue is most visible when at the largest (third) diameter. So I wont use UCCNC for this purpose until it is fixed.

Aside I found another bug. I booted into default profile, homed, probed tool length, ran a file, stopped and closed it, loaded another profile, homed again, attempted to probe again and UCCNC drove the end mill at max speed into the touch plate. If I load to default, and then load in a new profile before doing anything else it is fine. Doesnt like profile changes I guess.

[cncdrive]

If you want us to check the issue which you reported then post your profile file and also a g-code file with which you can produce the issue and a few words about the issue, I mean how to exactly reproduce it and what to look for, then my collegues will check it out.

Profile changes have nothing to do with probing, but ofcourse different probing macros could do the probing differently, because different profiles likely to have different offsets which loads with the profile.
It depends on the macro, but it might be in relation with the probing code programmed endpoint in the macro or maybe the movement into the workpiece is an initial movement command which loads wrong coordinate from the software, but then it has to be a problem with the macro.
Or if you using the probing plugin then the same issue could be in the plugin.
You could post your profiles you initially loaded and which you loaded afterwards and the probing macro and some description about how to reproduce the issue, what to exactly do and then we will check this one also out.

[MRob]

I linked the gcode file in the longer post above, with full description there. As I said, I was able to just load the file into the AXBB test environment (different computer to my CNC machine) and watch the feedrate, see that the problem seems to show itself there as well. So if you just run the above file with any old stepper as the 4th axis, wait until it reaches the third diameter Z20 I think), and then reduce the feedrate down low, you should see the same issue. Or try increasing the feed rate, I expect you will see like I did that it caps out, and will not increase above a certain value. But I'll attach profiles anyway, and the macro file for probing (default first, then turning profile).

[ger21]

Is your rotary axis perhaps limited by the kernel speed?

[MRob]

Great question, although I am running an ABXX with max output at 400k. Even with the system I just swapped in today, which is 10k/turn, that still gives 2400rpm. With the issue about not being able to increase feedrate, it stays really slow, like 50rpm max.

[ger21]

Most stepper drives have a max frequency of ~200Khz, and may not run properly if you have UCCNC set to 400Khz, as the pulse widths are too short.
You might want to try lower settings?

[MRob]

It's good, data sheet says 200khz but it runs happily at higher with the output from my home made stepper signal generator (50% duty). Stepper itself can hit 2500rpm without difficulty (closed loop nema34), which is over twice the spec. Frequencies coming from the AXBB are much lower during normal use, of course, though I am not sure precisely how it outputs the signal - probably 50% duty as well, as I haven't seen options to set the pulse width, and I've never had issues with the pulse width being too short for other lower spec stepper drivers. I'll keep steps/rev high unless I have to reduce, keeping everything as smooth as possible at low speeds is a priority. I used to run lower microsteps with previous steppers, but the vibration could actually work the chuck loose over long programs. Very annoying. 8k/turn (geared to 10k) is probably overkill, but hey, works!