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

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!

@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

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

@Notepad Thanks for the feedback. Yes! I already tried the phone aprouch, not really sure yet how precise the app reading is but I have that data. I also found that input chaping ahs a grapgh where vibrations are shown, so Im in the process of getting an accelerometer in order to start test.
Yes, I have really high quality ballscrews. Im still not sure that resonance is born on the ballscrew itself and not on the stepper motor. The ballscrews are already included on the steppers, the re is no connector between them.
At the other end of the ballscrews since they are really straight, they are fixed into a a cnc with a bearing where the ballscrew tip fits. I was thinking on modify this and put some kind of rubber dumper and see (again: Im not sure if vibrations is being created by resonance on the ballscrew or in the stepper)

@infiniteloop I have not tried this material of course, but I have indeed trying to shorten queu lenght in the past several times wheing trying make a macro introduce code faster in the queu for example. I can perfectly agree and confirm that printing becomes "bumpy". So, in the case of this talking about this material, if the movement suffers this kind of artifacts, for sure we can predict flow will be completly out of control because we can maka a paralel situation when you have moisture on you filement: can can get away sometiomes with lot of moisture, but at the moment the nozzle stops just for hal a second, you will see material being extruded A LOT.
From an engineering point fo view, when you face a develpment where at the very beginning the posible solution already faces a lot of problems... that is my sign to "ok, this solution will not end up well, lets look for another aprouch" and this is the case.
In this case, if you already recognize that the material has not a predictable flow, trying to control that chaos is something that will not get to a good solution. I would go towards try to get a better material, OR just not try to get a eprfect flow control.
Remeber this: this has already happened in the past. Maaaaany years ago, in the time where filament diameters where not as precise as today, opeple tried to use optical filament diameter sensor in order to measure diameter on the fly and adjust the flo on the fly. And that aprouch NEVER worked because you had to provide the firmware with the exact offset between the sensor position and the tip of the nozzle, and just an error of 0.2mm gives you more error on the flow calculation than a +-0.1 in fialment diameter so...
I still have one of those sensors by the way lol

@oliof But The vibration Im describing has no visible effect on the print, so how can I measure the vibration (I dont have special equipment for that)

I hav a couple of printer, they have ballscrews on X and Y axis. The "propblem" is (already asked to the motor manufacturer) is if I run a 42/45 mm/s speed and in the middle of X position (printherad at the middle of the ballscrews lenght) you can hear a vibration starting to grow up till the vibration becomes an earthquake and only when moving on negative direction.
manufacturer says Im hitting the resonance point of the setup. This problem never happens with any other speed.
So my question is: is there any way from firmware to restrict this range of speed of being used?

@o_lampe You cant do this. In the moment you measured the flow at the output of the nozzle, the gcode command will enter the queu... The flow modification wont be at the proper timming never ever.
In my opinion this is one of those request where the solution is being looked at the incorrect place. Just make sure you extruder works properly, your filament is in the proper state (dry) and you are done.

You have flow rate control on many slicers already (superslice foe example lets you set a max extrusio rate and set every type of path to use that max value. So in your case ofr example if you want to limit a 5 mm3/s of flow you can do it.

A really nice one: The APUS extruder. I have been using since I got it,

@Tinchus I have an extra observation. while trying to separate the BL cable from the resto fo the cables, electronics were off, I moved the printhead by hand and the red led of the bl touch turned on, is that ok?

@Phaedrux Can you give more specific sugestions on what oyu se as a potential wiring problem, and how you would route cables? If I use the short cable for BL, it is kind of imposible to keep other cables away since they are loner cables Right now as you can see on th pictures BL cables are tgether on the printhead bundle. I have tries to look online for cable steup and ewverything I find are cable bundles, Even if I route every cable apart, they will somehow need to close each other when they get connected to the duet.
Please advise on what potential problem you see on pictures so I can specifically fix that
Are all sure thare is no bug in actual version or if compatible is checked on latest firmware version? Today I noticed something: when pin is not deployed, and if I manually deploy iit, led on BL readcts. If I push pin up with fingers, DWC never sees the BL activation (zprobe value is always cero). If I issue an M402 pins goes up, then M401 deploys the pin and if I try to trigger it, pin is trigger but DWC nevers sees that, probe value is always cero. Then If I do a software emergency stop, the pin drops down, and if I trigger it with my fingers, goes up and gets re deployed inmediatly and I need to turn of power in order to get control again.
Thanks in advance

@Phaedrux Sure.

On the left there is bltouch an its connections marked as 1 and 2. Cable is new, and shielded with a metal tape. En the right is heatsing fan cable, thermistor and heater cartridge cable all together marked as 3

All cables ogether with extrudet stepper motor cable get together on top of the printhead. On the picture you see them but in reality they are all together inside a chain cable (not in the picture since I jhad to remove it in order to do test but since the chain cable is plastic, should not make any difference in fact with cable chain should be worst scenario because all cables are tigheter, still the problem exist without the chain cable.
Numer 4 is extruder cable, number 5 is BL touch cable, and on the right the heater cartridge cable and 6 is the hatsing fan cables. As seen , stepper motor cable is also shielded

On duet side I have bltocuh conection on io7, as you can see on the last part is not shielded (does it matter). Above that there is X endstop connection and next to it the Y endstop copnnection.

The cable markes as SIGNAL bed is a cable that is just like 5 cms close, it si on the pictture but it is a conection from out1 that feeds a mosfet feeding the heated bed.

And this is the metal tape I use for shielding, I guess it works because it solved the noise problem on the flat cable of the SBC in about 8 printers using duet3 on the school.