I'm thinking of what it takes to add 4th axis support to LW4's CAM.

I’m thinking of what it takes to add 4th axis support to LW4’s CAM. I need a reliable way to control surface speed. Let’s say I compute a factor “Q” (deg/mm) based on stock diameter (varies with job) and roller diameter (varies with machine). I use this to generate X (in mm), A (in deg) moves. User says they want surface speed to be 500 mm/s (F). How do I tell smoothie what “Q” is so it can maintain (within acceleration limits) 500 mm/s surface speed and scale back the laser properly when it has to slow down?

This is “laser on a cylinder” correct ? You’ll still only be using two axes right ? Y and rotation ? Then it really shouldn’t be any different from XY motion.
If you are talking proper XYZA CAM then we don’t have any way to do what you are talking about, expect if you do the math in advance and just use F to setup speeds to match all your requirements.

Yes. Laser on a cylinder, 2 axis. XA motion is different from XY motion since F (mm/s) has the wrong units for A (deg).

I’d expect the CAM knows the diameter, so you are really working on the surface, and it’s really XY, with both units being millimeters, no degrees at all.

If A’s units were mm then A’s steps-per-mm setting would vary between jobs.

Yep, there’s a gcode for that :slight_smile: I think it’s the best solution.

Oooh. I thought steps-per-mm was a config file setting.

It is, but you can override it with a gcode

M92? Example shows it with E; does it also work with A?

I think so yes.

Fantastic! If I pass it a negative value will it invert the axis?

I’m not sure :slight_smile: we’d have to test that

no negative M92 will not work. and yes the value can be degreess/step it is irrelevant it just steps the set amount in synch with the XY move. ABC is not in edge it is in a PR which you will need to fetch and compile as specified in the PR notes… ABC is handled as per standard NIST gcode specifications (look at linuxcnc). https://github.com/Smoothieware/Smoothieware/pull/1055

Does F control A like it does XYZ?

as per the gcode spec yes.

+Peter van der Walt it will be merged soon it needs just a bit more testing as there were a lot of changes, i added homing for abc, and some other improvements

Let’s make sure my understanding is correct. Assuming everything calibrated to mm:
G0 X0 A0
G1 X100 A100 F100

Will the 2nd line run the X and A motors at 70.7 mm/min, just like I had used XY instead of XA?

Edit: mm/min not /s

+Peter van der Walt generally people will need to compile these for themselves as you need to specify how many axis you need. However I can post a 4 axis CNC version as that seems to be what is needed here. There are also some notes on the changes in this version and how to specify the 4th axis, do you have somewhere you can put the firmware and the notes?

@Todd_Fleming Yes, but the A is not necessarily mm/sec it could be degrees/sec but basically what you are saying is that X moves 100mm and in that time A will also move 100 degrees (or mm) in synch and the time will be 1 minute (F is mm/min not mm/sec)

Then my understanding isn’t right since the equivalent XY move would take 1.4 min. The A axis doesn’t obey F the same way XYZ do.