@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?
![](/assets/uploads/system/avatar-default.png?v=1521803371351)
Posts made by Tinchus
-
RE: This possible bug is really weird
-
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.
-
RE: strange error en 3.5.1
@T3P3Tony ok, updating now. Any particular border suation instructions you may wanna me to try?
-
condition gcode in daemon
Im having this problem and I cant see what it really is. This is my daemon.g
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
If in console I do "echo (heat.heaters[0].current > 60) | (heat.heaters[1].current > 65) | (heat.heaters[2].current > 65) | (heat.heaters[0].avgPwm > 0.01)" while not printing, I get a FALSE result:
echo (heat.heaters[0].current > 60) | (heat.heaters[1].current > 65) | (heat.heaters[2].current > 65) | (heat.heaters[0].avgPwm > 0.01)
falseMy intention is to be sure a rele is OFF while not printin nor any heater active or hot.
For some reason that if statemen is been taken as true, and I dont know why. I have tested with echo the hole sentence and I can see it returns a false result. Also checking each of the conditional gives me false so Im sure the result of that if should be falso and so the else statement be exucuted, but... it is not working
but this failure is only happening after a print has finished. I I reboot the printer, looks like the daemon.g do what it is suposed to do.
Any ideas why?
thanks in advance
-
RE: strange error en 3.5.1
@dc42 I truied, did the sudo apt steps but that version is not released?
-
RE: strange error en 3.5.1
@droftarts The first try with M226 did the pause correctly as expected: it paused and moved off the print as pause.g instructed. I changed the filament, did some manual extrusion to purge the old color from the nozzle, and when I press resume, it was then that the error poped out and the print was cancelled.
Before that, I did another try , this time I was using kisslicer, the M226 was also executed well, filament was changed, and then the print resumed well too, but the print failed because of another problem (the resume script that kisslicer uses had a mistake of my responsability).
It was on between these prints that I noticed than from the print with kisslicer and the print attemp with superslicer, the only difference (apart from the gcode generator, but the M226 was in the same layer so...) was me introducing the M911 command on config.g ans so I decided last night to remove that command and try again.
But in short: M226 seems to be excuted correctly, pause.g is executed, the error pops out when resuming the print.
-
RE: strange error en 3.5.1
Dont ask me why, but in my case I found this: I lauched THE SAME gcode again and the only difference I tried was commenting the power failure configuration on config.g:
; M911 S21.0 R23.5 P"M913 X0 Y0"
MY resurrect-prolog.g file has this:
M116 ; wait for temperatures
G91 ;
G1 E-1 F200;
G1 Z5 F80;
G28 X0 Y0;
G90;
M83 ; relative extrusion
G1 E2 F3600 ; undo the retraction that was done in the M911 power fail script
M25 ; pauseI know: a M226 should not triggered this file right? so it makes no sense to me why7 would affect or cause this behaviour. Thing is: I commented out the M911 command on config.g, rebooted printer, launched the same gcode again, pause was made as expected, I changed the filament and print was resumed without problems.
-
strange error en 3.5.1
I have tryied to print a file, on layer 3.3 the slicer (superslicer) introduces an M226 to make a pause.
In that point I change filament color. I did the changed and after pressing resume, I got this error:Error: in GCode file line 0: G1: Axis X is already used by a different motion system
and print was cancelledNever happened before.
It is a duet3 SBC mode, with 3.4Pause.g and resume .g files are as always and tested since 3.5.6 with no problems
Ideas?
Thanks in advance -
M84 change on 3.5.1?
On previous version I was using M84 S0 to make motor never go to idle state (so they hold torque all ttime while pausing a print)
No on 3.5.1, the command complains: Error: in file macro line 22: M84: value must be greater than zero
How can I make motor stay away from idle now?
Thanks in advance -
may be an error on object model?
Just noticed this on version 3.5.1 (duet3 SBC mode)
When running autotune for a heater (didnt try all heater, I ran autotune on my heated chamber heater), I noticed the heater is turned on, but on the object model the value heat.heaters[0].active is 0.
In my particular case I have a couple of scripts monitoring this value in order to know if heaters are ON or OFF
When the autotunning start, the heaters are turned on, and the value remains during all the tunning with a cero value, I think this is wrong? should be 1? -
reconection to wifi after disconnect
Hello. Sometimes when power goes down, the duet3 + SBC restart faster than the wifi router, and in thsi situation the duet3 board never connects to the network.
Is there a way to make duet reconnect again to the network / retry the connection without rebooting it? -
RE: Emergency stop being triggered on 3.5.1?
@Phaedrux here it is the responsible ; i fopund it on DCS logs:
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Starting macro file trigger8.g on channel Trigger
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Trigger: Aborting orphaned macro file trigger8.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Aborted macro file trigger8.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Daemon: Aborting orphaned macro file daemon.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Aborted macro file daemon.g
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Daemon: Failed to find suitable stack level for flush request, falling back to current one
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [warn] Emergency stop
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Aborted job file
May 24 02:37:10 PU-HT-7729 DuetControlServer[412]: [info] Cancelled printing file 0:/gcodes/lapida 2.gcode, print time was 6h 19mThat trigger has a M112 inside, it is switch installed outside printing area, I use it as a safe protection in case the motors loose steps to avoid crashing the printhead wioth the frame. But that switch was never hit. I can tell that because the printhead it is always inside printing area all the times this reset happened. And this configuration was working ok under 3.4.6 for at least 3 months. For some reason this switch in being "triggered" now with 3.5.1? I have to say that this switch is against recommendations, because it is a NO one (recommendation is to use NC)
So 1 posibility is that some noise is triggering the switch? Is there any chance the firmware is now more "sensitive? (someone wihtout electronic knowledge like me is the one asking this so I apologize is the question is really stup...)