@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
![](/assets/uploads/system/avatar-default.png?v=1521803371351)
Best posts made by Tinchus
-
RE: "waves" on rounded prints
-
RE: BtnCmd-DWC Plugin - Customise DWC - v01.03.04 16-06-24
@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.
-
RE: cant connect to https://pkg.duet3d.com for update
@Falcounet Today I tried again and this time connection was ok... weird. But problem is fixed. Thanks!
-
RE: delete
@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.
-
RE: Unable to tune chamber heater
@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
-
RE: Causes for heater instability
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.
-
RE: Update interrupted
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! -
RE: Z offset on Inductive sensors
@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. -
oibject model "status" dcos.
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
-
RE: z probe sensibility and mesh calibration with G29
@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 .
Latest posts made by Tinchus
-
RE: This possible bug is really weird
@dc42 Makes a lot of sense. But are you sure this could be the reason? I mean: the retractions created by the slicers dont create this effect on the calibration. And also: the calibration data remains super stable along the hole printing, if this negative movements created by pressure advance has this effect, shouldnt the value vary along the print or between different prints? because for example: i ran a 3 hs print (a cube) using the "continues perimeter "option in superslicer. This created a continues path with barely any stop in the same layer. And the calibration data, having a pressure advance value of 0.1, had the described efffect. But another print, of 28 hs with lots of stps, paths on the same layer and where I can clearly see the pressure advance making movements on negative direction, in that print the calibration data is exactly the same as in the cube and following your answer, shouldnt be different?
-
This possible bug is really weird
Hello. I have a puylse encoder used as filament extrusion sensor. The wheel of the encoder ahs 100 holes, is really precise and accurate (the error in measurement is like 1/1000 of mms)
It works really well.
At the beginning I posted some problems related to this measurement: the encoder seemed to reported a calibration measured valuerd different insome ocassions. It was very stabble saying a value of 0.2 mm / pulse. But sometimes reported 0.25 mms/pulse. And sometimes reported 0.1 mm/pulse.
My guess was: something is wrong with electronics, may be the oncoder is too muy precise for this aplication? Well, at some point was like it was always reporting 0.2 so... it works and works really well, let it be.But now I had a couple of prints stopped because of the enocedor triggering filament error, all false triggers. The value reported by the enoceder calibration data was again0.1, and even on a print was 0.07 mms/pulse
This time I think I found the reason: a student by mistake changed the value of pressure advanced normally used here, wich is 0.05, and this student used a 0.1 value in a profile, and then changed to something even bigger: 0.13
I called my atention this time that this 0.1 and 0.13 vlues were too much related to the decreasing of the calibration data reported.
So I did a test: using a value of CERO, I got a calibration data of 0.26 mm/pulse.
Using a pressure advance value of normals 0.05 mms, I was getting again the value of 0.22 mm/pulse
using a pressure advance value of 0.1 gave me a predicted 0.1 mm/pulseSO I guess it is conclusive? Somehow pressure advance values are affecting thje calibration data for pulse encoders?
This is a duet3, MBC mode, with 3.5.2 version and encoder config is:
M591 D0 P7 C"io4.in" S1 L0.2 R20:350 E3
-
RE: Unload filament fails
@gloomyandy ok, I will try this and get back to you
-
RE: Unload filament fails
@gloomyandy Sorry: status being changed to "active", temperature is changed from 0 to 205.
-
RE: Unload filament fails
@gloomyandy I will test but my initial answer is a no: initial state when the unload is commanded is "OFF" and main temp set to 0, stand by temp is the same as when loaded the material (90 in this case), when I select "unload", I can see the status being changed to 205. But will double check later (printer printing now)
-
Unload filament fails
Hello, this is the unload.g file of my filaments, they are all the same, it just changes temperatures, in this case this is from PLA:
M83 if !move.axes[0].homed G28 X if !move.axes[1].homed G28 Y if !move.axes[2].homed G28 Z G10 P0 S205 M116 P0 T0 G1 E5 F100 M400 G1 E-24 F3000 G10 P0 S0
I can find the reason why it fails: I command in the interface to UNLOAD, the rountine starts, I can see the temp being set on the extruder and extruder is set to active, but it never waits for the temp to be reached as it is suposed to do due to the command M116 P0
It is a duet3, SMB mode, updated to 3.5.2
I have checked documentation to see if there has been any change on M116 command, seems nothing new, so the command should work.
On console I get:
7/8/2024, 11:47:52 AM Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
7/8/2024, 11:47:48 AM Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
7/8/2024, 11:47:44 AM Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater faultHeater is not in fault, the error makes sense since the T0 routine, and the G1 lines request extruder movement.
Thanks in advance for the help
-
RE: strange error en 3.5.1
@T3P3Tony Sorry forr delay in answering Tony, I as out of office. Update seems to have corrected the failure. Im not sure 100% because I have done only 3 attemps and were partial attemps, I have not tried to amke it fail. For now I guess it is solved, but I have noticed during these test another problem, I will create a separate post for this now (it is an unload problem)
-
RE: condition gcode in daemon
@chrishamm this the my original daemon.g (the one you saw was edited by my trying to see if the indentation in the else was the problem
while true if !(state.status = "processing") if (heat.heaters[0].current > 60) | (heat.heaters[1].current > 65) | (heat.heaters[2].current > 65) | (heat.heaters[0].avgPwm > 0.01) M42 P3 S1 M42 P3 S1 echo "active" else M42 P3 S0 G4 S2
-
RE: condition gcode in daemon
@chrishamm so I delete the "else"?
Why the lines in the fo statement are being executed even when the if result is being false? because of the wrong "else"?
-
RE: strange error en 3.5.1
@T3P3Tony I got this:
Incompatible software versions
The installed software versions do not match. Please operate your setup only at equal versions to avoid potential incompatibilities and unexpected errors.
Please check out the docs on how to upgrade your Duet software components.