Major performance problem

T3P3Tony

@spw thanks for the report. Are you able to downgrade to 1.21 for now. @dc42 will need to look into this further when he is back from holiday.

spw

In 1.21 there is an additional bug that merges the second line at speed 300 although it does turn off the laser before switching to speed 700. Like in 2.0 first 2 segments at the higher speed are missing.

3DPMicro

T3P3Tony,
Sorry to see folks with issues they anxiously want resolved but glad to see dc42 is taking a well deserved rest.

dc42

Please remind me of this issue when I return.

spw

@dc42 said in Major performance problem:

Please remind me of this issue when I return.

reminding, let me know if you need more logs or setup code

dc42

I think I can see the problem. When commands such as M3 and M5 are interspersed with movement GCodes, the movement GCodes go into one queue and the other commands go into another with a maximum length of 8. I think that second queue is getting full. That is likely to happen if you have more than 8 M3 and M5 commands within a time of 2 seconds + one move. At the slower speed each dashed line takes two seconds and you have 6 M3/M5 commands, so the queue doesn't overflow. At the higher speed, there are about 12 M3/M5 commands within 2 seconds, so it does.

In firmware 2.02 I already plan to rewrite the code to pass critical commands such as M3 and M5 in the movement queue, and at the same time allow laser cutters/engravers to use a parameter on the G1 command to control the laser. For version 2.01 I will see whether it is possible to suspend the processing of new moves while the secondary queue is full.

Catalin_RO

@dc42 My two cents on the problem... What if G0 is with laser off and G1, G2 and G3 are with laser on? In the end that is the original meaning of the commands: G0 for quick move between machining points and G1/G2/G3 for movement when actually machining!

spw

This post is deleted!

spw

Suspending move when the queue is full would be risky as if it happened when the laser was enabled at the full power it would burn a hole or even start a fire is set in one place for too long.
Adding PWM parameter to G1 command would be ideal as this is what Laserweb generates by default. M3 and M5 are used in Marlin compatibility mode.

dc42

I don't think suspending adding moves to the queue would be risky, because this will only happen when there is a M3 or M5 command pending that can't be queued. I already implemented this yesterday.

Support for using the S parameter to control laser power on G1 moves will be added in firmware 2.02.