RepRapFirmware 3.0 port for LPC1768/9 based boards
Posted by sdavi
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 05, 2020 04:26PM |
Registered: 4 years ago Posts: 213 |
On my SKR V1.3 board the following works fine for me...
M574 X1 P"!xmin"
S1 is the default type so pretty much the same as you have. My endstops are active low (so triggering the endstop pulls the pin to ground, hence the "!"), and obviously the names for the pins are different between the V1.3 and V1.4 boards. Are your endstops active high or low?
M574 X1 P"!xmin"
S1 is the default type so pretty much the same as you have. My endstops are active low (so triggering the endstop pulls the pin to ground, hence the "!"), and obviously the names for the pins are different between the V1.3 and V1.4 boards. Are your endstops active high or low?
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 05, 2020 04:33PM |
Registered: 13 years ago Posts: 224 |
My switches are set to NC so are active High.
Only difference that makes for testing is that the endstop would show always triggered when not and vice versa when it is triggered.
I can't get the status to change either way.
I've also tried commenting out lpc.board to make the firmware think it was a generic board but that doesn't seem to make a difference.
Based in Darlington, North East
Only difference that makes for testing is that the endstop would show always triggered when not and vice versa when it is triggered.
I can't get the status to change either way.
I've also tried commenting out lpc.board to make the firmware think it was a generic board but that doesn't seem to make a difference.
Based in Darlington, North East
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 05, 2020 04:59PM |
Registered: 13 years ago Posts: 224 |
Problem solved. It was the diag pin used for sensorless homing on the drivers that was causing the problem.
I had to bend them so they aren't connected when installed. There's unfortunately no other was of overriding sensorless homing on the SKR 1.4 using TMC2209s
Based in Darlington, North East
I had to bend them so they aren't connected when installed. There's unfortunately no other was of overriding sensorless homing on the SKR 1.4 using TMC2209s
Based in Darlington, North East
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 06, 2020 06:24AM |
Registered: 13 years ago Posts: 224 |
I've written a blog post about how to get this all compiled and how to connect an ESP to an SKR 1,4.
Any comments on improvements etc are welcomed
https://www.jayuk.org/compiling-and-running-reprapfirmware-on-an-skr-1-4-and-other-lp17xx-boards/?preview=true
Based in Darlington, North East
Any comments on improvements etc are welcomed
https://www.jayuk.org/compiling-and-running-reprapfirmware-on-an-skr-1-4-and-other-lp17xx-boards/?preview=true
Based in Darlington, North East
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 08, 2020 09:12AM |
Registered: 4 years ago Posts: 4 |
Quote
jay_s
I've written a blog post about how to get this all compiled and how to connect an ESP to an SKR 1,4.
Any comments on improvements etc are welcomed
https://www.jayuk.org/compiling-and-running-reprapfirmware-on-an-skr-1-4-and-other-lp17xx-boards/?preview=true
Did everything according to your instructions but knocks out an error
G:\3d printer\soft\rrf\CoreLPC4RRF-lpc-tmc22xx-dma>make
- Firmware Filename: firmware.bin
- Linker Script used: ./CoreLPC2/variants/LPC/linker_scripts/gcc/LPC17xx_smoothie_combined.ld
- Building ESP8266 WIFI Support
- Building LPC TMC22XX support
"[arm-none-eabi-gcc: Compiling CoreLPC2/cores/arduino/hooks.c]"
Error in command syntax.
make: *** [build/./CoreLPC2/cores/arduino/hooks.o] Error 1
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 08, 2020 09:18AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 08, 2020 12:40PM |
Registered: 4 years ago Posts: 4 |
Quote
jay_s
It looks like it's not finding your install of make.exe
Did you add it to your windows path environment as per this?
Make sure you add it as a system variable rather than a user variable.
Did you also restart VSCode?
Thanks everything was compiled but still some error came out
[arm-none-eabi-g++: Compiling RepRapFirmware/src/Movement/StepperDrivers/TMC2660.cpp]
[arm-none-eabi-g++: Compiling RepRapFirmware/src/Movement/StepperDrivers/TMC51xx.cpp]
[arm-none-eabi-g++: Compiling RepRapFirmware/src/LPC/Movement/StepperDrivers/TMCSoftUART.cpp]
\nCreating firmware.bin
text data bss dec hex filename
402432 1436 19013 422881 673e1 ./build/firmware.elf
sh: G:\3d: No such file or directory
make: [build/firmware.elf] error127 (ignored)
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 08, 2020 01:28PM |
Registered: 13 years ago Posts: 224 |
That looks fine.
You should find the firmware.bin file in the build folder where ever you put all the files.
Just pop that file on the root of your SD card and you should be cooking on gas.
I did my first print using an SKR v1.4 with TMC2209s running RRF3 this morning and it's the best looking print I've ever achieved on the printer I'm using
Based in Darlington, North East
You should find the firmware.bin file in the build folder where ever you put all the files.
Just pop that file on the root of your SD card and you should be cooking on gas.
I did my first print using an SKR v1.4 with TMC2209s running RRF3 this morning and it's the best looking print I've ever achieved on the printer I'm using
Based in Darlington, North East
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 08, 2020 02:23PM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 09, 2020 01:44PM |
Registered: 4 years ago Posts: 7 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 09, 2020 03:29PM |
Registered: 10 years ago Posts: 14,685 |
Quote
SilentStorm
G28
Error: SetPositions called when DDA ring not empty
Which firmware version? That used to happen sometimes in RRF 3.0 for Duets (usually when the endstop switch was already triggered at the start of a homing move), but I am fairly sure it is fixed in the later 3.01 beta and 3.01RC1 versions.
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].
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 09, 2020 09:58PM |
Registered: 11 years ago Posts: 341 |
Binary for 3.01RC1 is now available: [github.com]
I have also updated the LPC config tool (I didn't spend much time on it so it might be a bit buggy, only has a few boards and it's now a bit behind the official version). This version will generate a board.txt. If the board has plug-in drivers, then there will be an extra option to select the driver or add custom driving timings and those timings are also added to config.g. Boards with built-in drivers will not see that option, but will have the timings for their board added to config.g. Make sure to carefully check all the generated config files if using the config tool. Source for the configtool is here: [github.com]
Edited 1 time(s). Last edit at 02/09/2020 10:07PM by sdavi.
I have also updated the LPC config tool (I didn't spend much time on it so it might be a bit buggy, only has a few boards and it's now a bit behind the official version). This version will generate a board.txt. If the board has plug-in drivers, then there will be an extra option to select the driver or add custom driving timings and those timings are also added to config.g. Boards with built-in drivers will not see that option, but will have the timings for their board added to config.g. Make sure to carefully check all the generated config files if using the config tool. Source for the configtool is here: [github.com]
Edited 1 time(s). Last edit at 02/09/2020 10:07PM by sdavi.
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 04:11AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 04:59AM |
Registered: 4 years ago Posts: 213 |
@jay_s I think at the moment they use whatever name the manufacturer has used for the board silkscreen, which sort of makes sense from a user point of view. I'm not really sure what a good alternative would be? Use the same names as one of the Duets perhaps, so that config files match most of the examples out there? Having the different names does mean that things like the config tool are going to be more complex I guess.
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 05:02AM |
Registered: 11 years ago Posts: 341 |
Quote
jay_s
@sdavi
Could we look at coming up with a standardised way of naming the pins on each of the different boards?
I think it's easier for most people to use what is written on the board silk-screen in the GCode (makes debugging a lot easier that way). The only exception is boards like the ReArm etc that uses i.e. X+/X- for endstops which wasn't compatible with the way naming is handled in RRF3, so they got renamed Xmin/Xmax etc. Also, some boards have both min/max endstops and some have just x-stop, y-stop, z-stop and probe. I think it would get too confusing if some parts of the board is the same as the silkscreen and others are not.
The old format of port.position (i.e. 1.23) is still usable in RRF3+ if people prefer to use that instead of the silk labels.
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 05:08AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 05:42AM |
Registered: 4 years ago Posts: 213 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 05:43AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 05:50AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 06:29AM |
Registered: 13 years ago Posts: 224 |
Please find a proposed pin naming convention here
Have a look and see what you think.
The only one I'm stuck on is the name for the 4th thermistor on the MKS Sbase and the smoothie board.
Could I also suggest that every pin that's named has its pin number as well? What should the convention be as both "1.27" and "P1.27" is used across the boards files. Which would people prefer?
@sdavi Could you give me a link the correct mBed board?
Edited 1 time(s). Last edit at 02/10/2020 06:30AM by jay_s.
Based in Darlington, North East
Have a look and see what you think.
The only one I'm stuck on is the name for the 4th thermistor on the MKS Sbase and the smoothie board.
Could I also suggest that every pin that's named has its pin number as well? What should the convention be as both "1.27" and "P1.27" is used across the boards files. Which would people prefer?
@sdavi Could you give me a link the correct mBed board?
Edited 1 time(s). Last edit at 02/10/2020 06:30AM by jay_s.
Based in Darlington, North East
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 07:00AM |
Registered: 11 years ago Posts: 341 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 07:02AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 10:02AM |
Registered: 4 years ago Posts: 7 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 10:07AM |
Registered: 4 years ago Posts: 7 |
Quote
sdavi
Binary for 3.01RC1 is now available: [github.com]
I have also updated the LPC config tool (I didn't spend much time on it so it might be a bit buggy, only has a few boards and it's now a bit behind the official version). This version will generate a board.txt.
Please add SKR 1.4 to the configurator. Pin names do not match SKR 1.3
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 10:14AM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 01:50PM |
Registered: 4 years ago Posts: 213 |
Configuring stealthchop and spreadcycle typically needs UART support for the device, the current standard build of RRF for the LPC does not support that. Some drivers allow you to run them in standalone mode (in which case they typically run in stealthchop by default), but many come configured to use the UART interface by default. It depends on which driver board you have really.
I have just updated my build (that does have support for TMC22XX devices in UART mode) and if you would like to try it you can grab the binary here:
[github.com]
Note that this is built for WiFi not ethernet.
I have just updated my build (that does have support for TMC22XX devices in UART mode) and if you would like to try it you can grab the binary here:
[github.com]
Note that this is built for WiFi not ethernet.
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 04:32PM |
Registered: 10 years ago Posts: 14,685 |
Someone recently enquired when I was likely to add TMC2209 stall detection support to the TMC22xx driver in RRF, although I haven't found the original post. I've now added stall detection and configuration to the version of that driver in the Duet3Expansion project. It may be a little while before I port it over to the driver in RepRapFirmware (from which it was derived) because there isn't yet a Duet main board with TMC2209 drivers; but if someone else wants to port the changes across, it shouldn't be hard to do. The main difference between the two drivers is that the one in Duet3Expansion uses a separate FreeRTOS task to do the UART communication.
Edited 1 time(s). Last edit at 02/10/2020 04:32PM 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].
Edited 1 time(s). Last edit at 02/10/2020 04:32PM 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].
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 05:06PM |
Registered: 13 years ago Posts: 224 |
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 09:54PM |
Registered: 11 years ago Posts: 341 |
Quote
gloomyandy
As someone that has both SKR V1.3 and SKR V1.4 boards, I agree it can be a bit of a pain, but I'm not sure I could come up with a good alternative!
I realise that many people have multiple LPC boards and would like to have a common config.g that they might update and just copy to all boards, so how about using the new conditional gcodes?
I've just added the board name that is set in the board.txt to the object model instead of the generic LPC string. This would then allow you to have a line early in config.g to run a macro that uses that board name as a filename that has board specific settings in it, i.e.:
M98 P{"/sys/"^boards[0].name^".g"}
|
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards February 10, 2020 10:15PM |
Registered: 11 years ago Posts: 341 |
Quote
jay_s
Could I also suggest that every pin that's named has its pin number as well? What should the convention be as both "1.27" and "P1.27" is used across the boards files. Which would people prefer?
This is already supported using the first convention and has been since LPC RRF3.0. It will first search through the PinTable names, if its not in there then as a backup will search using the pin format (but only for pins that exist in the PinTable). The naming convention with the P in front can easily be added, but that's better done in BoardConfig:: StringToPin instead of using up more flash space adding by all those extra entries to the PinTable.
Edited 1 time(s). Last edit at 02/10/2020 10:16PM by sdavi.
Sorry, only registered users may post in this forum.