LPC port of RepRapFirmware

M80/M81 - By using the output of pin 2.12 as is to control the gate on the MOSFET, and these menu button definitions, it works just fine.

; Power Buttons
button R0 C2 T"OFF" A"M81"
button R11 C2 T"ON" A"M80"
;

for ATX you need to pull the PS_ON signal down (ground it out ) for the PSU to come on.

What behavior were you seeing?

Quote
flydeprutten
I made the mod on the LAN8720 module where I connected the RX_ER to NC.

THANK YOU!

My drawing was wrong!



Thanks

sinneD

folks who are using the LAN module- what kind of throughput are you getting uploading gcode files? i seem to be topping out at ~ 80-100Kib/sec

good ? bad? ok?

Quote
sinned
folks who are using the LAN module- what kind of throughput are you getting uploading gcode files? i seem to be topping out at ~ 80-100Kib/sec

good ? bad? ok?

Currently, up to 100K/s is normal.

I recently found ChaN 2018 example code for SD card that used 16bit SPI transfersfor block transfers and makes use of the 8 frame SSP FIFOs on the LPC. So I redid the SDCard library based around the new code. I've also added in a call as part of the init process to enable the HighSpeed interface on SDCards that support it - from what I read, this is enables the use of up to 50MHz SPI speeds to the card instead of the default 25MHz SPI speed interface.

Testing SDCard write speeds with M122 P104 with my 8G card:

Previous write speed: 0.16MB/s (512 byte write buffer)
New code write speed: 0.27MB/s (512 byte write buffer)
New code write speed: 0.68MB/s (with a 4K write buffer)

Network upload speeds (using the new SDCard library but with the same 512byte buffer) now reaches speeds of between 170-220K/s - about twice the speed with no additional memory needed. Using the 4K write buffer (which only fits if LCD is disabled) with the networking resulted in no upload speed increase. Since the card could write at 0.68MB/s with the 4K buffer the networking appears to be the bottleneck now, but there is not enough memory to also increase the required networking buffers as well. So with the limited memory we have, it looks like around 200K/s upload speeds may be the best we can achieve. It only takes a few minutes to upload the 30M gcode file I test networking with, so it's not too bad.


Those updates will be included in the upcoming V3.

Bigtreetech have released the SKR pro which uses a STM32F407ZGT6 clocked at 168MHz. Is there any chance of getting a build which would support this? Might perform better than the LPC based boards.

---

Based in Darlington, North East

Quote
jay_s
Bigtreetech have released the SKR pro which uses a STM32F407ZGT6 clocked at 168MHz. Is there any chance of getting a build which would support this? Might perform better than the LPC based boards.

Not here, this is just for LPC1768/9. It would need a different core etc ported to interface to the new microcontroller.

I am in touch with someone else who has done a port of RepRapFirmware for STM processors.

Edited 1 time(s). Last edit at 06/19/2019 01:51AM 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].

I have finally have success with DWC and networking!

Using the older version, 1.22.5 is much better performing.

https://github.com/chrishamm/DuetWebControl

I am still pretty sure that the full, complex menus and networking are not playing nice with each other, but some more testing is in order.

Edited 1 time(s). Last edit at 06/18/2019 09:14PM by sinned.

The 2.0 series of DuetWebControl places more demands on the network system than older versions. The 2.0RC1 and RC2 builds had particularly high demands.

The latest build in the 1.22 series is 1.22.6. It fixes a bug in 1.22.5.

---

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
I am in touch with someone else who has done a port of RepRapFirmware for STM processors.

That would be nice for the new SKR pro board !

Marlin is so flipping buggy all the time it's awful, it's in desperate need of help from those who can write code without deliberately introducing bugs, even if it's simply to make it safe to use.

Quote
Pippy

Quote
dc42
I am in touch with someone else who has done a port of RepRapFirmware for STM processors.

That would be nice for the new SKR pro board !

Marlin is so flipping buggy all the time it's awful, it's in desperate need of help from those who can write code without deliberately introducing bugs, even if it's simply to make it safe to use.

Oh my god, SKR PRO... it's so beautiful..

---

http://www.marinusdebeer.nl/

I have been getting some great help from a board member here but decided to ask if anyone had a board.txt for a bigtree skr v1.3 board. I've been running Marlin 2 on it in an ENDER 3 with bltouch that's pretty frankenstein'd out. I ran Klipper on it before that but both of these need work. I run a duet3d board on a couple deltas and really like that setup. thx for any help

Quote
4lathe
I have been getting some great help from a board member here but decided to ask if anyone had a board.txt for a bigtree skr v1.3 board. I've been running Marlin 2 on it in an ENDER 3 with bltouch that's pretty frankenstein'd out. I ran Klipper on it before that but both of these need work. I run a duet3d board on a couple deltas and really like that setup. thx for any help

