I would like to have auto-scaling of temperatures graph - would make tracking lower temps easier.

Perhaps it would be also nice to have dual-scale - left scale for tools (usually higher range), right scale to heatbed/chamber (usualy lower range).

@EducatingSavvas

If state.gpOut[3].pwm==0
	M42 P3 S1
else state.gpOut[3].pwm==1
	M42 P3 S0

condition in else is obsolete, and more "elegant" way is

If state.gpOut[3].pwm != 0
	M42 P3 S0
else
	M42 P3 S1

It would be nice to have recursive delete for non empty directories.

Probing twice the same point?

G30 P0 X26 Y226 Z-99999 ; probe near an adjusting screw
G30 P1 X26 Y226 Z-99999 ; probe near an adjusting screw

@dom I think latest paneldue will not work properly with 2.05.1 firmware. Update Duet firmware to 3.2.2

I think that viable solution would be to use NFC tags and a spool holder with reader. With new spool just put a nfc sticker (can be bought easily) and set a filament length when spool used for a first time.

Then each time spool in put on spoolholder read the tag, and update legth when print finished/tool change/ etc

Easy to implement - nfc readers are available with many intercaes, tags can be bought without problems.

Finally G10 support?
I wonder what are the actual changes in this new g code flavor.

https://github.com/prusa3d/PrusaSlicer/releases

Out of pure curiosity, I just checked on my printer (Duet3, standalone, 3.2-b1), and seems to be just fine.

I am getting popcorn
This is getting ridiculous.

It is so hard to understand, that older hardware is not capable of handling new features?

@MartinNYHC M208 X0 Y0 Z0 S1 instead of M208 X77 Y84 Z0 S1

@kotuo I see disconnection reported only for driver 2 - which drives Z axis. Do You have jumpers on the second Z motor connector?

@dc42 This is just a transoptor (Prusa MK3S filament sensor). I just disabled it for now. Not essential feature as I am using magnetic filament monitors. It was used only for loading filament. I have filament loaded when I can see false triggers - no light is going through sensor, so output is in low state.

@dc42 Yes. Reverting to 3.2.2 fixes that strange behavior. I tried 3 times. I did not try intermediate versions to identify which one introduces that.

Edit: This behavior is in 3.3beta1

@dc42 I would think that is the case if such behavior was also on 3.2.2, but with 3.2.2 it works just fine without false triggers.

I noticed a strange behavior after I updated from 3.2.2 to 3.3RC2.

I have a filament presence switch that I use for triggering filament load macro.
After I updated to 3.3RC2 it seems to be a lot of false triggers.
Powering up printed, it does nothing for about 3 minutes and suddenly starts triggering and display messages:
Error: Attempting to extrude with no tool selected.

I do not need to start print or do anything. Just power on printer and wait.

Duet3 standalone setup.

My config files:
trigger3.g
config.g
fs_enable.g
fs_disable.g
fs_config.g

I noticed that one of my macro causes error when it thies to disable DAA using command M593 F0, as documented in gcode wiki:
"Fnnn Frequency of ringing to cancel by DAA, in Hz. Zero or negative values disable DAA"

M593 F0
Error: M593: parameter 'F' too low

and DAA is not disabled.

Also executing M593 F0 during print caused print to stop, but not same way as pausing it. After pause-resume on web gui print is continued properly.

Duet3 3.3-RC1 standalone.

@dom I think latest paneldue will not work properly with 2.05.1 firmware. Update Duet firmware to 3.2.2

Should the keywork be 'end', or something else?
I think I would use

if condition
           then
                       if given condition true
                       execute all commands up to else statement
                       or to fi if there is no else statement

           else
                       if given condition false 
                       execute all commands up to fi
           fi

and

while condition
do
   command1
   command2
   command3
done

Should it be permitted to mix keywork-delimiting and indentation-delimiting in the same file? If so, what problems might arise, and what restrictions should be enforced?

IMO indentations should be allowed just to keep it more readable, but ignored in processing code

How should the user indicate to the firmware that a loop or conditional is to be delimited by a keyword instead of by indentation? One option is to have a new command keyword (e.g. 'noblockindent') that means that for the remainder of the file, keywork-delimiting will be used. Using that keyword when already inside a block would probably have to be banned. Another option is to use different variations of 'if' and 'while' (e.g. a different keyword or some extra character) to indicate keywork delimiting for that command.

I would drop indentations for indicating clode blocks

@JPS0284 Buy pt100/pt1000. Better than any thermistor.

@dragonn

@dragonn said in My wish : Inputs debouncing:

I just wanted to say that something simple from user stand point isn't often so simple in the software

I know. I have over 13+ years of embedded development in my CV. Bare metal, RTOS, Linux, Qnx and VxWorks. I am just too lazy to setup RRF build at my home computer after all day of work