Uploading firmware is same procedure as Smoothieware, i.e. copy appropriate firmware file as firmware.bin to the SDCARD and reset.

Notes:

Very Experimental at this stage - Use at own risk - Do not leave unattended etc etc etc.

The "Play" LED (on ReArm? and Azteeg X5 Mini) or LED1 (on Smoothieboard) should blink every 500ms which is controlled via the Systick interrupt.

RRF doesn't mount the SD card as a MSD like smoothie does. You may need physical access to the SDCard, if things go wrong and can't upload a new firmware.bin to the SDCard, or, want to revert back to smoothieware.

Currently the following features are disabled: SPI thermocouple; ethernet; and, Reset/fault Diagnostics.

RRF only supports 3 endstops + probe, so on boards with both max and min endstops, the MAX endstop headers are used by default for XYZ endstops (as either max or min), and Z-Min being used for zprobe. The X Min and Y Min pins are free for other purposes.

Currently no mapping of spare pins to Special pins controllable with Gcode for Smoothieboard and ReArm.

Zmin (currently configured for z-probe) is not ADC capable. If need Analog In for probe then update header files to switch to a spare ADC pin.

I've tried to pack RAMs AHB0 and AHB1 leaving around 8k main RAM free which hopefully will be enough for auto-calibrations etc?????

Unfortunately, I don't have a spare printer for testing, but I did have it temporarily connected on my printer and was able to home, heat hotend+bed, probe bed with piezo probe and print a hollow cube test print. I don't have a delta, corexy etc so haven't been able to test those.

I've got a CR-10 running a RE-ARM + Ramps 1.4 SB Premium. and willing to be a guinea pig if you'd like. I'm running marlin 2.0 right now and it's good but also been interested in RRF and their webgui if this supports the re-arm ethernet module. Besides just flashing, I assume I do the RRF online config to create the .g files?

Guinea pigs very welcome, especially a ReArm one since I don't have access to one to test. Make sure to check the enstops first, as mentioned in the first post. These can be changed in source code but does need to be re-compiled tho.

I haven't looked into the ethernet part yet. It will depend on how much RAM is required etc. I really hope there is enough as the RRF web gui is very good.

Yeah, you can use the online config tool and upload to the SD Card. Fortunately they do not overlap with the smoothieware config so they can all co-exist together on the SDCard nicely. I've attached the config for my azteegx5 for reference (which is actually the same config as what i use on my Duet Wifi with some of the settings for setting the microstepping etc removed although I dont think they will cause any issue if they are left in there) - running a standard cartesian with E3Dv6.

Quotesdavi
I haven't looked into the ethernet part yet. It will depend on how much RAM is required etc. I really hope there is enough as the RRF web gui is very good.

I'd love to see the Ethernet interface working on the LPC port; but I think RAM usage may be a problem. AFAIK the LPC processor on the current Smoothieboard and clones (including Re-ARM) has only 64Kb RAM. Even the legacy Duets had 96kb RAM and RRF for them used most of it. The current Duets have 128kb RAM.

You could reduce the RAM usage somewhat, for example by reducing the maximum number of stepper motors supported (maybe you already have) and therefore the number of DriveMovement objects allocated. Also you could save on RAM needed for the Ethernet interface by only allowing one HTTP connection at a time. Finally there are some buffers used to read and write info to/from the SD card, and these could all be reduced to 512 bytes, at the expense of file upload speed.

HTH David

PS - there are 2 separate networking subsystems in the RRF source tree for handling built-in Ethernet ports: the one for the legacy Duets which is based on LWIP 1.4 and in subfolder Duet, and the one for the SAME70 which is in subfolder Networking. The one for the legacy Duets almost certainly uses less RAM than the other one..

Quotedc42
I'd love to see the Ethernet interface working on the LPC port; but I think RAM usage may be a problem. AFAIK the LPC processor on the current Smoothieboard and clones (including Re-ARM) has only 64Kb RAM. Even the legacy Duets had 96kb RAM and RRF for them used most of it. The current Duets have 128kb RAM.

You could reduce the RAM usage somewhat, for example by reducing the maximum number of stepper motors supported (maybe you already have) and therefore the number of DriveMovement objects allocated. Also you could save on RAM needed for the Ethernet interface by only allowing one HTTP connection at a time. Finally there are some buffers used to read and write info to/from the SD card, and these could all be reduced to 512 bytes, at the expense of file upload speed.

