LPC port of RepRapFirmware

Hi,

As I suspected the idle mode to be responsible for the big discrepancy, I set it to 100%. For a 1A set via M906 the Vref I measure is 0.548V. The Rsense is 0.1 so from the 8825 doc, the current is 0.548/0.5 = 1.096A, close enough.
mcp4451 are used too.

Indeed, not much doc about these boards, none up to date. There was a MKS guy posting here in the past but not anymore.

Smoothieware new releases are claimed to be unable to run on these MKS SBASE.
You may save MKS SBASE days

---

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

Any reason the MAX end stop pins have been chosen for the limit switches instead of the MIN which seems to be the most common and logical (coord 0) set up.
When moving from Smoothieware, I had to reconnect them, not a major issue but an hindrance when you go from one firmware to an other, but I am asking because I can see the MAX being usually free can and are used for other kind of input like run out sensor ...

To switch from one firmware to an other can help isolate mechanical, hardware issues.

---

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

Quote
MKSA
Any reason the MAX end stop pins have been chosen for the limit switches instead of the MIN which seems to be the most common and logical (coord 0) set up.
When moving from Smoothieware, I had to reconnect them, not a major issue but an hindrance when you go from one firmware to an other, but I am asking because I can see the MAX being usually free can and are used for other kind of input like run out sensor ...

To switch from one firmware to an other can help isolate mechanical, hardware issues.

No reason, it was just a matter of picking something. Delta users have endstops on Max and z-probe on Min, which i had at the time so that probably played a part. Leaving z-probe on min seemed like a good idea and to be consistent the rest stayed on max.

You could switch the pin numbers over in the smoothie config file to keep them the same, or edit the header file in this version and compile the firmware.

Quote
sdavi

Quote
MKSA
Any reason the MAX end stop pins have been chosen for the limit switches instead of the MIN which seems to be the most common and logical (coord 0) set up.
When moving from Smoothieware, I had to reconnect them, not a major issue but an hindrance when you go from one firmware to an other, but I am asking because I can see the MAX being usually free can and are used for other kind of input like run out sensor ...

To switch from one firmware to an other can help isolate mechanical, hardware issues.

No reason, it was just a matter of picking something. Delta users have endstops on Max and z-probe on Min, which i had at the time so that probably played a part. Leaving z-probe on min seemed like a good idea and to be consistent the rest stayed on max.

You could switch the pin numbers over in the smoothie config file to keep them the same, or edit the header file in this version and compile the firmware.

Yes but MAX in Delta is a coord MAX, not coord 0 . I like to be consistent.
True MIN, MAX is irrelevant, fact, one input per axis is enough as one knows if it is going toward 0, max or even probing (my Z probe is the limit too).

I prefer to avoid recompiling. Startup set up files, commands, macros is the way. Marlin should do that too.

---

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

I wonder how many people are using RRF on MKS SBASE ?

---

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

Merged in updates from RepRapFirmware release v2.02 and new binaries uploaded.

Read DC42's WHATS_NEW to see changes in RepRapFirmware 2.02.

LPC Changes:
* Implemented firmware update command for Networking users. After installing this update, users can hopefully upload future firmware files (do not rename when downloading) using DWC by uploading via the upload button in the settings page which will place it in /sys/. Then running the GCode command M997 will then move the file to /firmware.bin and then it will automatically reboot the board (which should then flash the firmware in the usual way). This should save having to remove the sdcard to do firmware updates in the future.
* Increased the max open files to 4 (from 3) and also added an extra output buffer now 15 (from 14).

First of all - Thx for the great port ... really good job

after I have a lot of trouble with smoothieware I will now try RepRap.

takes some time to become the webgui. I use RepRap (MKS Network) v2.02 latest and I try DuetWebControl 1.22 - will not work lost connect. DuetWebControl v1.21 also lost connect.
I use now DuetWebControl v1.20 !!! that works for me. (use Safari on Mac)

The first trap was MIN MAX endstops. As MKSA said - for people they come from other firmware
It's posible to change that - would be great help.

JoVo

