@argo Update on this issue: using the curve smoothing solves the problem. Also, I made a copy of the original STL using solidworks, exported it as STL but using max quality for the STL and also the print came out PERFECT.
So all this issue is about the STL quality
Thanks all for the help

@chimaeragh Sure. For example, when I want to save the total uptime of the machine I execute count.g:
echo >"uptime.g" "global.ontime =",{global.ontime + state.upTime/60}

This saves in uptime.g the value of the global.ontime, and I get that value from the object model

Next time the machine restarts, in config.g I have a M98 P"uptime.g", so the value of the global variable is read again and keeps being incremented.

@Falcounet Today I tried again and this time connection was ok... weird. But problem is fixed. Thanks!

@blv there is no need to teach formulas or motion theroy, at least to me, Im a senior mechanical engineer, I guess I have those topics very clear. So Im pretty sure you can post your slicer profile, your config, and the STL so we can all see the sizes involved and it will be very simple to demostrate what I said is correct. But we can also do very super quick calulations looking the video: the size of the object is aprox 12 cms long. I has a soft cuve too. so lets say that segment is a real 15 cms as much it it is straight? If you print at 500 mm/s that means we should be watching your printhead cover those 15 cms in aprox 1/33 of a second without taking into consideration the acceleration. If we take into consideration the accel of 9000 you will reach something around 300 mm/s of max speed AND ONLY for a fraction of the path. Im dpoing all these calculation by my eye so I might be wrong in 20/50 mm/s max error.
And Im still not taking into account your jerk settings.
And this is the speed you get in your longest path, the rest of your STL model wont get even half of the calculated speed I have mentioned.
So...

And Im not fan of nobody. I use what I considere that covers my needs. I have used klipper. It is based on python, python uses an interpret to work. That means an extra layer between klipper and the processor. So it works very nive, but no software till today is as fast as a well C++ / C code is working directly with the processor... Or have you ever seen an OS written in python ?

The firmware duet is working on is really powerful, enough for me moving from marlin.

But hey... if you are fine with klipper, OK! keep using. You have to use whatever covers your needs man.

Also I think it would be usufull if you clear what you mean with "extra perfomance", it would be a good way to contibute here to the developers.

@davidewen @dc42 There are several post about this issue with heated chambers.
In my case the problem raised with version 3.3 and up. Something changed on that PID implementation. Before that, my heated chamber was using the old PID very good.

After I upgraded, the problem raised. So I tried to autotune again and I was getting the same errors like you. After playing a while, what I did was: I raised deadtime value A LOT. That way, autotune was able to finish.

BUT then it didnt worked: the values I got from autotune, should have worked but every time I tried to heat up the chamber, an error was there: temp rising too slowly.
Running autotune several times worked again, but then again, using the reported values always failed with the same error.

Then I did a trick: I ran autotune but using ONLY 80% of the PWM. Then to the reported values I changed the PWM to 100%. That is the only way I have been able to use PID on the heated chamber

I hope it helps

Im my case, the times this exact thing happened to me, was a bad connection on my thhermistor cables, a badly soldered crimp. Resoldering always solved my problem. This problem was never detected by eye, the graphics is the one that have indicated me the problem.

@chrishamm I solved the problem (so close the topic as solved please). I dont know the causes but this is how it is working now:

.- In config.txt I commented the line

#disable_fw_kms_setup=1

By doing this and rebooting, I can see the raspberry logo at boot but then again all goes white and stays there

So again in config.txt I made the change:
dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d

And these 2 changes solved the problem. Everything in "normal " now, The camera is not working either but it is detected.

On the other printer I checked, and disable_fw_kms_setup=1 is not commented... Documentation says this uses kernel defaults. So my guess is since the difference between both raspi images is the date and I can see a difference on kernel vlaues, there is something internal that makes all this trouble to me.

Either way, it is solved. Thanks for the help

@fcwilt because I planned the printer to have eough power to have all the build plate full of print, and since it is a big volumen, theoretically I can have like 15 kgs if I print metal. So Z motors have enough power to move that mass.
BUT, if something goes wrong, the also have the power to destroy my hotenfd and bend the bed if the printhead crash against the bed at full powwer. By reducing to 30% while homing, if something goes wrong, they will start to loose steps before bending my bed.

Hello. I have checked https://github.com/Duet3D/RepRapFirmware/wiki/Object-Model-Documentation#statestatus

I see "printing" status is not there anymore. It has been replaced for what other value?

his property may be one of the following:

disconnected: Not connected to the Duet
starting: Processing config.g
updating: The firmware is being updated
off: The machine is turned off (i.e. the input voltage is too low for operation)
halted: The machine has encountered an emergency stop and is ready to reset
pausing: The machine is about to pause a file job
paused: The machine has paused a file job
resuming: The machine is about to resume a paused file job
cancelling: Job file is being cancelled
processing: The machine is processing a file job
simulating: The machine is simulating a file job to determine its processing time
busy: The machine is busy doing something (e.g. moving)
changingTool: The machine is changing the current tool
idle: The machine is on but has nothing to do