I started adding skr 1.3 config to rrf3 not too long ago. I don't have access to one, and was using this pinout diagram as a reference. Currently, there is no support for setting current etc when using drivers that use SPI or UART. This is what I have come up with so far (it needs checking etc since I can't test it):

stepper.enablePins =               {2.1, 2.8,  0.21, 2.12, 0.10};
stepper.stepPins =                 {2.2, 0.19, 0.22, 2.13, 0.1};    
stepper.directionPins =            {2.6, 0.20, 2.11, 0.11, 0.0};
stepper.hasDriverCurrentControl = false; 

//1.29 X-
//1.28 X+
//1.27 Y-
//1.26 Y+
//1.25 Z-
//1.24 Z+
endstop.pins = {1.29, 1.27, 1.25}; //X, Y, Z Endstops

//                    Bed   E0    E1
heat.tempSensePins = {0.23, 0.24, 0.25}; //tb, th0, th1
heat.heatOnPins =    {2.5, 2.7, 2.4}; //hbed, he0, he1

fan.pins = {2.3}; //cooling fan

lpc.slowPWM.pins = {2.5}; 
lpc.slowPWM.frequencyHz = 10; //10Hz (for Bed PWM)
lpc.fastPWM.pins = {2.7, 2.4};
lpc.fastPWM.frequencyHz = 250; //250Hz (for Hotend/Fan PWM)

lpc.servoPins = {2.0};
specialPinMap = {2.0};

externalSDCard.csPin         = 1.23;
externalSDCard.cardDetectPin = 1.31;
lpc.externalSDCard.spiFrequencyHz  = 4000000;

//LCD Pins (only ST9720 SPI currently supported)
lcd.lcdCSPin =       0.16; //LCD Chip Select
lcd.lcdBeepPin =     1.30;
lcd.encoderPinA =    3.25;
lcd.encoderPinB =    3.26;
lcd.encoderPinSw =   0.28; //click
lcd.lcdDCPin =       NoPin;  //DataControl Pin (A0) if none used set to NoPin
lcd.panelButtonPin = NoPin; 

Quote
sdavi
I started adding skr 1.3 config to rrf3 not too long ago. I don't have access to one, and was using this pinout diagram as a reference. Currently, there is no support for setting current etc when using drivers that use SPI or UART.
[/code]

Does not the duets use SPI TMC drivers ? if so, could it not be added to your LPC port I wonder ?

Quote
Pippy
Does not the duets use SPI TMC drivers ? if so, could it not be added to your LPC port I wonder ?

Never looked into it, but may be possible. I think the SKR1.3 doesn't use HW SPI pins for the drivers, so it would also need a software spi implemented. I don't have a board so unable to try it. Maybe someone here could port it over and test it?

Thx much for your help. I only have endstops and a couple other things working but will try your board.txt file. I have tmc2130 v3 drivers running with software spi on the skr board.
With no spi support I will have to get them into stand alone mode I guess. Will report back.

I haven't tackled the tmc2130's yet. still working on the BLTouch. when I issue m280 p0 s10 I get servo index invalid. same for p1-p9. it wants to treat it as a servo on one of the pwm pins but the white and black wires of the BLTouch are attached to the z Endstop( this worked in marlin 2.0) and the servo wires are connected to the skr servo pins (2.0). again this worked in marlin 2.0.

the m558 to define this is - m558 p9 c2 r0.2 h10 f240 t6000
the m574 is - m574 z1 s2

Quote
4lathe
I haven't tackled the tmc2130's yet. still working on the BLTouch. when I issue m280 p0 s10 I get servo index invalid. same for p1-p9. it wants to treat it as a servo on one of the pwm pins but the white and black wires of the BLTouch are attached to the z Endstop( this worked in marlin 2.0) and the servo wires are connected to the skr servo pins (2.0). again this worked in marlin 2.0.

the m558 to define this is - m558 p9 c2 r0.2 h10 f240 t6000
the m574 is - m574 z1 s2

The SpecialPins start from 60, so you need to use M280 P60 S10, assuming pin 2.0 is the first entry in the specialPinMap array in board.txt.

YES. Probe now deploying and retracting.
M119 still only shows z: not stopped. Z probe: not stopped after m280 p60 s10 and me pressing and holding probe up.

here is config.g

Quote
4lathe
YES. Probe now deploying and retracting.
M119 still only shows z: not stopped. Z probe: not stopped after m280 p60 s10 and me pressing and holding probe up.

