RepRapFirmware 3.0 port for LPC1768/9 based boards

@MKSA

DWC does that to people!

A duet maestro will probably do what you want

---

Based in Darlington, North East

@jay_s @sdavi
Note that what puzzles me is that once DWC is loaded and I have control, I can transfer a gcode file of about 10MB (4 times the script file size app.9fed7e58.js that takes 15min !) in about 10s !

---

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

Quote
MKSA
@jay_s @sdavi
Note that what puzzles me is that once DWC is loaded and I have control, I can transfer a gcode file of about 10MB (4 times the script file size app.9fed7e58.js that takes 15min !) in about 10s !

What about downloading that same gcode from the LPC? (in DWC right click on the gcode file and select download) Maybe when sending from LPC it is slow?

@jay_s Maybe you can look into it this as you are also getting slower speeds to test with? It would be good to see whats going on with wireshark to see if there is any TCP transmission issues etc.

Quote
sdavi

What about downloading that same gcode from the LPC? (in DWC right click on the gcode file and select download) Maybe when sending from LPC it is slow?

@jay_s Maybe you can look into it this as you are also getting slower speeds to test with? It would be good to see whats going on with wireshark to see if there is any TCP transmission issues etc.

I tried but nothing happens. I can start the job, rename, delete it but can't download it back or edit it.

I can see the command rr_download?name=... but no answer

Also what about the command rr_connect?password=reprap&time=2020... . Plenty of them that seem to be rejected

---

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

So I've just rechecked the sort of connection I was getting with my MKS SBase. In my case it is 10Mbit/s half duplex (which is odd because this was to a 1GBit/s switch and the rest of my wired network runs at either 1GBit or 100Mbit), but even with that connection speed the DWC startup time is less than a minute.

hei guys! is it someway to run pt100 on this port? I have tl amplifer so what i need to write here?

M308 S1 P"e0temp" Y"??????"

Edited 2 time(s). Last edit at 03/12/2020 08:18AM by 7ambrion.

Quote
7ambrion
hei guys! is it someway to run pt100 on this port? I have tl amplifer so what i need to write here?

M308 S1 P"e0temp" Y"??????"

Supported sensor types in RRF can be seen here: [duet3d.dozuki.com] .

I have a PT100 working on the port, but its with a MAX31865.

Edited 1 time(s). Last edit at 03/12/2020 08:58AM by sdavi.

@sdavi, ok, thanks. i had a hope that MAX31865 needs just to duet boards

You could probably use the LinearAnalog sensor type with a PT100 + amplifier, but you would need to calibrate it, and it won't be as consistent as a MAX31865.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

i have purchased thirdparty max31865 and it looks like its have a lot of pins need i all of them or its just a one signal pin? and how about 430 resister, will it work with this gcode?

M308 S1 P"e0temp" Y"rtd-max31865" R430

@dc42, thanks, i'll try it while I wait a max31865

Quote
7ambrion
i have purchased thirdparty max31865 and it looks like its have a lot of pins need i all of them or its just a one signal pin? and how about 430 resister, will it work with this gcode?

M308 S1 P"e0temp" Y"rtd-max31865" R430

It uses SPI, so you need to connect the MISO, MOSI and SCK to SSP0 on the LPC, and the ChipSelect pin to a spare LPC pin. The P param for the 31865 is the chip select pin.

Here is my settings for the MAX31865 (430Ohm reference and CS on pin 0.16):

board.txt
heat.spiTempSensorCSPins = {0.16};

config.g
M308 S1 Y"rtd-max31865" P"0.16" R430

@dc42 @sdavi not sure if you are looking at this thread but... I'm in the process of updating to RC4 but have hit a couple of problems. There are a number of new items that have been added to the object model, but some of these are causing compilation errors when built with some of the options we use for some of the LPC builds. In particular the object model reference to "powerFailScript" fails if the HAS_VOLTAGE_MONITOR setting is false. Similarly the new entries for "gCodes", "macros" and "web" cause errors if HAS_MASS_STORAGE is set to false. I'm happy to go ahead and fix these but I'd appreciate some advice and what the best was is to handle these sorts of items if the underlying object is not available, should the item still be present in the object model (but return some sort of null value), or should they be removed from the model?