HTH David

PS - there are 2 separate networking subsystems in the RRF source tree for handling built-in Ethernet ports: the one for the legacy Duets which is based on LWIP 1.4 and in subfolder Duet, and the one for the SAME70 which is in subfolder Networking. The one for the legacy Duets almost certainly uses less RAM than the other one..

Thanks for the pointers David, that will certainly save some time looking for places to squeeze some extra RAM if needed.

Yes, we only have 64k total - 32k of main RAM and another 2 16k blocks of RAM. That makes it a bit trickier juggling around the objects into the different banks. The 2 16k blocks are contiguous address wise, however the manual does mention they are each on separate slave ports on the AHB so I'm not sure if its possible to use it as a single 32k block (would make it a bit easier) but i'm unsure what would happen if an object spanned across the 2 so i've left separate for now (this is way outside of my knowledge ).

Currently, we have 8236 bytes of "never used" main RAM, 1192 free in AHB0 and 8364 free AHB1. There was a comment in configuration.h that delta calib needs 3584 extra stack for 32points, which leaves us with around 14208 bytes (minus any extra stack we need).

I did find a version of lwip 1.4 lpc port just today so i'll definitely check out the legacy duet part and hopefully this drops in just nicely.

You might not be able to do a DMA transfer that spans the junction between the two 16-bit blocks, also an unaligned 16- or 32-bit access that spans the blocks might not work (but unaligned accesses are rare in the code). So I think you should be able to treat it as a single 32k block. You can reduce the maximum number of calibration points to 16 because few people use more than that.

The code in the Lwip folder is processor-independent, but you can tweak lwipopts.h to reduce memory usage. The Ethernet code that is specific to the ATSAM3X8E is in the EMAC folder.

HTH David

PS - please keep me informed of progress! I am likely to be giving a talk on RepRapFirmware next month and one of the topics I will be covering is which electronics it runs on.

Ok, I tried RRF configurator but no serial access. I'll give yours a go and see how she chooches as I run a e3d as well.
Sucks to think it might not get RRF's web interface and functionality such as live editing which to me is a huge perk. I will be going duet ethernet on my rostock max v3 once I can afford it new by the end of the year I hope or find a sale/used one once duet2 comes out.
Marlin 2.0 has been great so far, smoothie was a horrible experience with how it's coded especially no z probe endstop but configuring was easy and nice. It also sucks that RRF is pretty limited to specific boards only, I mean I can understand that making money is needed to provide a more premium firmware so to speak.

Also, I assume I just modify you configs to suit my bed and offsets as usual. When using the config tool I set it to rrf type not like marlin so maybe thats why I got no serial support.

Seems my stops are on the axis min just need to move them to max, then in the configuration tool set their end stop locations to 'at high end' and leave z to "at low end". Still faster than I got smoothie to even do anything lol

EDIT:
I don't know the trigger height of the capacitive probe just the offset, is this important at all and do I need to measure it?

Seems my stops are on the axis min just need to move them to max, then in the configuration tool set their end stop locations to 'at high end' and leave z to "at low end". Still faster than I got smoothie to even do anything lol

EDIT:
I don't know the trigger height of the capacitive probe just the offset, is this important at all and do I need to measure it?

Yeah, the marlin compatibility seem best suited for most of the host programs. But yet another good reason to try and get the ethernet web GUI up and running

With the endstops, it gets a bit confusing on the Smoothieboard and Re-Arm as they have both min and max endstops for each axis. Whereas the Duet (Reprapfirmware) and the AzteegX5 only have 1 endstop per axis - which causes a bit of a naming convention issue on the boards that have both.

At the moment, I have set it so that the Z-Probe connects to Z-Min header on the board, and the 3 axis endstops are connected to X-Max, Y-Max, Z-Max headers (regardless if they are at physically at Min or Max on the printer). So in the configuration just choose where they are physically on the printer (for most people on cartesian printers they are home to min) and choose if they are active high or not. In my config, I only have X and Y configured as normal NC microswitch (which is homed to min) and a piezo Z-Probe.

There is some documentation here. I'm not all that familiar with the RRF configuration, but the documentation is very good and there are lots of examples out there.

Quotecyris69
Endstops aren't working no matter how configured as well as the pins must not be right for the axises. Is this something I could compile?