after a few day playing around with latest "firmware-MKSSBASE-NETWORK.bin" on a MKS SBASE board I must say - for me - will not work stable with a webgui
Often lost connecting (CORS request failed) and it's not possible to reconnect!
Total different when it lost the connecting. I can force it by say "M999" then you have to wait or try several times to reconnect.
Looks like if run into trouble when it will read from SD card. It's not when you write to SD card. Save/edit config/macros and upload files running whiteout problem.
I try different "WebControl" version 1.20 up to 2.00 nothing works stable. Also tried different SD card's.
Does anyone have a reliably stable MKS or SMOOTHIE network version running?

Duet Web Control 2.0 is still in an early beta phase, also the versions up to RC2 load 3 or 4 files concurrently which is probably too much for the LPC port. I suggest you use version 1.22.5 instead.

What version MKS board do you have? I read that the early versions used a ceramic resonator for the Ethernet timing instead of a crystal, and it wasn't stable enough.

---

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 use the MKS SBASE v1.3. As i can remember was that issue for the v1.2.
From Duet WebControl v2.00 I tried the mini version - There is no big difference with "lost connection" problems to WebControll 1.22.5 - look and feel same behave .
So it could be that the board itself is the problem.

Apparently a few people also had issues with the supply to the phy chip on the sbase too.

I run 1.22.5 on Smoothieboard and find it stable with the LPC port - I've had it running for several hours without any problems.

I've been testing DWC v2 with LPC port and so far the main issue i've experienced is it "disconnects" when uploading large files since it also seems to be requesting status updates in parallel during the upload, but the LPC port only services one connection at a time, so DWC thinks there is a error when it doesn't get any replies from the status updates in time and then reconnects. This is not an issue in 1.22.5 where it stops the status updates during uploads so 1.22.5 should currently be the most stable with the LPC port.

From my testing, known causes to getting disconnects in 1.22.5 on the LPC port are:

1. Running gcodes that produce a large amount of text, such as M503.
2. Downloading/editing large files (i.e. over a 1MB or so), although it will usually reconnect automatically afterwards.

Quote
sdavi
Apparently a few people also had issues with the supply to the phy chip on the sbase too.

I run 1.22.5 on Smoothieboard and find it stable with the LPC port - I've had it running for several hours without any problems.

I've been testing DWC v2 with LPC port and so far the main issue i've experienced is it "disconnects" when uploading large files since it also seems to be requesting status updates in parallel during the upload, but the LPC port only services one connection at a time, so DWC thinks there is a error when it doesn't get any replies from the status updates in time and then reconnects. This is not an issue in 1.22.5 where it stops the status updates during uploads so 1.22.5 should currently be the most stable with the LPC port.

From my testing, known causes to getting disconnects in 1.22.5 on the LPC port are:

1. Running gcodes that produce a large amount of text, such as M503.
2. Downloading/editing large files (i.e. over a 1MB or so), although it will usually reconnect automatically afterwards.

On the schematic there is a fuse on the 3.3V line supplying the PHY chip !

Note that personally I don't care about the web interface, it is a 3D printer !
A nice feature to have (hey HP, Cisco have done that decades ago) but it is a matter of priorities. Not just regarding development but while running too !

---

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

Quote
MKSA
Note that personally I don't care about the web interface, it is a 3D printer !
A nice feature to have (hey HP, Cisco have done that decades ago) but it is a matter of priorities. Not just regarding development but while running too !

The web interface not only provides better control over your printer than you can get via USB, it provides a fast and convenient way to move files from your PC to your printer, manage the files on the SD card, and display the bed height map after mesh probing.

---

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

Quote
dc42

Quote
MKSA
Note that personally I don't care about the web interface, it is a 3D printer !
A nice feature to have (hey HP, Cisco have done that decades ago) but it is a matter of priorities. Not just regarding development but while running too !

The web interface not only provides better control over your printer than you can get via USB, it provides a fast and convenient way to move files from your PC to your printer, manage the files on the SD card, and display the bed height map after mesh probing.

I know that but I am more concerned about this MKS SBASE running properly the ported firmware related to the 3D printer functionalities and their future improvements.

---

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

After you experience network issues, it might be worth sending the M122 command from USB and checking the "Never used RAM" value in the report, to see whether the system has run out of RAM. The LPC processors have only half the RAM of the current Duets, so I'm amazed that @sdavi was able to include so much functionality in the LPC port.

---

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

That are the values after a "cold start".

