Is there a limit of 10 axis labels ?

Behrouz-AKT

Hello All

I have two Mini5+ (Wifi) with the seven drives each. The second is a set as an expansion board. I am using SW version 3.4.6

I need 11 axis labels and I can only create 10 . I am using 'j and 'k labels but the 'j don't show as its the 11 axis label. I also tried W with the same results .
M584 returns 10 only . attached is portion of the my config .g

;  CoreXY design
M669 K1 ; switch to CoreXY mode
; CoreXY Drives 
M569 P0.0 S1                        ; X physical drive 0 goes forwards
M569 P0.1 S1                        ; Y physical drive 1 goes forwards

;Head Drives
;M569: Set motor driver direction, enable remote module
;eg M569 P1.0 S1 R1 	; change enable polarity, active = disable drive
; Left Head and motor configuration
M569 P0.5 S1                    ; Z1 (from Left side from front) goes backward  
M569 P0.3 S1                    ; A physical drive 4 goes forwards
M569 P0.4 S1                    ; B physical drive 5 goes forwards
M569 P0.6 S0      				; U - Z2 (Right side from front) goes backwards
M569 P0.2 S1                    ; C physical drive 5 goes forwards
M569 P1.6 S1                    ; D physical drive 5 goes forwards
; conveyor  drive
M569 P1.0 S1                    ; 'k back drives 
M569 P1.1 S0
M569 P1.2 S1                    ; V Center drive
M569 P1.3 S0
M569 P1.4 S1                    ; W front drive
M569 P1.5 S0
; *****  Core XY maps to 0&1 
M584 X0.0 R0	; X LIN
M584 Y0.1 R0	; Y LIN
;Drive mapping HeadZ1 - left 
M584 Z0.5 R0	; Z1 LIN
M584 A0.3 R1 	; A ROT
M584 B0.4 R1	; B Rot 
;Drive mapping HeadZ2 - Right  
M584 U0.6 R0	; Z2 LIN
M584 C0.2 R1 	; C ROT
M584 D1.6 R1	; D ROT
;conveyor system
M584 'k1.0:1.1 R0	; Back LIN
M584 V1.2:1.3 R0	; Center LIN
M584 'j1.4:1.5 R0	; Front LIN

here is the result of M584

2023-11-18, 11:19:55 p.m. 	M584
Driver assignments: X0.0 Y0.1 Z0.5 (r)(c)A0.3 (r)(c)B0.4 U0.6 (r)(c)C0.2 (r)(c)D1.6 k1.0:1.1 V1.2:1.3, 10 axes visible

How do I get the 11th axes?.
Thanks for your help

droftarts

@Behrouz-AKT see https://docs.duet3d.com/User_manual/RepRapFirmware/RepRapFirmware_overview#firmware-configuration-limits
As far as I know, the Mini 5+ is limited to 10 axes, and 5 extruders, though a maximum of 12 axes and extruders. I am slightly surprised you are able to use axis labels in the ‘a to ‘l range, but perhaps the axis labels don’t matter too much so long as they are in the expected range, though you haven’t used W.

I don’t know if this is an artificial limit to balance performance. You could ask @dc42 to increase the number of axes, or point out where to change it in the firmware for your application. The 6HC and 6XD support more axes as they have a more powerful MCU, and may be more appropriate for an industrial application.

Ian

Behrouz-AKT

@droftarts
Thank you Ian.

I see these limitations and these limitations may have made sense with Duet 2 but with duet 3 with CAN-FD expansion I don't understand why these limits exist. Expansion boards should not be counted toward these. I can have 4 expansion boards on Mini5+ which give an extra 12 drivers (using 3HC) + 7 on Mini5+. for a total of 19 drivers. Alternatively, I can have 4 Mini5+ expansion board (removing the termination resistor on three of them) for a total sum of (5*7) 35 drivers. 10 Axes is just too limiting

My application is openPNP and the requirements for PNP is very light ( just lots of little motors) not the same as 3D printing or CNC applications.

@dc42 Can you help with the location of the code - I can change it. Also interested in changing the maximum limits of CAN devices for these boards. Please let me know location and file to change. Thank you.

gloomyandy

@Behrouz-AKT Even though the drivers may be attached to a CAN board the mainboard still needs to manage them and plan movements for them all of which needs memory. I'm not sure how much free memory exists on the MIni 5+ (the 5+ has 256Kb of RAM the 6HC has 384Kb), but I suspect that this is the reason for the current limits. For a particular setup you may be able to increase the number of axis, but remember that RRF needs to support lots of different configurations and so the limits will have been selected with that in mind.

The limits if you want to try changing them are in this file: https://github.com/Duet3D/RepRapFirmware/blob/3.5-dev/src/Config/Pins_Duet3Mini.h

Behrouz-AKT

@gloomyandy Fantastic, thank you . I see the limits and will start experimenting. With CAN-FD. I am planning on sending a simple command as it will be a custom board. I t will receive the command of the CAN bus, process the command and ack back to main. I could have over 50 of these little boards. They will never be accessed at the same time.

Are you saying that it must keep track of each even if they are doing nothing? Is there a specific file that a expansion board gets instantiated?

dc42

@Behrouz-AKT as Andy says you can increase the limits in the Pins_Duet3Mini.h file. The ones most likely to be relevant to you are MaxCanDrivers, MaxCanBoards and MaxAxes.

RRF assumes that a move may command all the drivers to move, so increasing these values will increase RAM usage. In particular, each movement record (DDA) will increase in size by 4 bytes per axis. However, there is a reasonable amount of free RAM on the Duet 3 Mini.

In versions of RRF prior to 3.5 it is not possible to increase MaxAxes above 15 because 16-bit bitmaps were used to keep track of axes. RRF 3.5 uses 32-bit bitmaps, so the maximum number of axes is 31.

If you need to control more than 31 drivers, but not all at once, then you could consider using M584 to remap one axis to different drivers depending on what you need to move. A possible disadvantage is that M584 waits for all motion to stop before it executes, which might be a problem for you depending on what you are trying to do.

Behrouz-AKT

@dc42 Thanks for your help. I only need 11 axis at the moment.

ON the CAN side and ignoring the axis issues if I add one additional CAN board ( with motor control ) then that will use an additional 4bytes and If I add 50 boards then that an extra 200bytes. Is that correct?

dc42

@Behrouz-AKT increasing MaxCanBoards to 50 will increase the RAM requirement a lot because of this line in CanInterface.cpp:

const unsigned int NumCanBuffers = 2 * MaxCanBoards + 10;

Each CAN buffer is around 80 bytes long. The reason it is chosen this way is because of this line in CanMotion.cpp:

return CanMessageBuffer::GetFreeBuffers() >= MaxCanBoards;

The purpose of these lines is to ensure that if a move requires motion from drivers connected to all boards on the bus, there will be enough CAN buffers available to send messages to all of them. If you definitely won't be doing that, you could change these two lines and use a smaller number of CAN buffers.

Behrouz-AKT

@dc42 Thank you. I will have to spend some time with the code, this is very helpful.