I see, there are plenty of other good ideas. I like the ides with the stepper endstops from the pic @oliof posted.
Yes, @T3P3Tony, you have the biggest so far.
I see, there are plenty of other good ideas. I like the ides with the stepper endstops from the pic @oliof posted.
Yes, @T3P3Tony, you have the biggest so far.
@droftarts Thanks Ian,
I came to that Idea when we had this unexpected reboots during prints, I guess you remember. I was not able to test more because I needed the printer. And you had no printer which matched my hardware.
More steppers will be connected later to simulate even more axes or multi steppers per axis. Maybe a display I have a old lcd display left. I think that there a plenty of options to add to the rig if needed.
I think about a beadboard too. To connect other kind of sensors or servors or whatever.
And I need at least one CAN device, not sure how to do that without buying a toolboard, maybe will source a clone, or something from a 3rd party. I will decide that as soon as I have the need for it.
Cheers, Chriss
Hi *,
I want to give you a sneak preview of my new printer concept.
My main learning from former builds it that the movement of the print head or the part causes 80% of the problems with prints, specially artifacts, ringing and problems with layer shifts etc. So I came to the conclusion to reduce the moving parts to the absolute minimum.
The next problem is the bed, all of the size limitation, flatness and the first layer issues. I tried to solve that with a entire new bed design reusing some old hardware I had in the shelf. (You can see the bed on the right top side of the build. )
There are still some problems to solve but the entire new concept looks promising to me till now.
OK, enough joking for now. Since a while I was thinking about turning my bench board into a real test bench for software and configuration tests. So I created this printer dummy.
The horizontal space in front of the board will be used for a kind a plate for some leds and switches to simulate input etc. And I will place a 2nd V6 clone next to the bed simulator to simulate a chamber heater. And the wires need some labels to make it faster to change setups.
The thing has no name yet, I'm open for suggestions.
Cheers, Chriss
Hi * and happy x-mas,
I can remember that we had the discussion about the colours in the DWC and the temp chart, I remember from the top of my head that this colours are not configurable, aren't they?
I do not feel very satisfied with some colours here:
Brown seams a bit low in contrast, the difference between Tool1 and tool3 is hard to tell. And the black on that nice gray looks very ruff to me.
It would be very, very nice if we could make that configurable or if some colours would not be used, specially in some combinations liek this red and orange.
Cheers, Chriss
@droftarts Thanks... That helped indeed a lot to get a better/full understanding about the concept.
@dc42 Thanks for the further explanation David! I understand it now and I switched over to the G53 concept in the meantime. Going "my way" was not very successful.
I have a other questions about the tool change itself. The Prusa slicer, which I use here, acts a bit stupid in my understanding, It sets the tool with G10 to the standby filament temp instead using M568 and the R option. I do that manually via the start code now, like this:
M568 P0 R{global.tool0_standby}
M568 P1 R{global.tool1_standby}
M568 P2 R{global.tool2_standby}
M568 P3 R{global.tool3_standby}
That works so far and I'm happy. But now comes Prusa into the game. The slicer change the temperate of the tool to standby temp now. That should not be a problem because I changed the standby in the start code. You see the "T1" than which does the tool change drill. Next is a G10 with P1 which is OKish. And the next M116 is my problem.
[...]
G1 E-1 F7200
; Filament-specific end gcode
G10 S100 P0 ; set temperature ;cooldown
T1
; Filament gcode
G10 S215 P1 ; set temperature
M116 ; wait for temperature to be reached
[...]
The M116 makes the printer to wait till the previous tool has reached its designated temperature which is the standby temp than (100°C in this case). That confuses me a bit. I understood M116 that it does not wait for "parked" tools since 3.5 anymore:
Note that in v3.5, the scope of tool heaters to wait for is limited to the heaters of the currently selected tool of the selected motion system.
I'm not sure how to overcome that to be honest. The only thing I can think of is to change the main temperature back to the printing temp via the tfree script. But not sure to what will lead me that.
Any ideas?
Cheers, Chriss
@gloomyandy Yes, I saw Davids configs indeed. I use many of his plastic parts for my Hemeras and did some modding on them. But thanks for bring them back up.
I always struggle a bit with using other peoples configs to be honest. I like to understand how things work in detail. And this printer is not a new build, I convert a RR VCore into a toolchanger, so I have a working config and need to add the toolchanging "only". Anyway, I used Davids settings for the coupler and some more ideas. But you are right, I have overlooked the G53 in his tools related files.
Cheers, Chriss
@engikeneer Thanks for the tip with G53, that is indeed what I was looking for. I id implemented "my way" in the meantime which simply sets the offset to x0y0 in the tool files. But that is a ugly hack indeed.
I had a look at the e3d's git repo to get some ideas how they did it. And they do not use they do not use the G53 there, which is a bit surprising. The command may be to new for their retired product.
Anyway, I will work on the calibration for now and will play with the G53 later.
@droftarts I'm a bit confused about the concept behind that offset to be honest. My tools get picked up and dropped off correctly as long as I have no offset configured.
It turns into a nightmare if I have offsets configured for obvious reasons.
So I tend to change the offset now in the tpost file and turn it back to X0 Y0 in the tfree file but that seams to me like a ugly hack. It would be far more convenient if the offset would be removed automatically removed when the tfree gets executed.
Cheers, Chriss
@droftarts Thanks for grounding me again. I may have misunderstood the docu of G10.
I may have overlooked that:
In your G10 tool offset setting commands (these G10 commands have axis letter parameters and a P parameter but no L parameter), specify the offsets of the nozzle or cutting head relative to the HRP.
I will drop the L parameter than and see how it behaves than.
Cheers, Chreers
I use G10 L2 now to define the offsets from the HRP:
G10 L2 P0 X0 Y0 Z2
I tested a bit, the tip of the nozzle is ruffly 2mm deeper than the z-probe. I expected to see a jump of the z high when I select T0 than but nothing happens when I select T0. Z is still at 2mm when the nozzle barely touching the bed. Did I miss understand something?
Cheers, Chriss
I have the feeling that I should use Z according to:
https://docs.duet3d.com/en/User_manual/Tuning/Defining_tool_and_Z_probe_offsets
Hi *,
My toolchanger setup goes forward slowly, the hardware is mostly done now and I think about the configuration.
I wounder now where I should expect x0 y0. I see it at the moment at the z-endstop on the coupler.
My idea was to use that as the startpoint and set the offset than per tool. Or would it make more sense to use T0's nozzle as y0 x0 and configure the offset of the endstop and the three 0ther tools from there?
I'm not sure what would make more sense. My uneducated guess is variant 1, with 0 at the microswitch, that would make it more generic, would need to calculate one one offset when I replace the tool.
How have you done it? Or how would you do it and why.
Cheers, Chriss
@Argo Argo is back in town...
@Hernicz Well, duet, as you know, is g-code only, so scripting is the only way too implement anything in RRF. You can add any kind of interaction code wherever you want, in the start.g, in some filament specific g-code what so ever. I just wanted to show you HOW you can implement a interaction with the operator and how I did it. It is fine for me if you think that it is irrelevant in your case and you are not going to use it.
Good luck,
Chriss
@Phaedrux Thanks for the confirmation... I have expected that but you know.....
@Hernicz said in Better filament Load and Unload handling:
There's no way to cancel and I have to wait until unload.g finishes before I'm able to select another filament. I'm also unable to put any script into unload.g, because as soon as unload.g finishes running I have no filament assigned.
I have no idea how the unload.g actually works but I had a similar problem with a trigger and I used M291 to interact with the user and you can simply store values in a global variable if you need it later.
Here how I did it with a trigger to head up my hotend, retract, bla bla and the operator can select a new temp for the hotend just because you can not flush the nozzle with ABS when your toolhead is at pla temp etc
;echo "Filament Change triggered"
M291 R"Tool" P"Change Filament?" K{"OK","Cancel"} S4
if (input == 0)
G1 Y1 F20000
;echo "Heating up"
M109 S190 ; Set temp and wait for it
G1 E-86 F600 ; Retract filament
echo "Change Filament"
M291 R"Tool" P"Filament Changed?" K{"Yes","Cancel"} S4
; Yes
if (input == 0)
G1 E84 F600 ; Extrude filament till nozzle
M291 R"Tool" P"Filament temp for nozzle purge" K{"210","230", "260"} S4
if (input == 0)
M109 S210 ; Set temp and wait for it
if (input == 1)
M109 S230 ; Set temp and wait for it
if (input == 2)
M109 S260 ; Set temp and wait for it
G1 E60 F400 ; Extrude to clean the nozzle
M400 ; Wait for the end of extrude
G1 E-18 F800 ; retracht filament from meltzone (revo)
M400
M104 S0 ; Extruder temp to 0
M568 P0 A0 ; Extruder heater off
M106 P5 S0 ; Turn the LEDs off
echo "Done"
; Cancel
if (input == 1)
M106 P5 S0 ; Turn the LEDs off
; No
if (input == 1)
echo "Chancel chosen"
M106 P5 S0 ; Turn the LEDs off
I found it very convenient to use whether I use the DWC or the display.
Cheers, Chriss
@Phaedrux Hmmmm.... I'm still not sure what I should expect. (And I do not do that for pause either to be honest). I never ganged in the pause.g from absolute to relative movement for example. My idea would be to move the toolead to the center front retract the filament, wait for confirmation and extrude a lot of filament to flush the nozzle. Retract a tiny bit and continue the print after a interaction with the operator.
So the move to the front must be a absolute move so I need to change that because reasons. Do I need to change that back before I resume the print than? Or does the FW takes care of that? I guess so because the head needs to go back to the saved position....
Cheers, Chriss
@oliof This is clear to me and what is clear from the docu of M600. But what is with the rest? Will the printer than in the "Pause" state? How will it resume regarding G91/90?
Cheers, Chriss
Hi *,
I have a question regarding the inter print filament change drill.
I realized that the SuperSlicer likes to add a "filament change" code to the generated g code when it detects a logo etc.
I had a quick look at it and it seams to me that it generates a M600 at the needed layer to change the filament. I understood M600 that it executes filament-change.g or pause.g if the first one does not exist.
So what can I expect here? The M600 executes the filament-change.g and goes in "pause" than? And I can continue the print than with a "resume" via the DWC or the display? Does the firmware resume than at the same location and with the same G91/G90 as it was?
Cheers, Chriss