Best posts made by Tinchus

@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

Sorry for the late update. In my case problem is solved. I used the spyglass plugin. I got it from here: https://plugins.duet3d.com/plugins/SpyglassWebcamServerPlugin.html

The build instructions... never used them. I just downloaded the pluging, intalled through DWC interface, on the general settings I completed the url http://printer2.local:8080/stream (later I noticed theat hostname was automatically replaced by the internal ip number)
And it works perfect.

The raspi image I have is a brand new one, nothing extra installed or removed but userland in order to have some commands to verify the cam that seems to not be installed by default:

sudo apt install cmake
git clone https://github.com/raspberrypi/userland
cd userland
./buildme
sudo cp build/bin/* /bin/
sudo reboot
and then tested camera with raspistill -o image.jpg

I really dont know if userland had any effect on camera installation but since bookworm removed any easy way to activate/deactivate the camera (to the level of knowledge I have at least) I installed userland in order to have some debugging on the camera. With raspistill at least I knew the camera was there and detected and then I just installed the pluging
I hope it helps

@fcwilt so far I got a tempral solution till I find a proper solution, I modified the start gcode to position the sensor out of printbed and so it doesnt get all the heat, I leave door open so chamber doesnt get hot. After probing I tape the pin to be sure it stays up, then close the door as soon as print start. LOL

I looked for info and I found it: https://reprap.org/forum/read.php?1,873463,873463 reports something very similar. There are other similar posts on other forums too. and the nice find is:
https://www.reddit.com/r/klippers/comments/102ycc3/bltouch_temperature_drift_over_time_seckit_cube/
and pictures of the process: https://imgur.com/a/bJwce1D/

Basically he reposts the same and his solution was to remove the electronics from bltouch body and take it to a cooler place doing a very surgical cabling work.
I have still 2 working bltouchs so I might give a try to this project.

Sorry for blameing duet electronics in the past!!!!!!

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.

@Zhang-Jianyu Thanks for the tips.
I have tried your idea. Using it exactly as your wrote, it "works", the problem I see is that this is not exactly and emergency stop. The buzzer works, but the printing doesnt stop till the buffer is empty, and in my example gcode, that took like 5 extra seconds. That makes a total of 10 second to stop the printing... no t exactly an emergency stop jajajaja
Then I tried:
removing the M400: still not perfect, the machines stops after 5 seconds (little more may be), but buzzer is not triggered
removing the G4 delay: the same, it stop after seconds, and buzzer is not triggered.

Thanks both. Yes, I had the local display, wich turned black after loosing the ssh connection.
I rebooted, it booted on 3.3 version. Then I repeated the comand in ssh and I got a "resume" message, wich worked ok. Thanks!

@jay_s_uk I created the mesh.g file, and modified accel and jer there for mesh calibration the restore the original values to normal after the G29 S0 command .

Here I have the latest data from a tunning try today: it is my heated chamber

I ran M303 H0 P0.88 S120

The P0.88 is because I need to lower the power input to the resistor in order to not burn it.

The tunning finished OK:

8/17/2022, 2:39:15 PM Auto tuning heater 0 completed after 3 idle and 14 tuning cycles in 8036 seconds. This heater needs the following M307 command:
M307 H0 R0.125 K0.058:0.000 D44.76 E1.35 S0.88 B0
8/17/2022, 1:10:13 PM Auto tune starting phase 3, measuring
8/17/2022, 12:47:41 PM Auto tune starting phase 2, settling
8/17/2022, 12:25:23 PM Auto tune starting phase 1, heating up

I saved the values, I restarted the board, I checked new values are being used.

Now I try to heat the chamber and I get:

Error: Heater 0 fault: temperature rising too slowly: expected -0.02°C/sec measured -0.03°C/sec

This has happened with every try to tune PID.
The PID was working on this same chamber , same resistors, same PWM in version 3.3

Actual version is 3.4.1, board duet3 in SBC mode

@dc42 When they compete with motion system... That explain my problem about this. My macro trigger the use of an extra stepper motor, which is connected to a driver on an expansion board. So depending on the printing speed, Im detecting strange "pauses" either on the gcode printing or in the time the extra motor moves..
Now I understand why, the re is a competition for the motion system even when this extra motor is not really part of the motion of the printer, it is just vor moving a heavy filament spool, but I guess since it is using a stepper driver, it is considered part of the motion system?

@chrishamm Hello. The update fixed the issue. Sadly, I had scheduled the execution of your requested command for monday, so I cant provide you with the output of that command in order for you to fully diagnose the problem.
But this update did the magic. THANKS!

@jay_s_uk I can handle this with no problem. 100MM is ok, 85 degrees is ok (temp where Im thinking is no more than 50 degrees C MAX)

@fcwilt said in Bug in firmware / DWC:

M141 P0 S80 P1 S80

It does the same. It turns on for just 1 second P0 then turns it off and turns on P1 wich stay on.

Hello. Im considering a new setup using servo motors instead of stepper motor. I have duet3 board with SBC .
In the actual state of firmware, wich servo motor you reccomend or what features you would reccomend them to have in order to beter work with the duet3 board (considering it uses those beatiful 5160 drivers )
Thanks in advance

@jay_s_uk this is so embarrasing.... jajajajaja thanks!