@bondus Your image is very nice. But for 3D printing, we need a continuous print area, so I would restrict it to the red-blue area. That's the main reason why I defined a printable area to be a rectangle. There is a bit additional printable area outside of the rectangle, but I expect only a few % gain.
You can change the print area for your printer by making the distance of the actuators variable (manuallly or by an additional actuator), so you can enlarge or reduce the print area. You mounted the actuators on one aluminium profile, so changing the distance is easy. For every object to be printed there will be an optimal distance: fitting print area with maximum resolution.
I design a printer where the heatbed fits the to be printed 3D object, so only the needed area needs to be heaten up. Together with the actuator distance and optimal arm lengths, a best print result can be achieved.
@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.
Sorry for my rant before, I was far too agitated to post on forums.
The problems had nothing to do with my configuration and setup. I didn't change a thing between starting to try to compile and successfully building a working firmware. No build configuration changes, no source file changes, none of the files in git were changed. The issues I had was everything from strange compilation errors in CoreNG, something about a Pin class, to linker errors where it was missing syscalls.o or symbols defined multiple times,
I think one of the keys to why it got resolved was a project refresh (F5) in eclipse.
I noted the change of GccPath and the need for an updated compiler. The old q2 compiler crashed on the new sources, "../src/Storage/FileInfoParser.cpp:764:6: internal compiler error: Segmentation fault". Scary.
My dislike for eclipse is now even stronger than it was before
@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.
We've never used the JTAG pins on the Duet, so when we needed to revise the layout of that area to reduce EMI, we were happy to remove the connector. If we wanted to do hardware debugging now, we would use Serial Wire Debug instead of JTAG, as we do on Duet 3. For Duet 2 we'd need to build a firmware variant that doesn't reprogram the bus matrix to use the SWD pins as GPIO pins.
Looks like your connection to Duet3D was lost, please wait while we try to reconnect.