Hmm this is whats in the config now: X Max - P1_25, Y Max, P1_27, and Z-Max P1_28 which i got from the PDF on the Panucatt website. I'll see if i can find the smoothie config for the rearm and check that too.

Can you run M122 for me and make sure it says ReArm as the board type just under the ===Platform=== heading, just to make sure i actually put the right firmware file there?

And can you confirm what endstops your using i.e. normal microswitches etc? And attach the config.g your currently using?

I was able to get xy to trigger they are your run of the mill reprap endstops. Your re-arm pins are correct I went through your code.
Can't get probe though, here is all the output. Also in the rrf tool I picked the unmodulated or smart ir probe since it was default and not sure which for capacitive NPN NO probe. Also seems motors aren't activating using the values taken from your config. Sorry, I'm not a big software configurer so a lot of this is still new to me. Been printing for over 5 years but never really did much besides use pre-built firms.

Quotecyris69
I was able to get xy to trigger they are your run of the mill reprap endstops. Your re-arm pins are correct I went through your code.
Can't get probe though, here is all the output. Also in the rrf tool I picked the unmodulated or smart ir probe since it was default and not sure which for capacitive NPN NO probe. Also seems motors aren't activating using the values taken from your config. Sorry, I'm not a big software configurer so a lot of this is still new to me. Been printing for over 5 years but never really did much besides use pre-built firms.

At least we are getting somewhere with the X and Y triggering. I've only been using RRF for about 6 months now but don't know a lot about the different configurations - configured it once and never had to touch again.

I did find some documentation about Connecting a ZProbe and M558 Setting Z probe. The docs mention a capacitive NPN probe needs to use Mode 4 (on a duet) - but this uses the E0 endstop rather than the Probe connector. However, Mode 4 wont work for us currently as its set to NoPin in the config. There must be a good reason they use NPN sensor on E0 (hopefully someone in the know can shed some light on this???). A quick look at the RRF code shows E0 doesn't have the internal pullup enabled, so possibly the pullups affect those sensors? However, I've never used a capacitive sensor before so i really don't know sorry. Hopefully someone else here has some answers?

On the Duets you can use NPN sensors with the Z probe input too, but depending on the amount of leakage from your sensor output you might need to add an external pullup resistor to +3.3V. The reason we suggest using the E0 input is because on the Duets it includes an LED + resistor pullup already.

Quotedc42
On the Duets you can use NPN sensors with the Z probe input too, but depending on the amount of leakage from your sensor output you might need to add an external pullup resistor to +3.3V. The reason we suggest using the E0 input is because on the Duets it includes an LED + resistor pullup already.

Thanks for the quick response.

Looks like the ReArm has external pullups to 3.3v on the endstops, so in that case try it at Mode 5, such as M558 P5 H5 F120 T6000 I1

Ok, that line of code worked in terminal and all motors moved to home, just my x/z axis thinks min is to the right when it should be left/down. How do I save it to memory, does M500 work with RRF? Also anyway to set z to home to XY 150+offset before probing?

EDIT:
SO my probe has an x offset of -41 from nozzle, z offset to move down at start of print is -3.45mm, I know large value but I'm lazy to relevel etc. But this is how it's shown in config, why is the offset to move down after homing for print set in the Y axis and I assume the Z is trigger height which I think I make it 3mm from nozzle when setting the probe up

Quotecyris69
Ok, that line of code worked in terminal and all motors moved to home, just my x/z axis thinks min is to the right when it should be left/down.

Good to hear the probe is working now. If the axis moves the wrong way when jogging then just need to change the settings in config.g where it says drives: i.e. M569 P0 S0 change to M569 P0 S1 (for the x-axis). P0 (Drive0) is X, P1 is Y etc. The S value is 0 or 1 to make it go backwards or forwards. Also, RRF has macros for homing (in /sys on the sd card) so also check homex.g, homey.g, homez.g and homeall.g. If they are homing to min you should see a -ve move, i.e my homex has G1 X-255 to make it goto the endstop at the min side. Its a bit different to the other firmwares, RRF is very configurable but does take a bit of extra learning.

Quotecyris69
Also anyway to set z to home to XY 150+offset before probing?

Yep, just edit those home files on the sdcard and tell it where to move to. Have a look at my config files homez.g and homeall.g as I move to the center of the bed to do the probe to home Z.

Quotecyris69
How do I save it to memory, does M500 work with RRF?

