QTPlasmaC with fourth axis - rotary

@LesNewell does the post processor take care of the faster feedrate for the A axis when cutting over the corners? If so by what ratio must the Axis be faster to be able to do a reasonable cut?

The last posted pipe_2023_06_26 appears to work with the current changes albeit it is a little large for my tube. 

There is one issue at the beginning of the circle:A is set to -90 in line N0110 and after the lead-in it is set to 270 in line N0180
It may be my setup but it does a complete revolution here so I changed N0110 to 270 and it seems OK.

I have pushed a test branch named phillc54/plasmac-tube with what I have so far which is only the basics. It includes the latest pipe.ngc file in nc_files/plasmac

There seems to be a problem with the feed rate of the rotational axis on the last bit of the cutting. It seems to slow down over the corners instead of speeding up.

mariusl wrote:

@LesNewell does the post processor take care of the faster feedrate for the A axis when cutting over the corners? If so by what ratio must the Axis be faster to be able to do a reasonable cut?
 

Yes, SheetCam varies the feed rate when cutting around the corner. The exact speed for each axis depends a lot on the tube corner radius. I generally recommend that the rotary axis be capable of 200RPM and the linear axes 10m/min (400IPM).

Looking at the test run there does seem to be something odd going on with the feed rates. I can see it in simulation here. I'll investigate further.

After more testing the feed rates in the code look correct. The slowdown I was seeing in SheetCam's sim is simply the simulator not being able to process movement blocks quickly enough. I need to upgrade the rotary simulation to use the new simulator engine used by 3 axis simulation. According to the code all of the corners apart from the one at 0:11 should be cut at around 20000-25000 units/min (I say units because it is a combination of linear and angular movement). The corner at 0:11 is has a lower feed because a lot of the movement is roughly parallel to the edge, unlike the rest which are closer to perpendicular. 

Phill, I have attached a version of the code that includes feed on every line. It may help you figure out what is going on.

There seems to be two issues at play here:

1. My little rotary table is only capable of 150°/sec which is 25rpm
2. LinuxCNC has poor path planning for axes other than X, Y, or Z

I made an AXIS sim with axes X, Y, and Z having max velocities of 30M/min (500mm/sec) and axis A having a max velocity of 200rpm (1200°/sec) and the result was fairly ordinary as far as I could observe.

EDIT: I have attached a halsampler capture of the A axis velocities for the second cut from the above sim.

I think we need to test this on a machine with a decently fast fourth axis. Marius, it's probably up to you for this.

Phill, just out of interest how do the A axis velocities compare to the first cut?

I found Mach3 works more smoothly with the rotary axis configured for 1 unit per rev instead of 360 units/rev. Do you think this would help here?

LesNewell wrote:

Phill, just out of interest how do the A axis velocities compare to the first cut?

I didn't plot those, I can do tomorrow.

I found Mach3 works more smoothly with the rotary axis configured for 1 unit per rev instead of 360 units/rev. Do you think this would help here?

TBH I don't know if that is possible, I assumed angular joints/axes needed to be degrees.

This is from the docs:

TBH I don't know if that is possible, I assumed angular joints/axes needed to be degrees.

I generally recommend that the 4th axis is defined as a linear axis rather than angular. I'm not sure about LinuxCNC but some other controls treat rotary axes differently to linear axes. Functions such as rotary axis diameter compensation or 360 degree rollover can cause all sorts of unexpected issues.