@dc42 thank you very much!!

@dc42 I managed to up the number of MaxSpindles successfully

To my second problem: I found the error "Port must be on main board" in the IoPorts.cpp file. However I don't quite understand how I can bypass this restriction. Is it even possible?
What I mean: is the firmware set up to allow spindles on expansion boards and you just blocked this feature? Or isn't this implemented in the code at all?
If it is possible to avoid this limitaion by changing some code, could you please tell me where I need to look or what I need to change?

@dc42 I should be able to do it myself. I would be very thankful if you could give me a walkthrough on what I need to do.

I have 8 lasers that I need to turn on and off individually and each of them will have a different power output every time they are turned on. Therefore I need to define each as a spindle so I can control them with M3 and M5. Depending on the direction my toolhead is moving multiple lasers with different and also altering power output need to be on at the same time. To make it easier for me to control them I need every laser to be defined as a different spindle because this will happen very often and quickly during movement. If I had 8 spindles defined that would solve the first big issue I'm having.

The second one is that I only have 2 empty PWM connectors on my 6HC board. I also have a 3HC board, but I can't use these PWM pins. When doing:

M950 R1 C"1.out1" 

I get:

Error: M950: Port must be on main board

Is there a way to make this work? Would it be possible to use a PWM pin on a Sammy C21 board?

@jay_s_uk I see, is there an "easy" way for me to up the max amount of spindles to at least 8?

The remapping is a little too slow for the use-case I have. I assume it is not planned to remove the limitation of the other boards as of now? If that was possible it would solve all of my issues

@chrishamm @jay_s_uk
I tried that and it is possible with a little work. However I have multiple lasers that I need to control individually with different PWM values for each of them so a multiplexer doesn't work for me.

I only have 2 empty PWM pins on my 6HC board that i can use to setup the lasers as spindles with M950 and control them with M3 and M5. When doing this i have this error when the R value is higher than 3:

M950 R4 C"io5.out"
Error: M950: parameter 'R' too high

Also is there a way to use the PWM pins on an expansion board (I have a 3HC) to configure the spindles on there? If I try to do this it tells me it is only possible on the main board. And is it possible to get 5V PWM instead of 3.3V?

@chrishamm The with the M400 command the M3 and M5 are executed at the right timing, but there is always a little standstill during movement, which I'm trying to eliminate.

is there any other way to sync the queues?

I'm not sure if It would work with the firmware facilities, but I will look into it. The main problem is the way that I need to interact with the multiple lasers in the future.

@chrishamm There is a flush programmed by my colleague that looks like this:

# Check for the type of the code
            if cde.type == CodeType.MCode and cde.majorNumber == 3:
                # --------------- BEGIN FLUSH ---------------------
                # Flushing is only necessary if the action below needs to be in sync with the machine
                # at this point in the GCode stream. Otherwise it can an should be skipped

                # Flush the code's channel to be sure we are being in sync with the machine
                success = intercept_connection.flush(cde.channel)

                # Flushing failed so we need to cancel our code
                if not success:
                    print("Flush failed")
                    intercept_connection.cancel_code()
                    continue
                # -------------- END FLUSH ------------------------

I don't know if this is the right way to do the flush.

When looking at the GCode lines with the GCode viewer it appears to "skip" or rather process all the lines except the "Internal infill with laser on" line all at once. So the lasers turn on during at random point during these movements.

I also forgot to mention that the RPi controls an Arduino MEGA which then turn controls the lasers, if that is important for my problem

I updated my system to the newest beta version available, but it didn't change the timing of the execution of the M3 and M5 commands.

I need further help please.

@jay_s_uk
sorry I misunderstood that. You're right I saw that. But is the implementation of M3 and M5 into the FDM mode changing the queueing or execution order of those commands. The plugin and the commands work perfectly in my setup. The problem occurs only when called from a file. he commands are still executed as intended, but not at the right order as they written in the file.

Thank you, I will certainly update to the newest stable version, but I didn't see any solution to my problem in the changelogs.

Here is a GCode snippet

;TYPE:External perimeter
G1 F1500
G1 X120.225 Y92.725 E0.37911 ; External perimeter
G1 X179.775 Y92.725 E1.55162 ; External perimeter
G1 X179.775 Y107.275 E0.37911 ; External perimeter
G1 X120.285 Y107.275 E1.55006 ; External perimeter
;WIPE_START
M204 P3500 T800 ; adjust acceleration
G1 X120.425 Y106.929 F21000 ; move inwards before travel
;WIPE_END
M204 P1000 T1000 ; adjust acceleration
G1 X120.768 Y106.544 ; move to first Internal infill point (minimum acceleration)
;TYPE:Internal infill
;WIDTH:0.455097
G1 F4800
M3 P1 S10 ; Laser on
G1 X176.232 Y106.544 E1.4615 ; Internal infill with laser on
M5 ; Laser off
G1 X179.232 Y106.544 E0.07905 ; Internal infill with laser off
G1 X179.232 Y106.126 F21000 ; move to first Internal infill point (minimum acceleration)
G1 F4800
M3 P5 S10 ; Laser on
G1 X123.768 Y106.126 E1.4615 ; Internal infill with laser on
M5 ; Laser off
G1 X120.768 Y106.126 E0.07905 ; Internal infill with laser off
G1 X120.768 Y105.708 F21000 ; move to first Internal infill point (minimum acceleration)
G1 F4800