Yes it does support M500. It will save it to the SDCard, but you need to edit the config.g to tell it to load those overrides when you reset the board by adding this to the bottom:

M501 ; Load saved parameters

Quotecyris69
SO my probe has an x offset of -41 from nozzle, z offset to move down at start of print is -3.45mm, I know large value but I'm lazy to relevel etc. But this is how it's shown in config, why is the offset to move down after homing for print set in the Y axis and I assume the Z is trigger height which I think I make it 3mm from nozzle when setting the probe up

That came from the web config tool? Maybe you accidentally entered the numbers in the wrong spot? But yeah the Z offset will use the Z param as you would expect it should I believe the Z offset are different to marlin, in your case should be Z3.45 and not negative - i.e. when you home Z it triggers the probe and stops so now the machine's Z position (nozzle height from bed) is actually at z=3.45.

Quotecyris69
Also, I'm using DRV88235's physical pot, all but extruder is 1/32 but getting:
M350: Drive Z does not support 32x microstepping

Don't worry about that, M350 isn't actually needed and you can delete that line if you want - microstepping is set by jumpers on the RAMPS. I'll make it ignore those warnings for the next update.

Quotecyris69
Recv: Error: Attempting to extrude with no tool selected.
Changing monitoring state from 'Operational' to 'Error: Attempting to extrude with no tool selected

RRF starts up with no tool selected. You need to send the command T0 to select the first tool (hotend). I have T0 at the end of my config.g so its already selected when it starts, but i think most slicers these days will put that in the start of the gcode file.

Ok good to know, I reset the machine and assumed it would keep settings but it didnt so I'll mess with that again. I'll look at your config about the tool selection..

Have any idea why hotend is working but bed isn't being triggered? It is controlled by a mosfet board which is wired into the board like you'd normally do if direct. Worked on marlin/smoothie but haven't gotten down to reading more of the code yet. However, this all feels quite promising at its current state as the issues are PEBCAK. I plan on if all goes well to get another rearm and use it on my rostock max v3 since duet no matter how much I drool over just won't ever happen

So what you are saying is that the offset for the probe where I had in marlin as -3.45mm which I'm sure if you've used marlin, I assume you have so know how it works. So when printing it would be at default 10mm from bed then move down 10+offset from nozzle to bed so technically -13.45mm total down to bed with enough space between to print a normal first layer.. With that said I'd actually just put offset how high I want the nozzle to be not how much its moving down, so I'd use lets say I like my nozzle to be about 0.05 to 0.10 from the bed I'd just enter positive 0.05 or 0.10 not -3.45. I don't have an LCD so not sure how to babystep it down so just use octoprint to move down until the prob trigger and measure distance from nozzle to bed or just from probe to bed?

EDIT:

How I did my probe setup originally was put a 3mm thick piece of aluminum under the probe then let the probe rest on it and tighten it down then put the same metal under the nozzle and let that settle while the bed is up to temp then adjust the trigger distance which will be ~3mm. Then add my positive offset or 0.05-0.10 or whatever. I also noticed that I hade T0; at the end of my config already.

Quotecyris69
Have any idea why hotend is working but bed isn't being triggered? It is controlled by a mosfet board which is wired into the board like you'd normally do if direct. Worked on marlin/smoothie but haven't gotten down to reading more of the code yet. However, this all feels quite promising at its current state as the issues are PEBCAK. I plan on if all goes well to get another rearm and use it on my rostock max v3 since duet no matter how much I drool over just won't ever happen

Yes, sounds like its very close now, mostly just getting config files sorted so far. Can you confirm that the bed temperature is reading the right value (around room temp) by running M105 or looking at the temps in the host program. Also, I think there was a LED on the bottom of the RAMPS board which goes on when the heaters were enabled, is the LED turning on? The ReArm pinout says the Heated Bed is P2_7 which is what i've used in the code.

Quotecyris69
So what you are saying is that the offset for the probe where I had in marlin as -3.45mm which I'm sure if you've used marlin, I assume you have so know how it works. So when printing it would be at default 10mm from bed then move down 10+offset from nozzle to bed so technically -13.45mm total down to bed with enough space between to print a normal first layer.. With that said I'd actually just put offset how high I want the nozzle to be not how much its moving down, so I'd use lets say I like my nozzle to be about 0.05 to 0.10 from the bed I'd just enter positive 0.05 or 0.10 not -3.45. I don't have an LCD so not sure how to babystep it down so just use octoprint to move down until the prob trigger and measure distance from nozzle to bed or just from probe to bed?

