Posts made by token47

@phaedrux It's a probe I designed myself. A crashprobe. It sits behind the HEVO carriage and is deployed by pushing it down from above (releasing a magnet). It can be easily deployed by hand (the printer will beep and wait for it) or go to the corner and press against another part. Still testing, but already much better than the older one which was driving me nuts. It has about 10mm of Z offset to the nozzle and another 6-7mm above the nozzle when retracted (I wanted a very long travel on both ways to avoid problems I was having before).

@phaedrux Thank you for the procedural steps. I'm reading about the upgrade and finding courage to do the upgrade, this will help. The reason for the delay is that my setup is complex, I have a ton of macros and some advanced configs, so I keep delaying it.

@fcwilt and @dc42 Thank you for the response. I thought fw 2.x did not have mesh.g support (I checked documentation and code, even tried it, but I could be wrong).

As I commented on OP I intend to upgrade soon, but anyway, it seems this problem would occour even on 3.x if issuing a G29 S0 directly, which is still something to consider.

@rjenkinsgb ok, maybe I was not too specific. Here is more details:

• G30 works ok, and is not related to this problem.
• Yes, the printer needs to be homed when running G29 (this means running G28 if needed). I am doing this.

The problem is still there. If the printer is homed, is near Z=0 (for whatever reason) and G29 is run, it will not lift before deploying the probe. It should (proof is that it will do it, just the order is reversed).

Actually i could move Z in deployprobe.g using G91 + G1 H2 + G90 like I do in homeall.g macro, but that would probably another lift on top of the homing lift, it would be better to just do things in the right order.

I just switched my z probe for one that is much longer and now I noticed a problem that was not noticeable before.

I'm using Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.05.1 (2020-02-09b1)

When running G29 S0, it will both deploy the probe for me, and also take into consideration the height needed for the probe to trigger (i.e. it moves to the first probe point while adjusting Z to my z-probe-offset + nozzle-dive-height).

The problem is that it deploys the probe BEFORE moving Z to the right level, and when the nozzle is too close to the bed at the moment I run G29 S0, it will deploy the probe, the probe will touch the bed while deploying and then be dragged over while adjusting Z and moving to the first point.

This is not a problem if you have a probe with a very small deploy travel distance, or if you are already high enough before deploying, or if you have a non-deployable probe like a inductive one. But it will be a problem if you have a probe with a very long travel (my current one has 10mm travel + 3mm dive) and it is below that height when G29 is run.

