RepRapFirmware 3.0 port for LPC1768/9 based boards

Hi all,
Very interesting. I have an Anycubic Predator + SKR 1.3 + RPi4 ready for the transplant and test of RRF3-SBC on it.
Some little questions:
1.- the RRF 3.01RC5 firmware-sbc you have published is the correct to use in my case? I mean, it has no network or others not needed as it will have an RPi connected by SPI and more RAM to buffers or others...
2.- about the DSF, I had to build it from scratch or it's better to install the standard version and rebuild the parts affected (by the fact it's connected to a LPC) directly on the Pi... Any case, any points to what to change (as the RFF was built to be SBC connected, has enough RAM to handle the comms with de Pi like the original Duet3 or almost more close, or I'm losing something)? And the .Net core 3.0 is old, may I use the LTS 3.1 instead? or it would take me more problems?
3.- I have the option to use TMC2208 and TMC2209 on the SKR, I would prefer the SPI ones, but I think that the SPI needed on the SKR is used on the SPC connection, so only TMC2208 is possible, I'm right?
I'm sorry if that has been talked somewhere before, I have read all and still have these questions on my head...
Kind regards from Spain
Chema

Hi, a few answers below...
1. Yes firmware-sbc is designed to work with LPC based boards and the SBC note that you will need a suitably configured board.txt file on the sd card in the sys directory.
2. I think it is better to install the unstable build and then basically follow the steps here: [reprap.org] you will need to rebuild the dsf using this command:

dotnet publish -r linux-arm -c Debug -o /opt/dsf/bin DuetControlServer.csproj

3. At the moment only UART control of TMC drivers is supported (and this is built into the firmware-sbc.bin version). I'm not aware of anyone getting SPI based drivers to work.

Edited 1 time(s). Last edit at 04/04/2020 10:33AM by gloomyandy.

I see that RC6 is now out (along with DSF 1.3), but there seem to be a few issues so I'm going to wait and let thing settle a little before merging that code over (though if I get really bored I may give it a go!).

Many thanx @gloomyandy. I would try to build that. And yes, the boring is moving a lot of people to do sometimes very nice things...

Ok folks,

I've been following the steps, but for sure I'm doing something wrong. Listing my steps:
1.- When installing the "standard" packages on the Pi, the DuetWebControl 2 works with "DCS is not started", so up to here seems correct.
2.- SKR is OK as M122 says the RRF is working ("RepRapFirmware for LPC176x based Boards (biquskr_1.3) version 3.01-RC5+1 running on LPC176x at 100Mhz")
3.- Changed to the unstable ARMV7 apt source list, updated and installed the last DSF via apt. DWC continues in the same way (it power up and "DCS is not started" message) so OK.
4.- Building your fork of DSF, no errors, but the DuetWebControl does not work anymore. Pi is working as I can access by SSH. Now I'm blind, don't know how to try anything but start services, no errors but no answer, DWC is off...
After that, I can remove DSF by apt, then install again (by apt) and it comes to stage 3 again. This takes me to my building is not correct. I'm using ".NET Core 3.1 SDK (v3.1.201) - Linux ARM32 Binaries" on the Pi directly, and made a git clone of your fork lpc-dev to the build...

Any help or light on the path would be appreciated.

Chema

Now it works partially. I don't want to edit my last message as someone can learn from my errors...

The only thing was to reboot the SKR, then it works, almost it connects... with the unstable version installed (via apt). It connects to DCS (as a machine with no axes or any other thing).

Then rebuilding the DCS (from lpc-dev fork), enable and start (systemctl start duetwebserver) the service and it seems to work (look at the screen shot).
Now I have lots of errors about something not configured correctly on the config.g (I assume), but I think that this could work...

I would refine the settings and install the new electronics in my Predator printer to start deeper tests.

Many thanks for your support and patience.

Chema

Remember that you need to move your config.g file (and any others) from the sd card to the virtual sd card on the pi to correctly configure your machine. The only file used from the sd card in sbc mode is board.txt.

Are you sure about this? I have been moving things on the config.g in the SKR SD and they become available on the DWC (on Pi)...
I have another confusing thing, the Pi SD has two partitions, the boot one has the sys, gcode, etc. folders, I was writing my configurations there (on sys/config.g for example), but when the Pi boots up, I can't find on it (connected by ssh, console) that populated folder, only in /opt/dsf/sd/sys, (but it was empty, only the blank config.g that says you have to populate it) so I copied the .g files there (with scp)...
Anyway, from the DWC says that the SD is not mounted, and it is working with the config.g on the SKR, but I'm not sure 100% about this...

Now I have the Predator than can home the three-axis, can heat the hot end and nothing else , a lot of hours today, so I will fight a bit more on Wednesday. I want to be able to print then something (so making the calibrations, bed levelling, etc. first).

I have connected the ZProbe (the Predator stock one, a switch with a magnet) to ZMax end-stop (Z+) but it is not working at all... Is there anywhere a list of the pins declared on firmware for the SKR1.3, as the end-stops (xstop and others)? Or I need to go by the M950...

Many thanks for your hard work on this. It could be a very nice port of a great software to the cheap SKR board with the aid of the powerful Pi4.

Regards
Chema.

I would be totally amazed if it was using the config.g from your SKR as the firmware does not have the file system enabled within it. You need to put the files into the /opt/dsf/sd/sys directory on the pi. I have never seen any sort of message about the SD card not being mounted, did you get that with the empty config.g file or only after you had changed it? I would start with a very minimal config.g file and add things slowly to it to build up the functionality, fixing any problems as you go.

@gloomyandy

I bet it's because DSF 1.3.1 is being installed as the latest version rather than 1.2.5

sudo apt install duetcontrolserver=1.2.5.0 duetsd=1.0.5 duettools=1.2.5.0 duetwebserver=1.2.3.1 duetwebcontrol=2.0.7-1 reprapfirmware=1.2.5.0-1 duetruntime=1.2.5.0 duetsoftwareframework=1.2.5.0

Should be used to get the correct version.
Then your changes can be applied.

Or update your DSF code and the firmware to 1.3.1 and RC6 respectively

---

Based in Darlington, North East

I would not recommend going to 1.3.1 and RC6 on an LPC based system at the moment. I sort of have it running, but have seen some problems that seem to be specific to the LPC version. I'm still investigating the problems at the moment. If anyone has a Duet based RC6 system with SBC at the moment I'd be interested to know if you have any problems with aG90/G91 or M82/M83 placed in the config.g file. On my system if I have those commands in the config.g and do an emergency stop then I get exceptions reported when the board restarts.

@gloomyandy

I have G90 and M83 in my config.g file on my duet 3 + SBC and it moves ok. No issues if I send an emergency stop either.
Want to give me a bit more detail to see if I can recreate the issue?

---

Based in Darlington, North East

The wiki for the project has been updated and can be found here
[github.com]

There are instructions for adding wifi or an SBC to the SKR 1.4.

Hopefully this will help people.

---

Based in Darlington, North East

@gloomyandy, you are right, my mistake (many changes at once). Now I have deleted all on the SKR/sys SD card but the board.txt and it works (of course from the Pi sys folder). But look at the screenshot, the drive is unmounted, so can't see anything by DWC (v 2.1.1) on there, I'm modifying by ssh on the /opt/dsf/sd/sys/... Not a big problem, but not so friendly.
@Jay_S, how can I check the version of the DSF I have installed? or any other part on the Pi. The DSF was built from the github

Regards from Spain
Chema

@ChemaFuji

I think all the DSF software installed from the unstable package branch won't be compatible with RC5.
I believe 1.3.0 and 1.3.1 and associated packages only work with RC6.

using

apt list duetwebserver

Will give you the package version.

If its not 1.2.5.0, then follow the wiki [github.com] from switching to the unstable branch

---

Based in Darlington, North East

Do you have anything in your config.g file that does anything with the sd card? I've no idea what is causing it to be reported as unmounted.

The SD dismounting issue has been coming up a fair bit with DSF 1.3.0
RC5 is also incompatible with it which won't help.

---

Based in Darlington, North East

When DWC 2.1.2 gets release, it will have support built in to ask the user if they want to reboot the board when the board.txt file has been edited in the same manner when the config.g file is edited.

---

Based in Darlington, North East

YEAH! I was at duetwebserver 1.3.1 and now at 1.2.3.1:

duetwebserver/unstable 1.3.1 armhf [upgradable from: 1.2.3.1]
duetwebserver/unstable 1.3.0 armhf
duetwebserver/unstable,now 1.2.3.1 armhf [installed,upgradable to: 1.3.1]
duetwebserver/unstable 1.2.1.0 armhf
duetwebserver/unstable 1.2.0.0 armhf
duetwebserver/unstable 1.1.2.1 armhf
duetwebserver/unstable 1.1.2.0 armhf
duetwebserver/unstable 1.1.1.0 armhf
duetwebserver/unstable 1.1.0.0 armhf

And now it seems to work very fine! I would continue fixing little things and testing.

Many thanks for your hard work on this.
Chema

When I order to heat the bed, the system disconnects Pi from the SKR:

	Warning: Lost connection to Duet (Timeout while waiting for transfer ready pin)

I'm going to do a little pcb to connect them in short (with the resistors) as now I have all this in the air, just to make it safe and discard any kind of bad electrical contact.
I'll write results.

Hi,
I've just pushed a release of RRF V3.01 RC6 and the associated DSF V1.3.1 to my github repos. Note that there have been a lot of changes in the DSF side of things and there are a larger than normal number of issues being reported over on the Duet forum. Because of this I would take particular care if you plan to try and use this release with an SBC setup. I've done a fair bit of testing and printed a couple of small test prints. I've seen a few issues, but the basics seem to work. I've tested the WiFi build a little and that also seems to work. I have not tested the ethernet build.
Binaries here:
[github.com]

Source:
[github.com]
[github.com]
[github.com]
[github.com]

I launched on SKR1.3 https://github.com/gloomyandy/RepRapFirmware/releases/tag/LPC_RRFv3.01RC5 firmware.bin with TMC2209 drivers and screen 12864. It seems that everything works. But I still need wifi through esp8266. In the firmware firmware-wifi.bin screen 12864 does not work. What should I do? Is it possible to simultaneously run "tmc uart", wifi and the screen?

All, I have updated the wiki page for the SBC installation.
It now covers RC6 only.

---

Based in Darlington, North East

I don't think there is enough memory to support all of those options. Unfortunately due to the lockdown I don't have access to a 12864 display so I can't test that at the moment.

OK friends. My printer is working with RRF 3.01RC5, the DWS 1.2.3.1 and all the DSF 1.2.5.0 in SBC setup. No problems by now. The connections between both boards is very fragile, so short cables and a little pcb to fix the resistors are the quid.
I'll fix some other minor things (a bracket for the SKR and silent fan for example), and try some large prints before upgrading to DSF 1.3.1 and RRF 3.01RC6.

Many thanks for your work and your support.
Chema

In this case, a huge request to implement full-fledged work through AUX, so that you can use cheap BIQU TFT24 / TFT32, MKS-TFT panels for control. Now through AUX we get the answer only in json on the M408.
Here is the patch that sdavi did Option for aux serial to output responses with compatibility mode for RRF2

Quote
bcmob
I launched on SKR1.3 https://github.com/gloomyandy/RepRapFirmware/releases/tag/LPC_RRFv3.01RC5 firmware.bin with TMC2209 drivers and screen 12864. It seems that everything works. But I still need wifi through esp8266. In the firmware firmware-wifi.bin screen 12864 does not work. What should I do? Is it possible to simultaneously run "tmc uart", wifi and the screen?

I's possible that I'm wrong, but I think that the 12864 uses the SPI to connect the SD reader it has, same as wifi module (and SBC mode), so you can use only one.

Quote
bcmob
In this case, a huge request to implement full-fledged work through AUX, so that you can use cheap BIQU TFT24 / TFT32, MKS-TFT panels for control. Now through AUX we get the answer only in json on the M408.
Here is the patch that sdavi did Option for aux serial to output responses with compatibility mode for RRF2

That option uses "TFT" that have "brain", that screens had a processor and communicates on a serial interface sending gcode commands, so no SPI...

Quote
bcmob
In this case, a huge request to implement full-fledged work through AUX, so that you can use cheap BIQU TFT24 / TFT32, MKS-TFT panels for control. Now through AUX we get the answer only in json on the M408.
Here is the patch that sdavi did Option for aux serial to output responses with compatibility mode for RRF2

The MKS TFT works with RRF on a MKS SBASE 1.3 ! Just that it is somewhat limited and no hope for it to evolve as it is MKS proprietary.

The RRF web interface is great but in my MKS SBASE 1.3 really slow to load (14 min !). OK once it is loaded though.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Alternately why not add the code needed to handle the json or the Panel Due interface to one of those displays? I'm not sure adding more features to support these different displays makes sense for RRF (which is already pretty complex, and pushing at memory limits). There are a few projects that are working in this sort of area:
[github.com]
or perhaps something like this may be of interest (though I'm not 100% sure it will work at the same time as actively using the web interface over WiFi):
[forum.duet3d.com]

My solution is to use the SBC setup with a rPi and hook up a touch screen to the Pi.

Now I am engaged in alteration of BIGTREETECH-TouchScreenFirmware firmware
The basic functionality is already implemented.

Edited 2 time(s). Last edit at 04/10/2020 05:58PM by bcmob.