Quote
gloomyandy
@dc42 @sdavi not sure if you are looking at this thread but... I'm in the process of updating to RC4 but have hit a couple of problems. There are a number of new items that have been added to the object model, but some of these are causing compilation errors when built with some of the options we use for some of the LPC builds. In particular the object model reference to "powerFailScript" fails if the HAS_VOLTAGE_MONITOR setting is false. Similarly the new entries for "gCodes", "macros" and "web" cause errors if HAS_MASS_STORAGE is set to false. I'm happy to go ahead and fix these but I'd appreciate some advice and what the best was is to handle these sorts of items if the underlying object is not available, should the item still be present in the object model (but return some sort of null value), or should they be removed from the model?

I've updated my github with my local changes that fixed some of those already (only those affecting the wifi build) if your interested. In my build I prefer to remove those unused items from the object model, especially since flash is now quickly filling up in 3.01.

I also merged and made changes to your RIT additions (and also software pwm as a result) to avoid the division etc - I've not tested my changes though. Also added in a "configurable" UART class that can select any hardware UART or be disabled (to free a little more memory from the ring buffers that are now allocated dynamically or free up AUX pins to use for something else) from board.txt without needing to recompile - only quickly tested with UART2.

Edited 3 time(s). Last edit at 03/17/2020 02:28AM by sdavi.

I suggest you remove them from the model. Some model properties are dependent already on HAS_V12_MONITOR and I suggest you use HAS_VOLTAGE_MONITOR in the same way.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I've just committed some changes to support build configurations with HAS_VOLTAGE_MONITOR and HAS_MASS_STORAGE disabled. I hope this helps.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

@DC42 that's brilliant thanks, makes things much easier. Quick follow up question. which DSF branch should be used with RC4, "dev" or "dc-rrf3.01-RC4"? Thanks again.

Both WiFi and SBC builds seem to be working for me now. I've merged the configurable UART code along with RC4 and the updated board.txt entries. I'm going to test things a little more and will then upload the binary files.

My SBC test rig with HDMI touch screen: [photos.app.goo.gl]

Quote
gloomyandy
@DC42 that's brilliant thanks, makes things much easier. Quick follow up question. which DSF branch should be used with RC4, "dev" or "dc-rrf3.01-RC4"? Thanks again.

Use dev, it now includes the fixes from my branch.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

@gloomyandy

Not having much joy getting the SBC version to work.
I'm using duetpi (all updated from the unstable branch) as a base and have cloned and built duetcontrolserver from your repo using the command you posted on page 5.
I've also connected to pi to the SKR as we've discussed and I'm using RRF3 build for SBC.

When I load DWC, i get an error saying that DCS is unavailable.

Any thoughts?

---

Based in Darlington, North East

Hmm I'm not sure what to suggest. I have literally just redone pretty much everything using the latest RRF3 RC4 (with sdavi's changes merged in) and the latest DSF (from the dev branch) and it all works fine (I now have it working on my actual pronter and used it just now to print a case for my pi 4). If you are using the latest version of my repo make sure that you have updated the board.txt file to use the new rationalised names for the pin used to handle sync between the LPC and pi. I did pretty much the same as you...
1. Built the latest RRF3 RC4.
2. Updated the board.txt file
3. Switched to the unstable branch and did an update/install.
4. Built and published the modified DCS using my fork.
5. Hooked everything up.
6. Booted the lpc.
7. Test
Everything worked fine for me. The updated pin names are here: [github.com] Probably worth checking things with M122 P200 Are you sure the wiring between the boards is ok? I'm using a pretty short cable between the two boards (20cm) and on my new adaptor board I've used 100Ohm resistors on all of the connections (other than ground).

I do have a few changes that I've not pushed yet, but I don't think they should make any difference

I hadn't realised you'd changed the pin names. I probably should've read the change log.
Updating that fixed it.
Time to get it installed in a printer.
Watch this space