I don't know much about the new BLTouch, i've got a old one here i sometimes test to see if it's working in the port. The BLTouch webpage timing diagram shows there is only a very short pulse on zmin when its triggered, so its unlikely to see it in M119. The wiring diagram shows the latest bltouch has a zmin test mode for M119 by using M280 S60, have you tried that?

Tried that. Didnt work. Still showed z not stopped. I took off bltouch wires and put a jumper over the z endstop pins. M119 still shows z not stopped. Weird

Binary now updated to RRF v2.03. Download from Github.

Be sure to read DC42s Whats New.

There have been changes to the SDCard library (listed below), so it would be a good idea to make a backup of the config files etc on the SDCard before updating.

LPC specific changes:

• Networking:
  
  • Upgraded FreeRTOS+TCP to V2.0.11
  • Fixed a bug causing a buffer to not be freed if there was a socket error during the first read.
  • Moved priorities up one so EMAC task is now higher than IPTask.
• SD Card:
  
  • Updated functions for SDCard and SharedSPI to improve performance now using ChaN 2018 routines.
  • Added detection for SDCards that support HighSpeed mode which enables the card interface SPI speeds up to 50MHz. To use faster speeds, change in board.txt, e.g. to use 50MHz spi for internal card set lpc.internalSDCard.spiFrequencyHz = 50000000;. If the card is not detected as a HS card, it will be limited to 25MHz speed. If slower speeds are set in board.txt, they will be used.
  • SDCard read/write retries are now supported.

so after the jumper test on the Zmin Endstops, it makes me wonder if something in board.txt or config.g is making the m119 command read the z Endstops status from some other pins than the z min Endstops pins. otherwise how could jumpereing them not cause m119 to say triggered?
On another note, I need to operate the tmc2130's in standalone right since nothing else is supported at the moment - no spi, no uart?

another issue. m280 p60 s10 works fine.
in sys/deployprobe.g I have 1 command m280 p60 s10. however when I issue m401 I get
Send: M401
Recv: Bad command: {\rtf1\ansi\ansicpg1252\cocoartf1671\cocoasubrtf500
Recv: Bad command: {\fonttbl\f0\fswiss\fcharset0 Helvetica
Recv: Bad command: {\colortbl
Recv: Bad command: \margl1440\margr1440\vieww10800\viewh8400\viewkind0
Recv: Error: G-Code buffer 'serial' length overflow
WARNING! Received an error from the printer's firmware, ignoring that as configured but you might want to investigate what happened here! Error: G-Code buffer 'serial' length overflow
Recv: Bad command: \f0\fs24 \cf0 M280 P60 S10

ok so BLTouch is working but I had to set
M574 z1 s1. instead of m574 z1 s2. I don't understand why though.

the m401 is still the same problem as above though.

Quote
4lathe
another issue. m280 p60 s10 works fine.
in sys/deployprobe.g I have 1 command m280 p60 s10. however when I issue m401 I get
Send: M401
Recv: Bad command: {\rtf1\ansi\ansicpg1252\cocoartf1671\cocoasubrtf500
Recv: Bad command: {\fonttbl\f0\fswiss\fcharset0 Helvetica
Recv: Bad command: {\colortbl
Recv: Bad command: \margl1440\margr1440\vieww10800\viewh8400\viewkind0
Recv: Error: G-Code buffer 'serial' length overflow
WARNING! Received an error from the printer's firmware, ignoring that as configured but you might want to investigate what happened here! Error: G-Code buffer 'serial' length overflow
Recv: Bad command: \f0\fs24 \cf0 M280 P60 S10

Looks like you have saved deployprobe.g as a RTF file format. Make sure to save it as a plain text file.

Sorry. Fixed that. Only thing left is the steppers not responding and 12864 lcd.

Edited 1 time(s). Last edit at 07/01/2019 10:23PM by 4lathe.

jay_s did you ever get the skr 1.3 working?
Sdavi, i used your board.txt above but get mo movement at all from the steppers. Is there something else to di to get tmc2130 working?

I got the SKR board going with a RRD/GLCD. Details here- [imgur.com]
I am using my modified mudcruzr Maestro menus

BIQU remapped the pins going to the EXP1 header. The traces that are connected are not compatible with the port. We can use them for other things, just not SPI connected LCD.

My solution was to solder 3 jumpers to the back of the board and make an interconnect for the LCD cable header. That way I could use the method outlined by dot_bob.

Materials needed-

7 pieces of wire, various colors to make you life easier.
4 female Dupont connector crimps
7 male Dupont connector crimps
2 5 pin Dupont connector shells for the LCD cable end
2 7 pin DuPont connector shells for the board header end. Use of the longer connector shells fills the header cavity to ensure pin justification.
soldering gear