To measure the offset go down until the probe triggers, then measure the distance from that position until the nozzle touches the bed. Lets assume that you measure 3.45mm. Update config.g to have your G31 P500 X-41 Y0 Z3.45 and when you run G30 (do a single probe) soon at the probe triggers RRF then loads that offset, in this case 3.45mm, as the new current Z position. If you dont like that as a starting point, then you can edit homez.g and homeall.g and tell it it move closer to the bed after it probed. Here is an example for homez.g (assuming there is no z_max endstop, using probe to home z and the offset is correctly set) to lift up 5mm (to always ensure the probe is above its offset height), move to bed center, probe, then move nozzle to be 0.1mm from bed:

However, I'd probably recommend to not do it like that in case you want to run auto level or something before each print. My preference is to move back up the 5mm after a probe in homez.g, and in the slicer start G-code tell it to move close to bed before it starts heating so it doesnt ooze out at the start. But RRF is very configurable so you can do what ever suits your needs best

Apparently My hot end has been at 200C for like 18 hours without me knowing... however the M105 reports the correct room temp for the bed.

This is how I have my ramps wired, haven't noticed any new lights flashing and on my mosfet board for controlling the bed has an LED that will blink light when its sending power to bed. If you look at the LED closets to the group of mosfets the LED labeled LED1 is red and constant lit as normal no other LEDS are lit

Got motors going correct way, can extrude and its pushing the right way. Part fan doesn't do anything but maybe thats the firmware. I just used second hotend terminals like I found to do online so maybe need to adjust that somehow. Alos, when setting the z offset, if I do a home for Z it just goes down 5 then back up even though I tested at Z5 offset.

Also seeing if it was because I wasn't using G30, so I tried that and got this:

Quotecyris69
Apparently My hot end has been at 200C for like 18 hours without me knowing... however the M105 reports the correct room temp for the bed.

This is how I have my ramps wired, haven't noticed any new lights flashing and on my mosfet board for controlling the bed has an LED that will blink light when its sending power to bed. If you look at the LED closets to the group of mosfets the LED labeled LED1 is red and constant lit as normal no other LEDS are lit

Number one rule of 3D printing safety, never leave it running unattended and make sure power is off.

Hmm, I checked the smoothie config for rearm and it also says 2.7. My AzteegX5 pin out is actually quite similar to the rearm, and luckily the Bed on it is also 2.7, so i loaded up the rearm bin onto the azteeg and my bed heater led does turn on. So i'm not sure why its not working for you on the ReArm. I dug out my old RAMPS board, and the LED for the bed is behind the mosfet, between the mosfet and extruder driver, the led is labelled LED2. I assume the external mosfet board is powered by the same power supply as printer ?

Quotecyris69
Got motors going correct way, can extrude and its pushing the right way. Part fan doesn't do anything but maybe thats the firmware. I just used second hotend terminals like I found to do online so maybe need to adjust that somehow. Alos, when setting the z offset, if I do a home for Z it just goes down 5 then back up even though I tested at Z5 offset.

Found out why the cooling fan doesnt work. I had it setup as 2nd heater in the config, and inadvertently also again the same pin as cooling fan pin. Attached updated firmware.bin for ReArm with 2nd heater (as named in the docs) configured as cooling fan - see if that fixes the fan issue.

Is the Z-axis confirmed to be moving the right way? It should move up 5 (or whatever is in the homez.g and/or homeall.g) to make sure the probe isnt triggered before beginning the G30 probe.

Updated experimental version released: download here. There are now 2 versions: Network and non-network versions. Currently, they are the same except one does not have the networking code compiled in.

Changes:

Updated to RepRapFirmware 1.21

Combined AHB SRAM 0 and 1 to make memory management a bit easier. Both locations are DMA safe addresses for ethernet DMA transfers.

Bug fixes from first version:

Updated to detect CPU speed for LPC1768 (100MHz) and LPC1769 (120MHz)

Fixed bug affecting correct heater operation on P2.7

Updated step interrupt timing to match 128 divisor which DDA was also expecting.

Added Ethernet support (8720A PHY chip only)

!Important! If running the network firmware on a board without a PHY chip or on a board with optional LAN adapter disconnected, you must disable Networking in config.g. The LPC will stop responding if attempting to initialise EMAC without the PHY chip connected. Networking can be disabled by setting M552 S0 in config.g