simplify is not worthy anymore . The "new" features they have added to version 5 have been present on free slicer for about some years already.

Hello. due3 board, SBC mode with 3.5.4

I have this on my daemon.g

while global.daemonactive
	if state.status != "processing"
		if (heat.heaters[0].current > 60)
			M42 P3 S1
		else
			M42 P3 S0
	G4 S2

I have this because in some situations I prefers to set the variable to false and so stop daemon from working instead of renaming the file. Not really much use. But today I edited daemon.g nd I just added an echo command. I saved the file. So I was expecting to see the echo command being executed and the result on the console. It never happened. I went crazu ike for 10 minutes trying to find a typo mistake, or something. The echo command was never being executed. I checked the global variable value and it was ok with a true value.

The echo command was in the else section. The M42P3 S0 was being executed, I know that because that switch turns off and ON a led. If I manually executed the M42 P3 S1 command (with all heater off and coldf) I could see the led being turned on and after 2 secs daemon.g tuned it off. So daemon was working, the if sentence was ok. The echo command was just not being executed.

Then without any modification I restarted the printer. And this time everything worked as expected. I sidenly started to get the echo command results on the console.

So, It looks like the daemon.g is not being updated if you edit the file. Tjhe file is updated, but the daemon alredy on memory still is the old one?

Im doing something wrong to update daemon.g? starting it and stopping it using the variable works ok

@chrishamm I solved the problem (so close the topic as solved please). I dont know the causes but this is how it is working now:

.- In config.txt I commented the line

#disable_fw_kms_setup=1

By doing this and rebooting, I can see the raspberry logo at boot but then again all goes white and stays there

So again in config.txt I made the change:
dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d

And these 2 changes solved the problem. Everything in "normal " now, The camera is not working either but it is detected.

On the other printer I checked, and disable_fw_kms_setup=1 is not commented... Documentation says this uses kernel defaults. So my guess is since the difference between both raspi images is the date and I can see a difference on kernel vlaues, there is something internal that makes all this trouble to me.

Either way, it is solved. Thanks for the help

@chrishamm yes, that is what I have:

max_usb_current=1
hdmi_force_hotplug=1
config_hdmi_boost=10
hdmi_group=2
hdmi_mode=87
hdmi_cvt 1024 600 60 6 0 0 0
enable_uart=1
dtoverlay=disable-bt

Will continue looking, I have 2 more hs for a print to finish so then I can copy the sdcard from that printer if I can find a solution before that.

@chrishamm I have checked and that is the config Im using. In those instructions, i fguess it doesnt matter because they dont talk about bookworm, the ask for changing the overla.
On 1 of the working prointer i have checked OS version and I have this:

No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm

So it is using bookworm. On that printer, confg.txt is using this:

Enable DRM VC4 V3D driver

dtoverlay=vc4-fkms-v3d
max_framebuffers=2

So in the printer it is "failing" you ask me to go back to kms? will try (but it was like that at the first boot and wasnt working)
The other setting are checked and in place.

@chrishamm Yes, that one, without the case (either way both are identical, difference is just the plastic caseing).
Previously the solution on the other printer with the "older" image was the config posted there: dtoverlay=vc4-fkms-v3d
This time that solution is not working.

@chrishamm The prpblem is not with the touchscreen, the hole screen just dont turn on.
Regarding https://www.waveshare.com/wiki/7inch_HDMI_LCD#Software_Setting: no, my model is a 7inch hdmi lcd (H), not that model, but I can give a try a guess?

@Electriceye Thanks for the comments. Problem with your theory is: I have 3 other printer running 3.5.4. Some config, same hardware, some everything but the image version: 2 of them are using 3.5.4 version but have been upgraded to latest everything (firmware and raspbian). The other printer received a frsh new raspi image downloaded like 2 months ago, there were some issues with those images, I report them and there were fiexed. In that printer I had the same issue as know but solution was super easy: just changing a line on config.txt.
This printer now is using an inamge downliaded like 2 or 3 weeks ago, I tried to copy the config, as far as I know it is the same as in the others, but it doesnt work. I know the screen is ok because it works if I connect a usb to the power port.
So definitly it is just something regarding configuration.
Im thinking about just coping the sd card from the other printers and use that, but... im the kind of guy who finds a problem and wants to really solve it but this one is getting difficult lol

@T3P3Tony thank for the reply. Im using a raspi 3 b+ and the 32 bits image, the 64 bits version has a really bad impact on the perfomance of this raspberry pi.

Hello. Im using a waveshare 7inch (H) hdmi touch screen . Iworked ok with all versions of duet pi . On one of the last updates i had troubles, but after some cnfig I made it work. There was a problem with that image wich I reported and then was solved (by crisham I think?). Now I have downloaded the latest image, the touchscreen is not working (it is just black , seems to never turn on) and the config it worked before now it is just not working so maybe there was something new on the image?
has somebody else had the problem?
Thanks in advance (duet3, sbc mode, latest firmware 3.5.4)

@T3P3Tony I dont have any printer on stand alone mode.