I cannot try to lift Z in my probe deploy macro because it will also be ran when running G28 and Z is not homed yet so it will not work. And I don't have mesh.g yet in the version I'm running (I'm planning to upgrade soon).

I think the order of DEPLOY and MOVE-Z should be reversed. Thoughts?

Thank you

First, you have to configure the "virtual endstops" to use the stall instead of physical switches. You do that putting this in your config.g:

; Endstops
M574 X1 Y1 S3 ; Set endstops to use sensorless motor load detection
M915 X Y E S3 F1 H200 R0 ; set stall motor sensitivity and actions

This is enough for it just to work as if you had switches installed. Anytime the motors stall, the enstops will be triggered.

Now, when doing the homing, you must use the S1 paramenter (or the H1 parameter on FW 2.02 and later) in your G0/G1 commands so it respects endstops.

H1 terminate the move when the endstop switch is triggered and set the axis position to the axis limit defined by M208. On delta printers, H1 also selects individual motor mode as for H2. Normally used with relative motor coordinates (see G91).

For example, my homex.g is like this:

G91 ; relative positioning
G1 Z${Z_HOMING_LIFT} F$((Z_SPEEDS[MEDIUM]*60)) ; lift Z relative to current position
M98 P"0:/sys/m_set_homing_speeds.g" ; set lower speeds and accelerations
M913 X60 Y60 ; set X and Y motors to low current for homing
G1 S1 X-$((X_LIMITS[MAX]+100)) F$((XY_SPEEDS[HOMING]*60)) ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F$((XY_SPEEDS[HOMING]*60)) ; go back a few mm
M913 X100 Y100 ; set X motor to 100% of the normal current
M98 P"0:/sys/m_set_normal_speeds.g" ; set normal speeds and accelerations
G90 ; absolute positioning

Don't mind the variables inside the script, I have a pre-processor that replaces them before uploading to the duet by ftp. Pay attention to the logic and replace your values.

There are certain requirements you have to take care when using sensorless homing. For example, it will only sense when the motor is above certain speed, if too low, it won't detect. So do not home in very low speeds. Also, if you lower motor current to about 60% it will help the process, at full current it may bump too hard on the limits. I also decrease accelerations, speeds and jerk in those macros and restore them afterwards, I have seen better results with that.

You can use start.g and stop.g to turn on/off specific pins on the board (configuring the pin as a GPIO using M950 and turning it on/off using M42) and wire a led or even an SSR to that pin to control something external. You can use any of the unused pins like endstops or unused pins in the expansion header.

I do it the opposite way. I always edit stuff on my pc and upload changes. I made a script to automate that. You can find it at https://github.com/token47/duetcfgen

It works on linux, cygwin and WSL.

This is what I use and have tuned over the years:

# speeds, accelerations, jerk and moves
JERK_NORMAL=([X]=12 [Y]=12 [Z]=5 [E]=10) # max instantaneous speed changes (mm/s)
JERK_HOMING=([X]=0 [Y]=0 [Z]=0 [E]=0 ) # max instantaneous speed changes (mm/s)
ACCEL_NORMAL=([X]=2500 [Y]=2500 [Z]=100 [E]=9000 [PRINT]=2500 [TRAVEL]=2500) # (mm/s^2)
ACCEL_HOMING=([X]=500 [Y]=500 [Z]=50 [E]=250 [PRINT]=500 [TRAVEL]=500) # (mm/s^2)
MAXSPEEDS=([X]=150 [Y]=150 [Z]=30 [E]=30) # max speeds (mm/s)
XY_SPEEDS=([SLOW]=20 [FAST]=150 [HOMING]=80) # speed for X or Y movements
Z_SPEEDS=([SLOW]=3 [MEDIUM]=8 [FAST]=20) # speed for Z movements
E_SPEEDS=([SLOW]=10 [FAST]=30) # speed for E movements

These are variables in the tool I wrote to parse and export a config for me, but you can see the values that matter there.

BTW the tool is here if you want to play (works in linux or windows/cygwin).
https://github.com/token47/duetcfgen

I have a macro to change filamento mid print unloading and loading again using gcode while paused. Works like a charm. I insert a M226 in the slicer at the point to change colors, the printer will pause and go to the corner. While paused, I click the macro on the web interface, it will run, eject filament, load another, purge and stop. Then I unpause and it goes back printing.

The macro (and it's dependencies) are below. They are split because I use the same load/unload macros on normal filament loading and unloading.

@file macros/Load_and_Unload/Change_Filament_Mid_Print.g

"M98 P""0:/sys/m_unload_filament.g ; Call macro for the rest of the work"
"M98 P""0:/sys/m_load_filament.g ; Call macro for the rest of the work"

##########################################################################
@file sys/m_load_filament.g

; WARNING: temperature must already be set for the current tool (G10 Snnn)
; on the calling routine
;
"M291 P""Please insert filament"" S3 T0 ; Display new message"
"M291 P""Now loading..."" S0 T0 ; Display new message"
M913 E40:40 ; set extruders 0 and 1 to low current
M83 ; Select relative extruder motion
G1 E-1 F$((E_SPEEDS[FAST]*60)) ; Retract 1mm of filament at 1800mm/min to ensure that it is not flagged as stalled.
G1 E10 F$((E_SPEEDS[SLOW]*60)) ; Feed 10mm of filament at slow speed
G1 S1 E$((BOWDEN_LENGHT+100)) F$((E_SPEEDS[FAST]*60)) ; Feed filament at fast speed until detects stall
M913 E100:100 ; set extruders 0 and 1 to 100% of their normal current
G1 E50 F$((E_SPEEDS[SLOW]*60)) ; Feed 50mm of filament at slow speed
G4 P1000 ; Wait one second
G1 E${FIRMWARE_RETRACTION} F$((E_SPEEDS[FAST]*60)) ; Retract 4mm of filament at fast speed
M400 ; Wait for the moves to finish
M82 ; absolute extruder moves
;G92 E0 ; reset the extruder counter
M292 ; Hide the message

##########################################################################
@file sys/m_unload_filament.g

; WARNING: temperature must already be set for the current tool (G10 Snnn)
; on the calling routine
;
"M98 P""0:/sys/m_beep.g"" ; Warning Beep that your filament is starting to retract!"
G4 P3000 ; Wait 3 seconds
"M291 P""Retracting filament..."" S0 T0 ; Display another message"
M83 ; Select relative extruder motion
G1 E-50 F$((E_SPEEDS[SLOW]*60)) ; Retract some filament at slow speed
G1 E-${BOWDEN_LENGHT} F$((E_SPEEDS[FAST]*60)) ; Retract more filament at fast speed
M82 ; absolute extruder moves
;G92 E0 ; reset the extruder counter
M400 ; Wait for the moves to finish
M292 ; Hide the message again
M84 E0:0 ; Turn off extruder drives 1 and 2

Don't mind the variables, they are used in my duet config generator. You can get the idea doing manual substitution. https://github.com/token47/duetcfgen

@deckingman said in CoreXYUV with dynamic load\force balancing.:

@brunofporto Actually, I had already used all 10 of the Duet plus Duex5 drivers and didn't much fancy the complexity of adding two external ones. So at the moment it's either 5 extruders, or 3 extruders with dynamic force cancelling but not 5 extruders and dynamic force cancelling together. That will have to wait for gen 3 Duet.

But changing from one configuration to another is simply a matter of swapping two motor connectors on the Duex5 and uploading the appropriate configuration files - about 2 minutes max.

It's easy to use motors 9 and 10 on the duet2 itself without expansion. They are present on the (unused) LCD connector and it's just a matter of using two external breakout boards. Like on this image:

@deckingman silly you, we are watching.

Yes! D8.0 was perfect for my bed. I was afraid of going too high compared to the original 0.4 value and wouldn't go past 1.0. Thank you for the information that 5 to 10 were more usual values!

@dc42 Hummm, that explains why I upped the value until more than double and it still would not make a difference. Will try that. Thanks!

@deckingman LOL. Not exactly, but good to know that, heheh. BTW, very nice project your printer, following every move. Congrats!

@deckingman they are compiled to raw gcode doing variable substitutions and sent by ftp to the duet, automatically. For the case in question, just imagine the substituted command. They are below for easier reading, this is what is actually on the config.g file:

M307 H0 B0 A102.1 C36.8 D0.4 S0.75 V12.3
M307 H1 B0 A674.5 C185.7 D4.8 S1.00 V12.3

For the record, the config generator is at https://github.com/token47/duetcfgen

thanks

@dc42 I like being able to choose between both, as @fcwilt said. But, if forced to choose, I would prefer for it to follow documentation (average all readings and not abort). That is a must when you send a G29 from the start script of a slicer, unless the whole print would abort too (what happens today is that the G29 aborts and the print continues).

Yes, my complete settings are:

M307 H${HEATER_PIN} A-1 C-1 D-1 ; Disable Heater pin used by probe
M307 H0 B0 ${HEATER_H0} ; Disable bang-bang and tune heating parameters
M307 H1 B0 ${HEATER_H1} ; Disable bang-bang and tune heating parameters

And also:

; Heaters Tunning
HEATER_H0="A102.1 C36.8 D0.4 S0.75 V12.3"
HEATER_H1="A674.5 C185.7 D4.8 S1.00 V12.3"

@dc42 That is great (and please do it) but it may not solve both problems.

One problem is a way to force doing all the probes and averaging them. Treating 0.00 as a special case to do that will solve this one.

Other problem is having a non-zero value, and still not being able to find two readings whose delta is below that value, even making all the possible readings. It should then just average all the readings, but it gives an error and aborts the G29. This is different from what the documentation says it should do.

I think this second problem is a bug, what do you think?

Thank you!