Networking currently requires a lot of memory. In order to free enough memory and also allow for a delta configuration + calibration, the following compromises were needed:

Reduced maximum number of probe points to 121

Delta maximum calibration points to 16

Max files open limited to 3

Only 1 HTTP connection permitted at a time. This will also make the initial load of the webpage a slightly longer. Since there is only 1 listener downloading from the GUI can cause it to "disconnect" as the ajax status update calls will fail. Increasing the AJAX retries in the Settings Panel on the GUI can help - a retry count of around 10 seems sufficient for general usage including loading/saving config/macro files. The main cause for disconnect would be downloading a large file from the SDCard, which is probably not something most people would do anyway - just need to click connect again after the download to reconnect. Uploading GCode files to the SDCard doesn't cause any issue.

MDNS and Netbios disabled.

Telnet and FTP access disabled.

Reminders:

RRF only defines a single endstop per axis. It can be configured as a max (high end) or min (low end) endstop.

Boards with both Min and Max endstop headers should be wired as:

X_Min

(Spare)

X_Max

Wire to X Endstop

Y_Min

(Spare)

Y_Max

Wire to Y Endstop

Z_Min

Wire to Z Probe

Z_Max

Wire to Z endstop

By default there are no E0 and E1 endstops. So don't choose a probe mode which requires them (or if needed can modify header config file and compile). Those using induction NPN probe should use Mode 5 (confirmed by cyris69).

RRF is optimised for drivers on the Duet board, therefore some boards will require different pulse timings (see below) to avoid losing steps.

v1.21 by default now requires all axes to be homed before any axis can be moved.

As a starting point, use the RepRapFirmware Configuration Tool to create and download initial config files. Select the Duet Ethernet as the board, but please be certain to check the config.g afterwards, specifically: disable Networking if needed, adding correct stepper driver timing pulses (see next) and ensure correct z-probe setup (if using one). Please refer to the RRF GCodes for detailed information for settings in config.g.

Motor driver configuration M569 add the T parameter to select correct step pulse timings. The Azteeg X5 Mini has DRV8825, ReArm has pluggable drivers (refer to datasheets for specific driver settings). I have extracted some popular driver settings from the datasheets as a starting point.

Driver

Width

Interval

Setup

Hold

DRV8825

1.9

1.9

0.65

0.65

A4988, A4982

1.0

1.0

0.2

0.2

A5984

1.0

1.0

0.4

0.4

Known Issues

Running GCode that returns large amount of text to the "console" through the Web Gui will cause the firmware to become unresponsive (I.e. running M503). Do not run these commands during a print.

Wow, I'm impressed that you managed to enable networking using only 64kb of RAM!

I suppose it's too much to hope that there's another chip pin-compatible to the LPC1769 with 128kb RAM, that could be used to upgrade existing boards? 128kb is enough to run the in-development RTOS version of RepRapFirmware.

You might be able to fix the M503 issue (and I suspect you may find an issue with M122 as well) by generating part of the response, then returning to allow the web client to take that part and release the buffers, before you generate the next chunk. But this might still cause momentary pauses if you use those commands during a print.

Quotedc42
Wow, I'm impressed that you managed to enable networking using only 64kb of RAM!

It is very tight at the moment. When configured as a delta, there is only 1928 bytes free in main RAM and only 8 bytes left in the AHB SRAM.

I ended up using lwip2 which actually saved a bit of memory compared to 1.4 and ended up using the newer networking code too. Reduced to 1 network buffer and even that was cut down to 1.5k from 2k.

Quotedc42
I suppose it's too much to hope that there's another chip pin-compatible to the LPC1769 with 128kb RAM, that could be used to upgrade existing boards? 128kb is enough to run the in-development RTOS version of RepRapFirmware.

That's an interesting idea. I'll be keeping an eye out on the RTOS version in the future for my Duet Wifi tho!

Quotedc42
You might be able to fix the M503 issue (and I suspect you may find an issue with M122 as well) by generating part of the response, then returning to allow the web client to take that part and release the buffers, before you generate the next chunk. But this might still cause momentary pauses if you use those commands during a print.

M122 is currently ok. Unless there are other commands that produce long output it seems to be a minor issue if its only M503, especially when there is a much better way to look at (and edit) the config settings through the GUI editor