=== RTOS ===
Static ram: 1740
Dynamic ram: 30348 of which 0 recycled
Exception stack ram used: 256
Never used ram: 392
AHB_RAM Static ram used : 10784
=== Ram Totals ===
Main SRAM : 32344/32768 (424 free, 392 never used)
RTOS Dynamic Heap : 33712/52304 (18592 free, 18592 never used)

could be interesting after few hours playing around....

Quote
JoVo
That are the values after a "cold start".

=== RTOS ===
Static ram: 1740
Dynamic ram: 30348 of which 0 recycled
Exception stack ram used: 256
Never used ram: 392
AHB_RAM Static ram used : 10784
=== Ram Totals ===
Main SRAM : 32344/32768 (424 free, 392 never used)
RTOS Dynamic Heap : 33712/52304 (18592 free, 18592 never used)

could be interesting after few hours playing around....

Did you change the firmware since testing the networking? As that appears to be the non-networking version of the firmware based on that output - the AHB static memory should be around 17K when running the networking version.

ups - you're right is the USB version.
but can't use both USB + Network - will not work.
Not sure if that is my fault or limit in software.
will try to bring up network ....

so now with network + usb (works today )

=== RTOS ===
Static ram: 2792
Dynamic ram: 29340 of which 0 recycled
Exception stack ram used: 296
Never used ram: 308
AHB_RAM Static ram used : 17504
=== Ram Totals ===
Main SRAM : 32428/32768 (340 free, 308 never used)
RTOS Dynamic Heap : 38352/44536 (6184 free, 5016 never used)
=== LPC PWM ===

Btw. with your software I have to swap Hotend and Bed thermistor for korrekt function on my MKS SBASE v1.3
only thermistor!

orig. Smoothieware on MKS SBASE
-------------------------------------------------
temperature_control.bed.thermistor_pin 0.23
temperature_control.hotend.thermistor_pin 0.24

your software
-----------------
; Bed Heater (H0)
M305 P0 T100000 B3950 R4700 ; Set thermistor + ADC parameters for heater 0 "BED"
M143 H0 S120 ; Set temperature limit for heater 0 to 120C

; Hot End Heater (H1)
M305 P1 T100000 B3950 R4700 ; Set thermistor + ADC parameters for heater 1 "HOTEND"
M143 H1 S280 ; Set temperature limit for heater 1 to 280C

Quote
JoVo
so now with network + usb (works today )

=== RTOS ===
Static ram: 2792
Dynamic ram: 29340 of which 0 recycled
Exception stack ram used: 296
Never used ram: 308
AHB_RAM Static ram used : 17504
=== Ram Totals ===
Main SRAM : 32428/32768 (340 free, 308 never used)
RTOS Dynamic Heap : 38352/44536 (6184 free, 5016 never used)
=== LPC PWM ===

Sounds like there is some intermittent problem going on. There should be a blinking LED when everything is working. When you can't connect over USB when using the Network version, check that the LED is still blinking.

Is this the similar problem you were having with smoothieware as well?

There is an issue on the LPC CPU, where if the PHY chip is not present (or not working?) the manual mentions the CPU can become locked and no further functionality is possible. I have a Azteeg X5 mini (which has no networking), and if i try to enable networking it freezes the CPU, to the point where not even the watchdog will reset it!

For testing, you could edit the config.g to disable the networking by changing M552 S1 to M552 S0 . You should be able to connect with USB and then can enable the networking by running M552 S1. If it immediately freezes and LED stops blinking then you may actually be having an issue with cpu communicating with the phy chip.

Quote
JoVo
Btw. with your software I have to swap Hotend and Bed thermistor for korrekt function on my MKS SBASE v1.3
only thermistor!

orig. Smoothieware on MKS SBASE
-------------------------------------------------
temperature_control.bed.thermistor_pin 0.23
temperature_control.hotend.thermistor_pin 0.24

I'll fix that in the header file and upload a new binary soon. The initial config was based on the smoothieboard one (which is why i mentioned before checking the header file to check the config was correct since i can't test it).

Quote
sdavi
....

I'll fix that in the header file and upload a new binary soon. The initial config was based on the smoothieboard one (which is why i mentioned before checking the header file to check the config was correct since i can't test it).

