LPC port of RepRapFirmware

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

Ahhh that new C parameter for M558 makes configuring the probe a lot easier then . That sounds good having a new M-code for endstops and multiple endstops per axis.

Small update for Networking users.

• Updated network driver to accept broadcast ethernet frames to allow the board to reply to ARP requests. Although FreeRTOS+TCP defaults to frequently sending gratuitous ARP, some OSes do not accept them by default resulting in their ARP tables not being updated.
• Tweaked the network related buffers, freed some memory by not creating the ftpresponders which were never used and added a 2nd http socket+responder to work with the upcoming DWC v2.0 to upload and download files without getting disconnections. I still run both DWC 1.22.5 and 2.0 with 10 ajax retries in the settings otherwise it occasionally looses connection briefly when refreshing the files in the GCodes section.

There is also still 3K of memory free on a 5 driver board configured as a cartesian so there hasn't been too much lost while adding the 2nd http socket.

That sounds good. I will test today. You say up to 10 ajax retries. I'll try. Yesterday I provided the test printer with limit switch(s) and wanted to try to make it work.
The first print attempts I made were not great - layer shift - but that's probably my mistake.
Thx for your great work

Quote
JoVo
That sounds good. I will test today. You say up to 10 ajax retries. I'll try. Yesterday I provided the test printer with limit switch(s) and wanted to try to make it work.
The first print attempts I made were not great - layer shift - but that's probably my mistake.
Thx for your great work

Did you add the pulse timings to M569 for the DRV8825s in config.g?

No - only "M569 P0 S0" so I 've to read and find out what I have to add for the driver. Short look said "T" parameter. thx

I use "T" with the parameter you described earlier in the thread - and printed a cube (most printed part in the universe) without "layer shift" ;-)
Quality is not bad for the first complete print.

webgui has been working stable for more than 6 hours, rarely losing contact, it's good to work with. I use the "DuetWebControl" 1.22.5 + 1 and firmware-MKSSBASE-NETWORK-6.jan.bin

fight with "trigger height" and "z-probe". This morning "z-probe" still worked ... but - too much configured ;-)

New binaries with experimental support for boards with Min/Max endstops.

**Upgrading to this version you need to check endstop configuration and connections**

This should now allow M574 to select the position of the endstop, and it now also updates the RRF endstops array to allow it to select the hardware pin corresponding to Min or Max. This also now requires the probe to be selected with P4 and the C param (new in 2.02) to select the endstop header the probe is connected to. When using P4 if you run M558 again it will report it as P5 mode as this workaround updates the RRF Probe pin definition and converts it to "P5" mode otherwise it would conflict with the Endstop workaround......Hopefully this will be easier to implement when the RRF has that new endstop M-code in the future.

Boards with only X,Y,Z and Probe headers there is no change.

I've put a readme in the edgerelease directory that explains the changes.

Quote
sdavi
New binaries with experimental support for boards with Min/Max endstops.

**Upgrading to this version you need to check endstop configuration and connections**

This should now allow M574 to select the position of the endstop, and it now also updates the RRF endstops array to allow it to select the hardware pin corresponding to Min or Max. This also now requires the probe to be selected with P4 and the C param (new in 2.02) to select the endstop header the probe is connected to. When using P4 if you run M558 again it will report it as P5 mode as this workaround updates the RRF Probe pin definition and converts it to "P5" mode otherwise it would conflict with the Endstop workaround......Hopefully this will be easier to implement when the RRF has that new endstop M-code in the future.

Boards with only X,Y,Z and Probe headers there is no change.

I've put a readme in the edgerelease directory that explains the changes.

OK, for the MKS SBASE, it works .

Note I just gave a try to Repetier-host and the com is still screwing up when in debug mode and after a movement command.
Not a real issue for me but could be an annoyance for others.

---

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

For MKSSBASE-NETWORK it works also ...
two little issue: Webgui is not so stable as before - lost connecting twice and "LogicalPin" the number changed 62 to 60 so my fan would not work

Quote
JoVo
For MKSSBASE-NETWORK it works also ...
two little issue: Webgui is not so stable as before - lost connecting twice and "LogicalPin" the number changed 62 to 60 so my fan would not work

Ah yes thanks for pointing that out, I forgot to mention that the Logical Pin numbers might have changed for some boards as the previously unused endstop pins are no longer listed as spare pins.

There was no changes to the networking with the last update.

