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 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.

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.

@chas2706 said in No output from G32 on DSF 1.2.4 / DWC 2.07:

With both examples I notice the Pi does not return to "pi@Duet3:~ $ " is this something to do with the problem?

That is due to the -f switch which means follow and waits for new stuff to be written to the journal. Not returning to the command prompt without hitting Ctrl-C is normal in this case.

Same issue with 3.01-RC1 -- system already was on DSF 1.2.4

M122-RC1.txt

PS I figured out by now that systemctl restart duetcontrolserver.service is enough to make the system respond to commands issued via DWC again. duetcontrolserver's logs don't seem to log anything specific:
duetcontrolserverlogs.txt

Hi,
on my Duet 3 0.6 board with RRF 3.01-beta3, I am currently trying to get sensorless homing set up for X and Y so I can use the printer while trying to come up with a mount for normal endstop. My suspicions about sensorless homing don't seem unfounded because at times while the motor stalls, I get

G28 Y Error: Operation failed (Reason: Transport endpoint is not connected)

At this point, any attempts to send commands to the board are stuck (i.e. the spinner on the send button in the dashboard keeps spinning). Files and status from the printer still update in DWC

and after that, no more connectivity between the duet3 board and the raspberry pi until I reboot the pi. I had to completely power down the boards (connected via ribbon cable, Pi gets power from the duet3 board) to get the system up again.

The issue seems to be that if you don't cause a stall event within the home*.g quickly enough, the communications between the board and the SBC fail. As I am cleaning up my scripts and make sure the endstop positions are right and the travel moves are far enough, the error starts ceasing.

Is there a way to recover from the Transport endpoint is not connected error without a full power cycle?

Thanks @dc42 and thanks @Danal -- I have done everything on your list, and as the board is not in a metal enclosure, I will ignore the Ethernet shield ground connector for now. I have a genuine Meanwell PSU so I am confident it is isolated.

End result: I know nothing anymore and probably need someone with the knowledge to look at my rig at my place and tell me what to do ...

@Danal yes they do, and only a small number of printed parts to boot. So far I would say they could improve by using shoulder bolts for the idlers, and toothed idlers for the idlers where the toothed sides of the belts run, but that's already a high level complaint.

Conditional gcode in rrf can do this.

@bearer the duet3 0.6 has a header labelled GND next to the Ethernet port. I am trying to figure out whether I should connect it or not. @dc42 seems to say yes, connect it to mains ground.

I really don't get why people keep bringing up neutral which is something different.

I already bought an expansion board though (-: it would help with cable management, but tool boards are much cleaner IMO.

@dc42 so the GND header on the duet3 is just another DC neutral header?

PS: I am not connecting anything via USB, the Raspberry is connected via the SBC connector/SPI. I do have a ground loop filter for USB connections though.