Maximum number of axis?

Kulitorum

How many channels can the duet3 control at once? - I know that the duet2 will do 10 axis, what is the limit for the Duet3?

Kulitorum

dc42

Still 10 axes, using axis letters XYZ UVW ABCD. After that we run out of axis letters that are free for use in GCode commands.

Kulitorum

So it's not possible to do 15 axies? - even with Duet3?

Kulitorum

dc42

If we can work out what to call the additional axes so that they can be addressed in GCode commands, then we could support more axes on Duet 3.

I guess one possibility would be to have a switch that makes axis names case-sensitive, then we could have up to 20 axes.

Have you any other suggestions?

Kulitorum

Xa Xb Xc, Ya, Yb, Yc ?
D,H,I,J,K,L,M ?

dc42

@Kulitorum said in Maximum number of axis?:

Xa Xb Xc, Ya, Yb, Yc ?

G28 Xa would be ambiguous.

D,H,I,J,K,L,M ?

D is already used for the 10th axis. M is not available because it would start a new command. I and J are used in G2/G3 so not available. K is not available because G31 uses both K and axis letters. Off the top of my head I'm not sure about H or L. Q might also be available, I think it's currently used only in M950.

Another possibility is 'A 'B 'C etc. RRF already allows a single quote inside a double-quoted string to force the following character to lowercase, so internally within RRF they would be unique letters.

What program would you use to generate the GCode?

Kulitorum

But when reading for example a G31 command, you then start looking for K parameter, so why would G31 reserve the K parameter?
We use our own slicer and we are adding a second printhead, adding effectivly another X,E,U axis (Xpos, Extrusion, Nozzle rotation) are are investigating adding two more printheads.

dc42

@Kulitorum said in Maximum number of axis?:

But when reading for example a G31 command, you then start looking for K parameter, so why would G31 reserve the K parameter?

G31 also accepts axis parameters to declare offsets.

Kulitorum

So I suppose the lowercase - 'A 'B 'C etc. solution would be the prefered then? - That would release 26 extra axies.

how many axies do we have CPU power to drive?

Kulitorum

dc42

@Kulitorum said in Maximum number of axis?:

So I suppose the lowercase - 'A 'B 'C etc. solution would be the prefered then? - That would release 26 extra axes.

Yes, I think it's probably best to use 2 characters for additional axes, either 'A 'B 'C etc. or perhaps QA QB QC because currently letter Q isn't used in any commands that accept axis letters.

how many axes do we have CPU power to drive?

Good question! It will depend on how many GCode commands per second throughput you need, and how many of your axes and extruders move simultaneously.

Kulitorum

I guess we will at most move 9 axies at the same time - XYZEU, 'X'Y'E'U for a two head move - in 1-2 years maybe 18 (with 4 heads)

We have a vertex for every 10mm in the XY plane, and run at 500mm/sec (working towards 1000mm/sec, give it a year)

Kulitorum

JoergS5

Maybe using unicode letters would be an option, using greek alphabet e.g.

dc42

@JoergS5 said in Maximum number of axis?:

Maybe using unicode letters would be an option, using greek alphabet e.g.

Yes, that's a possibility too. However, it's not entirely straightforward because we would need to use a mixture of UTF8 encoding (for incoming GCode lines) and wide characters (se that we can pass axis letters around conveniently).

Overall, I am inclined to use some prefix character followed by another letter. The prefix character could be ' or @ or something else.

I've added increasing the maximum number of axes to the RRF 3.2 work list.

mwwhited

@dc42 what about a binary mode that uses a faster more native access to the hardware versus worrying about GCode at all? It could be variable or fixed length and would open a wide world of options.

It wouldn’t be standard GCode but who cares. This is for the computer to understand not humans.

Without the parser is could be crazy fast and even use less memory.

Yes new slicers would be needed (already covered for OP) but it could be optional or better still just transpile from GCode to this format in the duet or sbc.