could it be that web control something cached? Now lot of hour later webgui is stable (I configured dual-z today - works also )
Last issue for me is Temperature (Chart) this is not a straight line - it has a lot of spikes up to 10 C ° most of them up to 5 °.
For some test prints, the system was stopped due to incorrect temperature. PID was done.

Quote
JoVo
could it be that web control something cached? Now lot of hour later webgui is stable (I configured dual-z today - works also )
Last issue for me is Temperature (Chart) this is not a straight line - it has a lot of spikes up to 10 C ° most of them up to 5 °.
For some test prints, the system was stopped due to incorrect temperature. PID was done.

Check the values of M305 and make sure they are correct for your thermistors, check wiring etc etc. Are they stable when not printing etc ?

Quote
sdavi

Quote
JoVo
could it be that web control something cached? Now lot of hour later webgui is stable (I configured dual-z today - works also )
Last issue for me is Temperature (Chart) this is not a straight line - it has a lot of spikes up to 10 C ° most of them up to 5 °.
For some test prints, the system was stopped due to incorrect temperature. PID was done.

Check the values of M305 and make sure they are correct for your thermistors, check wiring etc etc. Are they stable when not printing etc ?

after a "M84" they are stable!
If I switch to smoothieware they are stable. I checked that in "Octoprint -> Terminal " and "Pronterface"
So I'm not sure if the board has a problem.
Any idea?

Quote
JoVo
after a "M84" they are stable!

That sounds like motor current is affecting the thermistor reading. Possible causes include:

1. Both wires from the thermistor should go directly from the thermistor to the thermistor connector on the controller. The thermistor should not share a common ground wire with anything else.

2. If the controller PCB layout wasn't doesn properly with separate analog and digital grounds, then it could be a "feature" of whatever controller board you are using. The Smoothieware build for that board might have extra temperature smoothing in it to hide the issue.

---

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
JoVo
after a "M84" they are stable!

That sounds like motor current is affecting the thermistor reading. Possible causes include:

1. Both wires from the thermistor should go directly from the thermistor to the thermistor connector on the controller. The thermistor should not share a common ground wire with anything else.

2. If the controller PCB layout wasn't doesn properly with separate analog and digital grounds, then it could be a "feature" of whatever controller board you are using. The Smoothieware build for that board might have extra temperature smoothing in it to hide the issue.

It's a MKS SBASE v1.3
They wires goes directly. I've only a schema von v1.2 and it look's like they have own ground, but I'm not an engineer.
Perhaps is there another person that play with a MKS board and have or have not this issue.

Quote
dc42

Quote
JoVo
after a "M84" they are stable!

That sounds like motor current is affecting the thermistor reading. Possible causes include:

1. Both wires from the thermistor should go directly from the thermistor to the thermistor connector on the controller. The thermistor should not share a common ground wire with anything else.

2. If the controller PCB layout wasn't doesn properly with separate analog and digital grounds, then it could be a "feature" of whatever controller board you are using. The Smoothieware build for that board might have extra temperature smoothing in it to hide the issue.

2) I don't have any temp variation issue, idling or while printing. Hot end is PID, bed ON OFF
The schematic mentions Analog and Digital ground (the ground plane by looking at the board itself). The TH 0V are labelled DGND, the stepper drivers 0V are on the AGND, (analog ground). No Signal ground though
Therefore MKS knows about them. In addition the board looks well made. So one can safely assume it is OK.
Fact is, considering its low cost, it is quite a neat board. Too bad they cut corners by not putting a LPC1769 processor and better stepper drivers than the 8825.

Edited 1 time(s). Last edit at 01/10/2019 02:19PM by MKSA.

---

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

Quote
MKSA
The schematic mentions Analog and Digital ground (the ground plane by looking at the board itself). The TH 0V are labelled DGND, the stepper drivers 0V are on the AGND, (analog ground). No Signal ground though
Therefore MKS knows about them. In addition the board looks well made. So one can safely assume it is OK.

If they really are wired that way round, it's the wrong way round. Thermistors should be connected to analog ground, stepper motors to power ground, which may be a common ground plane with digital ground.

I wouldn't trust MKS to get it right. They didn't design the board, they copied the Smoothieboard design and made some changes that broke it, such as replacing a crystal by a ceramic resonator, which wasn't stable enough for the Ethernet interface. They corrected that error in a subsequent revision, but who knows what other bad decisions they made?

