M command timing is off when executed from GCode file

jay_s_uk

@nkts i would suggest that you first upgrade to 3.4.5 and see if you're still affected.
Also, 3.5b3 allows the use of M3, M4 and M5 in FDM mode without having to switch to Laser or CNC mode so once 3.5 is released you won't need to use any custom codes.

nkts

@jay_s_uk

I'm not switching to Laser or CNC mode. We only used M3 and M5 because they are not supported in normal FDM mode. We could also use M6 and M7 for example. I still need the costum plugin because I have more than one laser und some other things I am executing with the plugin an not supported M commands.

Maybe the update will help, but I need confirmation that it indeed will or that there is a realistic chance it will because it is an R&D project and I don't want to change anything in a running system that isn't necessary.

nkts

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

jay_s_uk

@nkts i said you can use M3, M4 and M5 without switching to Laser or CNC mode in 3.5b3.
but you definitely want to look at upgrading as DSF has undergone some significant improvements since 3.3 (which was released almost 2 years ago!)
Have a look here at the DSF changelog https://github.com/Duet3D/DuetSoftwareFramework/wiki/Changelog-DSF-3.x
And here for the RRF changelog https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x

nkts

@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.

jay_s_uk

@nkts i know there were issues with out of order processing certainly in 3.2 but i can't remember if they also existed in 3.3.
The python plugin has also been updated to improve the handling from 3.3

nkts

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

@nkts one for @chrishamm

chrishamm

@nkts Does your plugin flush the corresponding code channel before you actually handle M3/M5? This step is crucial due to the buffering mechanism used in SBC mode. See here for a good example how custom codes should be implemented.

nkts

@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

chrishamm

@nkts Perhaps you need to execute M400 as well in your M3 implementation after flushing the codes in order to wait for the last moves to stop - RRF also has a movement queue, so you need to sync with that, too.

Why don't you use the built-in RRF facilities to control the laser? It's generally better to perform motion-dependent commands right in the firmware.

nkts

@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

@nkts That's why I suggested to use the firmware facility instead - the SPI link between SBC and Duet is no realtime feature (yet). You can always remap the laser port dynamically or multiplex the Duet PWM port using a different command.

nkts

@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?

jay_s_uk

@nkts looks like the maximum amount of spindles currently is 2 (or maybe 4 in the current beta?) https://docs.duet3d.com/User_manual/RepRapFirmware/RepRapFirmware_overview#firmware-configuration-limits:~:text=number of triggers-,MaxSpindles,-2

You could get round this by unmapping a spindle before using another one.

The spindles on CAN boards is a limitation I believe. Not sure when it will be removed though

nkts

@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

jay_s_uk

@nkts you would need to ask @dc42 to increase the quantity

dc42

@nkts if you are set up to compile RepRapFirmware then you could increase that value yourself.

I can look at increasing the maximum in the next 3.5beta release. Can you explain your use case for 8 spindles?

nkts

@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?

nkts

@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?