---

Based in Darlington, North East

Yep those changes got picked up from Sdavi I think they make a lot of sense. Good luck with the printer. I've noticed a couple of odd things mainly to do with the time estimation and the layer information, I don't think that DSF/DWC handle the latest Prusa Slicer (which I'm using very well). It prints fine, but the information displayed is wrong. I have some changes which fix some of the problems.

@gloomyandy

Have you seen that the schematic for the SKR has been released now? [github.com]
The 5V stepdown SGM6130 can apparently handle up to 3A output. Think we could get away powering the pi from this?

On another note, there seems to be an issue with homing hanging if the response expected isn't received. This isn't an LPC issue and seems to be linked to DSF in general.
Not managed to print anything but axis move ok and it seems to a lot more stable than using ESP.

---

Based in Darlington, North East

Not sure about powering the Pi from the SKR board. I also need to be able to power an HDMI touch screen (attached to the Pi) so I've taken the option of using a buck converter to drop the 24V supply to 5V for the Pi. I'm not sure how well it works though as I still see the odd lower power notification from the PI, may be due to voltage drop in the cable between the LPC and the Pi (which is basically 20 way ribbon cable, I've doubled up the connections for ground and 5V but the are still not very substantial).

I've not seen any issues with homing so far with the SBC setup, but it does seem that there are a few problems with DSF and I'm not sure how quickly they will be resolved. I think in general the LPC/SBC combination may be the better one than LPC/ESP as I think running the ESP with only two connections was right on the edge of the web interface working and it was very easy to provoke network errors because the web interface tried to open a 3rd connection. SO far I've not seen any issues with the LPC/SBC interface though it does concern me that we are running with a smaller set of buffers and that the object model does not supply some items, which may cause issues if/when the SBC side starts using more complex scripts and things. But I guess we will have to wait and see how that works out. So far I've been able to print a few test items and a case for the rPI 4 all using the LPC/SBC setup and no problems with that.

@gloomyandy

Would there be a way to have any thermostatic fans controlled by the board rather than the raspberry pi?
It can take a while for the raspberry pi to come back online if you have to reboot the system for some reason

---

Based in Darlington, North East

Hi Jay the fans are controlled by the LPC, but the problem you will have is that the configuration of the fans etc. is driven by the SBC which means the board has no idea that there are even fans attached until the SBC boots and reads the configuration files. I'm not sure there is an easy way around that. What fans are you worried about? I guess if you want to be safe just run those fans all of the time (noisy but safe). Does this same problem exist with a Duet board? I'm not sure if the Duet will read the local configuration files when in SBC mode or not, which would be a way around this in that case. If the same problem exists with a Duet it may be worth opening a discussion on the Duet forum?

I've just updated things to RC5 from DC42 and have also built binary files for ethernet (firmware.bin) WiFi(firmware-wifi.bin) and SBC/rPi(firmware-sbc.bin). I've done a small amount of testing of the SBC and WiFi versions, but have not tried the ethernet build (no hardware to test that where I am for the lockdown!).
[github.com]

I've tried the ethernet version out and I can't get it to connect to my network (on an MKSSbase).
If its enabled for DHCP, the IP address remains as 0.0.0.0 and nothing ever gets assigned.
If I assign an IP address, subnet and gateway, it still doesn't show up.

Is there any info I can gather that would assist?
RC4 is also the same.
I've found it difficult building previous versions as although the firmware itself is tagged for the versions, CoreLPC4RRF and RRFLibraries aren't.
I know somewhere around RC2 or RC3 were working

---

Based in Darlington, North East

All of the repos are tagged with RC5, I didn't make an RC4 release as RC5 appeared before I'd uploaded everything!

I've just uploaded firmware-eth-notmc.bin which disables the TMC22XX support for the ethernet build, I seem to remember that my Sbase did not work unless I did that.

That's working ok now.

And I meant RC4 that I'd self built. Don't think I'd set TMC22XX to false though.

---

Based in Darlington, North East