---

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
MKSA

Quote
dc42

Quote
JoVo
after a "M84" they are stable!

That sounds like motor current is affecting the thermistor reading. Possible causes include:

1. Both wires from the thermistor should go directly from the thermistor to the thermistor connector on the controller. The thermistor should not share a common ground wire with anything else.

2. If the controller PCB layout wasn't doesn properly with separate analog and digital grounds, then it could be a "feature" of whatever controller board you are using. The Smoothieware build for that board might have extra temperature smoothing in it to hide the issue.

2) I don't have any temp variation issue, idling or while printing. Hot end is PID, bed ON OFF
The schematic mentions Analog and Digital ground (the ground plane by looking at the board itself). The TH 0V are labelled DGND, the stepper drivers 0V are on the AGND, (analog ground). No Signal ground though
Therefore MKS knows about them. In addition the board looks well made. So one can safely assume it is OK.
Fact is, considering its low cost, it is quite a neat board. Too bad they cut corners by not putting a LPC1769 processor and better stepper drivers than the 8825.

thx for explantion that is what I'm think too.

Uh - that sounds bad to me. Now it look like that my board or hopefully wiring is "damaged or bad" Can it be that the usage from "P0.26 aka TH4" impact has. I use it to switch Fan1 (Hotend) on/off. Would be great when it change to 1.23, It is a Pin with PWM or to 1.22 for extension as Fan or something like that.

Quote
dc42

Quote
MKSA
The schematic mentions Analog and Digital ground (the ground plane by looking at the board itself). The TH 0V are labelled DGND, the stepper drivers 0V are on the AGND, (analog ground). No Signal ground though
Therefore MKS knows about them. In addition the board looks well made. So one can safely assume it is OK.

If they really are wired that way round, it's the wrong way round. Thermistors should be connected to analog ground, stepper motors to power ground, which may be a common ground plane with digital ground.

I wouldn't trust MKS to get it right. They didn't design the board, they copied the Smoothieboard design and made some changes that broke it, such as replacing a crystal by a ceramic resonator, which wasn't stable enough for the Ethernet interface. They corrected that error in a subsequent revision, but who knows what other bad decisions they made?

Fact is steppers drivers, power FET 0V are on AGND and the TH 0V the DGND. The TH are connected to the ADC IN of the processor that is also on DGND. So at least in the schematic, it is correct.
Now, how it is in reality on the PCB, hard to say. Black coated, multilayered.
BUT, as I wrote, I don't experience the issues mentioned by JoVo.

I understand Smoothie designers, yourself being pissed off by these copiers. I know the feeling. Been there too.

I bought it to try as it is dirt cheap and was surprised to get something better than dirt.

Because of that I also never asked Smoothie people for support and I never promoted MKS boards but can't blame them here.

As you do support users, you know that most issues are with them.

Lucky these machines are not dealing with high power, high voltages .... because it would be the "killing fields"

---

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

I just purchased a couple of Duet 2 WiFi's from Matter Hackers and while I was attempting at getting one running on a coreXY I stumbled upon this port. I have a couple of machines that run on Marlin 2.0 with a MKS sbase, RE-ARM, and AZSM mini. I plan to try this port on most of them.

I am starting on a Tevo Little Monster delta which is mostly stock but comes with a MKS sbase standard. Playing with it last night I have the web interface up and running and the steppers moving. I am fairly new to ReprapFirmware so I am learning as I go but everything so far seems pretty straight forward. I also have the code building with visual studio code using the windows-arm-none-eabi extension.

The plan right now is seeing if I can get the reprap discount full graphics display and a BLTouch working. Has anyone tried getting a BLTouch working with this firmware yet?

Quote
dot_bob
I just purchased a couple of Duet 2 WiFi's from Matter Hackers and while I was attempting at getting one running on a coreXY I stumbled upon this port. I have a couple of machines that run on Marlin 2.0 with a MKS sbase, RE-ARM, and AZSM mini. I plan to try this port on most of them.

I am starting on a Tevo Little Monster delta which is mostly stock but comes with a MKS sbase standard. Playing with it last night I have the web interface up and running and the steppers moving. I am fairly new to ReprapFirmware so I am learning as I go but everything so far seems pretty straight forward. I also have the code building with visual studio code using the windows-arm-none-eabi extension.

The plan right now is seeing if I can get the reprap discount full graphics display and a BLTouch working. Has anyone tried getting a BLTouch working with this firmware yet?

