Welcome! Log In Create A New Profile

Advanced

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
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?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 05, 2020 04:33PM
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
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 05, 2020 04:59PM
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
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 06, 2020 06:24AM
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
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 08, 2020 09:12AM
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
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?


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 08, 2020 12:40PM
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
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
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 08, 2020 02:23PM
Looks like my WiFi issue was a bug.
See the update log for RRF3.01 RC1
Quote

The M587 command didn't set up the access point password correctly, resulting in "Wrong password" reports when trying to connect to the access point


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 09, 2020 01:44PM
G28
Error: SetPositions called when DDA ring not empty
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 09, 2020 03:29PM
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], 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
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.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 04:11AM
@sdavi

Could we look at coming up with a standardised way of naming the pins on each of the different boards?


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 04:59AM
@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
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
@sdavi @gloomyandy

Point taken. Just thought it might be easier to always use the same names across the board rather than the mishmash of naming used across the silkscreens.


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 05:42AM
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!
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 05:43AM
Want me to come up with something as a suggestion?


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 05:50AM
And I'm only talking about core names used. Can't do anything about pin only names


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 06:29AM
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
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 07:00AM
Quote
jay_s
@sdavi Could you give me a link the correct mBed board?

It is not a printer board. It's the dev board i use for programming and debugging.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 07:02AM
Quote
sdavi
Quote
jay_s
@sdavi Could you give me a link the correct mBed board?

It is not a printer board. It's the dev board i use for programming and debugging.

That makes sense then. I'll ignore the mBed


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 10:02AM
Thanks. The problem really was in the incorrectly configured endstops. How to turn on stealthchop for 2208/09 in RepRap?
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 10:07AM
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
The pin names for the SKR 1.4 can be found here as a stop gap until the configurator is updated

Stealthchop is configured on a standard duet by using M569.
I don't know whether this is configurable currently as I've not tested it. Mayby @gloomyandy can chip in?


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 01:50PM
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.
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 04:32PM
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], 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
@dc42 It was me


Based in Darlington, North East
Re: RepRapFirmware 3.0 port for LPC1768/9 based boards
February 10, 2020 09:54PM
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
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.

Click here to login