Some of you may remember I reserved a kinematics type number back in August 2019.

And some of you remember I wanted to take a break from 3d printers.

Well, I failed either so far. But as of today, I have a prototype machine built that I can implement for. Luckily, someone did it for Smoothieware (the same person whose prototype build I copied, with his blessing and help).

Here is a first photo:

And here is a short video of me abusing delta mode and absolute tower moves to show that it's only mostly dead:

https://photos.app.goo.gl/c4ptuJajXeWNc8di9

Still missing are endstops, belt tension, anything on the effector to do useful stuff, a surface to do stuff on ... but for implementing the kinematics this should be sufficient. Let's see if I can get to there in less than nine months (-:

Tom Sanlanderer has designed and published a cheap diameter sensing setup (see https://www.youmagine.com/designs/infidel-inline-filament-diameter-estimator-lowcost-10-24) -- it would be great to see that included in a future filament sensor design -- and to add a feature to adjust extrusion rate with the sensed diameter of course for those of us that like the last tiny bit of precision.

Hi,
I would like to document what I needed to do to compile RepRapFirmware and DuetWiFiSocketServer on a Debian Buster system (similar to a previous report on doing the same on Linux Arch).

First off, do not waste time trying to install the build chain from debian packages. They are sorely outdated and will not work.

The Build Instructions are a decent baseline, but to get everything going, I had to close some gaps.

Build Tools

1. Eclipse IDE for C++ downloaded from upstream. This requires a JRE to run, but openjdk is sufficient.
2. arm GNU toolchain downloaded from upstream. The Debian packages are massively outdated and builds will fail.
3. xtensa architecture toolchain from upstream is needed for DuetWifiSocketServer. As with the arm-gcc cross compiler, the Buster packages are outdated and won't build the project.
4. ESPtool because the esptool.py included in the xtensa architecture toolchain has different command line switches and the build will fail without the binary
5. eboot.elf from the Arduino ESP libraries

Additional Dependencies

In addition to the repositories listed in the build instructions, you need LwipESP8266 and CoreESP8266 as prerequisites to build DuetWiFiSocketServer.

More Project Variables and Paths

1. For LwipESP8266, set GccPath to the bin dir of the xtensa-lx106-elf compiler suite
2. For CoreESP8266, set GccPath to the bin dir of the xtensa-lx106-elf compiler suite
3. For DuetWifiSocketServer, set

• EspBootFile to the path to a valid eboot.bin
• EspToolPath to the esptool binary (NB esptool.py does not work because it has another call signature)
• GCCPath to the bin dir of the xtensa-lx106-compiler suite

From the default settings on the checked out projects it looks like you can find those when you added ESP8266 support to a local arduino installation, but when I set this up I was tired and couldn't remember how to set up board support on Arduino so it was more straightforward for me to download and build everything from source. It also made it possible for me to ensure that I really got the latest versions of everything.

With all this in place, I was able to build CoreNG, FreeRTOS, RRFLibraries, LwipEsp8266, CoreEsp8266, DuetWifiSocketServer and finally RepRapFirmware without a hitch.

The Duet2 Wifi will still serve you well, @Chriss -- it's not magically bad now that this board has been announced (-:

The last ten days I kept myself busy with a V-Core Pro Corexy kit. It sports a 750W AC heater, three independent z steppers, MGN15 linear rails, 9mm Gates belts, a Duet3 with a Raspberry Pi4, hall effect endstops, a polypropylene print plate, paracord-sleeved cabling, a 450W Meanwell PSU (overpowered without running a heater, but that hopefully means it will rarely switch on it's fans). Print volume is 300x300x300 -- but since I use integrated leadscrew steppers, Z is likely close to 330.

The kit is super chonky for lack of a better word. The belt runs are super clean and parallel to everything, and the belt tensioner is integrated in the X carriage requiring a single screw per belt to tension.

I am almost ready to do a first print, but am missing mounts for the endstops and Z calibration. After that, everything will be cleanup and incremental improvements.

I like the JoKo Engineering FreeCAD tutorials and demos on YouTube (and I usually hate YouTube tutorials). He does a couple comparison between various tools as well, but for everyone that doubts FreeCADs capability, the demo where he builds something out of a Solidworks certification in FreeCAD, then exports it as step file and checks the result in Solidworks for full compliance is pretty amazing.

I recently ran across a concept from 2014 that seems to have been implemented in LinuxCNC and MachineKit, but none of the main printer firmwares around: Velocity based extrusion.

In short, the extruder is not an axis controlled by the GCode directly, but the firmware is instructed about target line width and height and controls extrusion speed according to nozzle movement. This is similar to volumetric extrusion but different (extruder is still an axis) and should basically result in pressure equalization similar to Pressure Advance, but based on nozzle movement velocity rather than as a heuristic adjusting the extruder movement.

Further reading:
https://basdebruijn.com/2014/05/machinekit-and-additive-manufacturing/
https://basdebruijn.com/2014/09/velocity-extruding-revisited/
Post processing script for slic3r:
https://github.com/machinekoder/Machinekit-Slic3r-postprocess/blob/master/velocity-extrusion.py

CMD53 is some kind of configuration command for a wifi chip; which is where some error was triggered. This seems to have blocked some subsystem for about 2 seconds, long enough for a realtime system to decide it is in an irrevocable state of de-sync.

Sleuthing a bit, it could be related to an unfixed issue with the wifi chip and/or driver on the Raspberry Pi which has been around since 2018 ...

I'd suggest moving to Ethernet if possible.

Hi,
Please consider offering the DuetPi image using f2fs rather than ext4. It's a filesystem written for use on SD cards and is much more resilient to power loss and sd card style faults. More info at https://www.kernel.org/doc/html/v5.7/filesystems/f2fs.html

RatRig has the V-Cast which comes in an IDEX configuration if you are interested. Their basic mechanics kit for the IDEX V-Cast is about 380EUR: https://www.ratrig.com/3d-printing-cnc/rat-rig-v-cast.html

@dc42 said in Help me find "linker script" in source code:

Where did you find that link?

It's linked at https://github.com/Duet3D/RepRapFirmware/blob/dev/RTOS_notes.md

Hi,
I noticed that sometime recently, the GCode Dictionary structure on the duet3d wiki was changed so that the main page only has short stubs about every GCode command, and the detailed info is on sub pages.

In my personal opinion, that makes the documentation much less accessible than before: I can't easily get from one entry to the next, especially if one references another, since most mentions of other GCodes aren't linked. It also makes me lose the sense of "grouping" I got from everything being accessible on a single (albeit) long page.

How's everyone else thinking about this change?

Driver 11 didn't work, there's a bug fix note in the RRF 3.3 release notes:

[Duet WiFi/Ethernet] Driver 11 connected to CONN_LCD did not work. It should now work provided that you have not configured a 12864 LCD.

https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-33

Make sure that you are runing RRF 3.3 (and update DWC to the same version as well), and try again.

This is a safety feature and I'd recommend against disabling it. It may be a bit of a regular occurrence during setup and tuning, but during normal operations it should almost never happen.

@Phaedrux I ordered a board and expect it to arrive by October. If I don't manage to find the offending change by a couple bisecting builds, I'm happy to send it over to Duet3D for inspection.

@phaedrux said in Large Format Dowell to Duet conversion:

The only direct connect screen compatible with the Duet is the PanelDue.

Other options exist. RepPanel, RRFDisplay as seen elsesewhere on this forum; the BTT TFT support for RepRapFirmware improves roughly on a week-by-week basis. These are all open source. The closed source FlyMAKER screen also is available.

Personally, I do not regret buying the PanelDue. I'd prefer an 12864 controller on Duet3, but haven't put the RRFDisplay to use yet myself.

Last I heard the only difference is that the TMC2660s stallguard pins are floating since those aren't required on the troodon. Otherwise, it's a single board combining Duet2Wifi and Duex5. Unfortunately, I don't have a board (or schematics) either.

5V and 3.3V LEDs should also light up.

does it behave better when you disconnect the heater?

What's going on here?

Can you route that red wire (MOSFET control?) so it doesn't seem to potentially hit the reset button?