A few people have reported success using bltouch with the LPC port. The ReArm is already configured for use with servos on its first 3 servo pins, but for other boards, you need to find a spare pin, edit the header file and add that pin to the SpecialPinMap array (if its not already there) and also add it to the Timer2_PWMPins array (which will use the timer to generate a 50Hz pwm) and recompile. Then you can check M122 to see the logical pin it has been mapped to and then follow the RRF documentation. I did test with my old bltouch not too long ago and it was working deploying/retracting the pin etc.

The RepRapDiscount Full graphic i have working on a azteeg X5 mini but I haven't tested the sd card on it though. By default, the LCD support is not compiled in with the networking - in the past there was not enough memory to have both together but there was recently some extra memory freed up so it might be possible to have both together. Edit pins_LPC.h if you want to compile the lcd in along with the networking.

A bit of a long preamble, but I get to the question near the end.

I am keen to give this a try having just ripped the MKS-SBASE (v1.3) and the useless smoothiware out of my Anycubic Delta Plus. I have put the Trigorilla Board (TB ) back in with Marlin 1.1.9 but am missing the touch TFT-LCD. I would like to go back to the MKS-SBASE board for the touch LCD, so this sounds promising.

But, I cannot tear out the TB and put the MKS back in to play with stuff as I need the printer working. Is it possible to set this up on the bench, as in, plug the bare MKS into the PC and do some testing? I can plug in a thermistor and switch-probe etc.

Is there any instructions for installing this on a delta? I noticed a mention of using the MKS-base config above and that appears very similar to the smoothiware config, so I am a little confused as to what I need and how to do it. I found some stuff on YT, but it seems to be all for the wifi board connections.

Thanks

Quote
StlLooking
A bit of a long preamble, but I get to the question near the end.

I am keen to give this a try having just ripped the MKS-SBASE (v1.3) and the useless smoothiware out of my Anycubic Delta Plus. I have put the Trigorilla Board (TB ) back in with Marlin 1.1.9 but am missing the touch TFT-LCD. I would like to go back to the MKS-SBASE board for the touch LCD, so this sounds promising.

But, I cannot tear out the TB and put the MKS back in to play with stuff as I need the printer working. Is it possible to set this up on the bench, as in, plug the bare MKS into the PC and do some testing? I can plug in a thermistor and switch-probe etc.

Is there any instructions for installing this on a delta? I noticed a mention of using the MKS-base config above and that appears very similar to the smoothiware config, so I am a little confused as to what I need and how to do it. I found some stuff on YT, but it seems to be all for the wifi board connections.

Thanks

Sure you can, just use the USB and Pronterface, make it simple to test ! It is what I did.
The TFT32 works now.

There are links in this thread about how to install RRF. Similar to Smoothie, no compile/upload just copy.
Configuration is all done via Gcode mainly in config.sys. Gcode are well documented but one has to pay attention to the differences with the Marlin Gcodes. Got to "translate" you Smoothie, Marlin config.
Plenty of reading/learning though.

---

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

Quote
MKSA
There are links in this thread about how to install RRF. Similar to Smoothie, no compile/upload just copy.
Configuration is all done via Gcode mainly in config.sys. Gcode are well documented but one has to pay attention to the differences with the Marlin Gcodes. Got to "translate" you Smoothie, Marlin config.
Plenty of reading/learning though.

Thanks, but I could not find any links, I looked through all posts on all 7-pages. I failed to mention I use Mint so no Pronterface.

But, I tried installing the firmware-MKS.bin as firmware.bin and used the config that was working from the smoothieware before pulling it. Got the back-light on the LCD12864 and no text, one LED blinking and one solid on the MKS.

I then plugged the TFT32 in (same setup from smoothie installation) and it is not seeing the thermostor plugged into any of the 3-thermistor sockets.

Could you or someone else, please point me at (or attach here) all the files I need on the SD to at least see something on the LCD and /or the TFT. They do not need to be setup for a delta as I just have the board on the desk and I would like to get it working before worrying about the actual setup.

Thanks

I though I would post a quick update on my progress with this LPC port. I have the majority of the hardware for the TEVO little monster running with the exception of the discount full graphics display or the stock TFT32. Delta compensation is working along with networking.

