@sungod3k said in Flying extruder with 4th axis:
I found the section about "additional towers to carry flying extruders" in the wiki, when I define the 4th like this does that in include the behavior that the 4axis moves up and down depending on where the x/y position of the effector is? or does this need to be added as an extra command?
That's automatic, you just need to define the XY position of the extruder outlet and the distance you want to maintain between the extruder output and the hot end input.
@mwinterm would you be able to provide a link for the xtensa-lx106-elf-gcc cross-compiler? This is the only remaining issue I cannot seem to solve and I have tried downloading from several sources but they do not seem to work. It would really appreciate if you could provide some information on this.
That's good. I'm aware of Eclipse and actually use it for some things in all kinds of strange versions. It's a fine tool for development, but not for builds or integration.
I've also seen so many compilers and tools get buried in licenses and obsoletion of platforms that it always lights up alarms to see some massive IDE been mentioned when something is supposed to get built.
@dc42 said in Delay response for Macro called during printing:
When the command is inside a macro file, how long is the delay?
Only one line command in Macro. Sometimes it needs 1~2 seconds, sometimes it needs around 5 seconds. It makes me confused and I doubt that if I have run Macro or not. The important point is it just happens while machine is printing.
@giostark said in [solved] BL-Touch deploy only one time with 2.03RC1:
I read somewhere in the "whats-new " that during the probe some deploy and retraction now are automated. Is correct?
That's correct. For some types of probe, when running bed.g you want to deploy and retract the probe just once in the entire sequence, which you can do using M401 near the start of bed.g and M402 near the end. But that's not the case for BLTouch, which needs to be deployed separately before every probe point. So leave the firmware to deploy/retract it automatically.
@dc42 said in temperature sensor pin number change:
not the one you thought it was.
There were two firmwares on the SD card. One for before 1.20 one for 2.0+. Having these both on the SD card causes problems. Now it has resolved.
@dc42 Are you sure it built all of them? For me it builds the active one (which I didn't even notice) plus the one that's linked.
For instance, I went through the CoreNG, RRFLibraries and FreeRTOS projects and made SAM3X* the active config but linked all the SAM4E* configs. When I build RepRapFirmware, it builds the SAM3X* configs plus the SAM4E* configs but that's it. Since those libs are tiny, there's no real downside to building the extra SAM3X* configs and RRF links to the correct SAM4E* versions. Well, "correct" for me since I build Duet2_RTOS.
@dc42 said in Video of delta 4th additional axis sidekick extruder:
Looks good! But can't the Bowden tube be made a lot shorter, if you tilt the extruder so that the filament outlet is horizontal or 45deg down, instead of what looks like 45deg up?
I believe you're right on a lower angle. It was a big leap for me with all the added complexity - the extruder carrage falls when the motors are not energized pulling the effector down by the bowden. So I was playing it safe until I can work around that. I will probably end up moving the extruder mount to overhang the bed a bit and get the bowden angle closer to overhead.
The firmware is really great - it basically just worked straight away with minor effort. I was shocked at it's ease of flexibility - and the added motion is highly enjoyable to watch! Thanks for developing the firmware this is great!
The Duet_NG folder that is greyed out is the important one. I sometimes find that Eclipse greys out the wrong folder. Changing the configuration to a different one and then back again usually fixes it. However, when the wrong folder is greyed out, the build still works.
The version of Eclipse that I currently use is 2019-03.
Thanks, I'll look into that. It seems I could infer the initial heating phase by detecting the transition from Idle to Printing (heating begins) and then wait for all axis' to be homed (heating complete). It's just for lighting, not critical path.
btw it's also possible to print in mirror mode. The procedure is:
Adjust your M208 and other settings so that X0 Y0 is bed centre (this works better for duplicate mode too, because all your prints can be centred at (0,0) when you slice them, regardless of how you intend to print them).
Use the M579 command to apply a scaling factor of -1 to the U axis during the print.
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.