Could you rearrange the limit switches as discussed above at the same time ?
Just a convenience for people wanting to use RRF on the SBASE as most have a hard time figuring and sorting this out on their own.
Makes swapping firmware easier too, for comparison.

---

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

No my problem on Smoothie is (stop printing without any saying why) but not all the time! can print 1Kg without any issue or as last week nothing after 6 !hour try to came over layer 20 ;-)

Network is running all the time - only webgui lost connection (XMLHttpRequest cannot load [192.168.10.40] due to access control checks.)
LED is blinking as expected (there are two LED one stay one is blinking).

thx for fix the thermistor connection .... make switch firmware simple (configured smoothie Endstop pin's from MIN to MAX) so I can try without change any cable.

only Z-offset make me problem (problem between the ears in my opinion) but all other imported function are running fine (heating, PID, G28, G29) when Z is correct I'll try to print ...

Updated MKSSBase config based on this config.txt and binaries uploaded.

The config is now (please check these are now correct):
Bed: Therm - 0.23 and HeaterPin - 2.5
Hotend1: Therm - 0.24 and HeaterPin - 2.7
Hotend2: Therm - 0.25 and HeaterPin - 2.6

good job - great,

I use firmware-MKSSBASE-NETWORK.bin

Network - work (http for the moment also! will check more later)
USB - work
thermistor connector pinout - OK work as original

With the endstops, it might be possible (have to look at the source code for endstops etc) to select the hw min/max using M574 as it configures the X,Y, Z endstop as no endstop, low end, high end. It is the probe which is the only issue.

I assume most people use the unused Z endstop for the probe? So can we assume it will normally be on a Z-min or Z-max connector?

So we can either modify GCode M558 and add a param to specify if the probe is on Zmin/ZMax (although i'm not too keen on changing gcodes). Another option could be using the following:
* if M574 sets Z0 (no endstop) then probe is connected to z-min
* if M574 sets Z1 (low end) then probe is connected to z-max
* if M574 sets Z2 (high end) then probe is connected to z-min
If we went for such a system would probably have to add to M122 what pin the probe is on to make it easier to people to troubleshoot.

Any thoughts?

first I'm new to reprap ....

I try M558 P7 but I've also M574 Z1 activated (that could be my prob)

Quote
JoVo
first I'm new to reprap ....

I try M558 P7 but I've also M574 Z1 activated (that could be my prob)

Yeah, currently the Z-Min (on the board) is configured to be what RepRapFirmware considers the "Probe" pin so probably P5 should work. I think in your current config it is expecting the probe to be on the "RRF Z endstop" (which is currently Z-max in the current port).

The current duets have X,Y,Z and Probe headers but many of the LPC boards have Xmin, Xmax, Ymin, Ymax, Zmin and Zmax and no probe header which makes it bit of an issue currently. The azteeg x5 mini on the other hand only has x,y,z and probe which maps just like rrf expects...... Once we've got a configurable option in place and some documentation should make things easier in the future.

M558 is something that needs some extra documentation for the lpc port too as some options also don't apply such as using E0 and E1 pins etc etc.

In RRF 2.03 I'll be adding a new M-code to assign endstops. Endstop inputs are already numbered from 0 to some maximum in other commands such as M591. The mapping is currently fixed at X=0, Y=1 etc. and that will become the default mapping in firmware 2.03. The new M-code will also provide for using multiple endstops on a single axis, which will avoid the need to create additional temporary axes when homing with multiple endstops.

The M558 P4 option that used to select the E0 endstop input on Duets already (in firmware 2.02) accepts a C parameter to specify the endstop input number, default 3. So you can now connect the Z probe to any endstop input. The P5 and P6 options that refer to Z and E1 endstop inputs are deprecated in favour of P4 with C3 or C5.

Edited 2 time(s). Last edit at 01/05/2019 02:40AM by dc42.

---

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

As I wrote earlier, no need for MIN and MAX endstops, just assign the SBASE MIN endstops as the DUET endstops and the SBASE MAX to probes, sensors whatever, (yet, to be consistent, the Z MAX as the Z probe if different from the Z endstop).

Sorry to insist but looking at the calls for help, many people get confused by end stops, motor direction ... even with a correct documentation ! Now if you tell them, that here the MAX is in fact the MIN, they will end up with a nervous breakdown

---

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