When I first started with networking it was barely usable on internet explorer and chrome and firefox would just crash. It may just be the MKS hardware causing many of the issues. I dug around in the networking code a bit last night trying to improve performance. I was having an issue with the css and java script downloads crashing causing the UI to become corrupted. I reduced buffer sizes and re-enabled TCP windowing and added a couple http sockets and performance has jumped up 10x. It's still not perfect but it allows use of chrome, firefox and DWC 2.0.

I also started work on using the firmware on my SCARA printer that is running an AZSMZ Mini. I have rough movement working. I need to square things up mechanically before I can do much more.

I'll submit a pull request of the pin files when everything has been fully tested.

All is here:
[reprap.org]
[github.com]

Read all this thread too.

It is a 3D printer, not a Web server, so start with the basic. The web interface can come latter.

---

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

@StlLooking, you can use the configurator at [configurator.reprapfirmware.org] to help generate the configuration and homing files. If you pretend that the board is a Duet 0.8.5 then it should offer you most of the correct options.

---

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
StlLooking

Quote
MKSA

I then plugged the TFT32 in (same setup from smoothie installation) and it is not seeing the thermostor plugged into any of the 3-thermistor sockets.

Could you or someone else, please point me at (or attach here) all the files I need on the SD to at least see something on the LCD and /or the TFT. They do not need to be setup for a delta as I just have the board on the desk and I would like to get it working before worrying about the actual setup.

Thanks

Connect the TFT32 and run the command "M575 P1 B115200 S0" This will put the aux port to 115200 baud and turn off checksum. With this command my TFT2.8 is working.

For the TFT32 the command

M575 P1 B115200 S0

Should be put in the config.g file as posted here previously.

---

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

Well after playing with the firmware the last couple of nights I have it running on a couple of printers and added support for the BIQU SKR board. I have submitted a couple of pull request with these changes.

I have been playing with the MKS SBASE trying to get networking and the discount reprap full graphics display running reliably. The hardware was designed pretty poorly as the display can't run very fast without artifacts. The same display runs fine on the AZSMZ Mini and BIQU SKR.

I have been playing with memory settings trying to make the network more reliable. it is working fairly well with NumHttpResponders = 1 and NumHttpSockets = 1 but goes to lunch after 5-10 minutes. It still responds to pings but the web server is MIA. The changes to the memory and network settings are in my default branch: [github.com]

Here is the M122 response right after the failure:

>>>m122
SENDING:M122
=== Diagnostics ===
RepRapFirmware for LPC176[8/9] based Boards version 2.02(RTOS) running on MKS SBase at 100Mhz
Used output buffers: 1 of 12 (9 max)
=== RTOS ===
Static ram: 2828
Dynamic ram: 29304 of which 0 recycled
Exception stack ram used: 304
Never used ram: 300
AHB_RAM Static ram used : 15592
=== Ram Totals ===
Main SRAM : 32436/32768 (332 free, 300 never used)
RTOS Dynamic Heap : 39608/46408 (6800 free, 6216 never used)
=== LPC PWM ===
Hardware PWM: 100 Hz
PWMTimer1: 10 Hz
PWMTimer2: 50 Hz
PWMTimer3: 250 Hz
=== GPIO Special Pins available === (i.e. with M42)
LogicalPin - PhysicalPin
60 - P0_26
61 - P1_23 [Timer 2]
Tasks: EMAC(blocked,236) NETWORK(ready,804) IP-task(blocked,312) HEAT(blocked,936) MAIN(running,2320) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:16:25 ago, cause: [power up]
Flash Slot[66]:
Last software reset at 2019-02-01 23:43, reason: User, spinning module GCodes, available RAM 396 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000001 Task 0x00000000
Stack: 00000000 00000000 0003acd9 2007e120 2007ca58 2007e120 0003b071 2007e120 00000000 00000000 00000000 00000001 10001f3c 00000000 00000000 00000000 0003acd9 10001f3c 2007ca58 10001f3c 0004cd9a 2007dac8 0002fa9b
Error status: 0
[ERROR] Error status: 0

Free file entries: 4
SD card 0 detected
SD card longest block write time: 0.0ms, max retries 0
Date/time: 2019-02-03 23:26:19
Slowest loop: 1.22ms; fastest: 0.06ms
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm: 100, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: none
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
file is idle in state(s) 0
serial is ready with "M122" in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 24.55ms; fastest: 0.02ms
Responder states: HTTP(0)
HTTP sessions: 0 of 1
Interface state: active