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.

For people looking for a nice, configurable 12864 display, I cannot recommend the BTT TFT2.4 (or other sizes) well enough. While it's nominally an MKS-like touch screen, it also has an 12864 emulation mode that works perfectly fine with the Duet Maestro (including external SD card support), except for annoyingly not drawing the initial screen nicely.

So far I had to fiddle around with the screen (go to a sub menu, back out) to fix this display corruption, but today dealing with other things on my DICE I figured that the display comes up nicely after a reset initiated when the config file is updated. So there must be a better way than physically twiddling buttons I thought.

The solution is fairly simple: Patience. And this is how you introduce patience (at the end of your config.g):

M918 P1 E4 ;-- initialize screen 
G4 P500    ;-- wait half a second
M918 P1 E4 ;-- initialize again

People smarter than me may figure out how to teach the touch screen to talk PanelDue, other than the MKS one the BTT one is fully open source with all files available.

And here is a beauty shot:

Looks nice! What led you to choose repetier server over DWC?

According to a recent post on the thread about the initial run, an SD card with the required files is included.

Thanks for clarifying on DuetWiFiServer, I decided to cover that just in case someone decided to hack on that as well and isn't blocked on finding prerequisites at that point in time.

Here is the same printer 3 months later. I had to replace the heater due to broken cables, updated to the DICE specific hotend in the process, switched the belt carriage to one that clamps the belts with screws instead of gluing them in, fixed some screws, did remove all the various voltage fans with 5V ones, and added a small 12864 controller to the Maestro.

It's still due a few upgrades (I will need to find someone milling me the front plate with the air intake hole and an integrated holder for the 12864 rather than having one put on a 3d printed front plate with double sided tape, and I recently learned the hotend fan is not the right version (too little airflow, which explains my heat creep issues).

As for sample printed parts, the following picture has the motor bracket and flexshaft coupler for a remote direct extruder, as well as the under-effector fan assembly printed on the DICE with reasonable success. Maximum print speed was a conservative 100mm/sec

There is an extensive guide putting a Maestro board in the Ender 3, which should give you some good initial ideas how to do this conversion: https://duet3d.dozuki.com/Guide/Ender+3+Pro+and+Duet+Maestro+Guide+Part+1:+Wiring/37

That's markforged kinematics and should be possible to define with M669 K11

In my experience, the web interface does not always update fast enough, but that doesn't mean the leveling does not happen.

Success! At least it compiled (after I installed libreadline, wxwidgets already lingered on the pi)...

Is there a non-destructive way to test whether the PanelDue likes this version of bossa? I'm a bit worried since the instructions to update start with erasing the current firmware.

For people looking for a nice, configurable 12864 display, I cannot recommend the BTT TFT2.4 (or other sizes) well enough. While it's nominally an MKS-like touch screen, it also has an 12864 emulation mode that works perfectly fine with the Duet Maestro (including external SD card support), except for annoyingly not drawing the initial screen nicely.

So far I had to fiddle around with the screen (go to a sub menu, back out) to fix this display corruption, but today dealing with other things on my DICE I figured that the display comes up nicely after a reset initiated when the config file is updated. So there must be a better way than physically twiddling buttons I thought.

The solution is fairly simple: Patience. And this is how you introduce patience (at the end of your config.g):

M918 P1 E4 ;-- initialize screen 
G4 P500    ;-- wait half a second
M918 P1 E4 ;-- initialize again

People smarter than me may figure out how to teach the touch screen to talk PanelDue, other than the MKS one the BTT one is fully open source with all files available.

And here is a beauty shot:

I have completely disabled PA after switching to KISS with it's looping seam hiding. When going to Hemera, I also disabled KISS' PreloadVE settings which is like slicer based PA to my understanding (but working of an experimentally deduced viscosity model of the material used).

Supermerill's Slic3r++ fork includes looping seam hiding as well, but I haven't tried it yet (the latest build crashes at launch and I haven't tried to figure out why).

@T49 RRF assumes open loop control, so has to re-home whenever the motors have been deenergized or the current machine state is lost, including after a reboot.

I think we can see from the forum history that there is an established if not explicit policy to help people with RRF questions regardless of whether they "provably" have a genuine board (up to and including support for the unofficial LPC1768 port), whereas hardware specific support often comes with the caveat that "if you have a board manufactured by duet, get in touch with your authorized reseller".

Considering others in the 3d printing industry recently went so far as to add a hardware fuse to their custom 3d printer control board, I'm happy to contribute to the open community here. Arguably the price is a bit of a preselector for who is around here, but then again we have the LPC port here so it's not an absolute gatekeeper.

Hi,
On https://duet3d.dozuki.com/Wiki/G-Codes_not_implemented M851 is listed as not to be implemented and to use G31. Yet, M851 reports a Z offset on my CR20 running 2.05RC2. The Z offset in G31 is 2.52, M851 reports -2.52 ... confusing but probably to align with Marlin. X and Y offsets are not reported in M851 though.

So, contrary to documentation, M851 seems to be (partially) implemented but un(der)documented. Does anyone know when it was introduced and if and how it should be used?

There are other projects like SMuFF that use the paneldue protocol to send and receive data, so that part has been done before. The majority of the work would be to build your own menu and encoder based selection/input system, but there are instructables for that as well. Someone with more free time than me and some coding experience should be able to get a simple version up in a couple weeks.

You could try using an esp32 to use the paneldue serial protocol to receive and send data and use the 12864 as an interface on the esp. this is probably easier than hacking on the duet firmware.

It needs a wide and sturdy gantry to deal with the forces from the longer Y belt, but then it's about on par with corexy.

That's markforged kinematics and should be possible to define with M669 K11

Do you print inner or outer perimeters first? Either way, switch it around.