Show all posts by user
Quotesinned
I am hoping to confirm this- if you are using a board with modular stepper drivers, like A4988 or DRV8825's, there is no need for using the M906 command to define motor or idle currents.
M906 X800 Y800 Z800 E800 I30 ; set motor currents (mA) and motor idle factor in per cent
thanks in advance
Yep, current control will only work on those boards with built-in d
by
sdavi
-
Firmware - experimental, borrowed, and future
I've been working on the ESP8266 WIFI initial port for LPC as part of the RRF3 branch. I made a little prototype board to plug it onto the smoothieboard for my CNC.
Connecting the ESP8266 requires SSP0 pins (runs as a slave) and 3 spare GPIO pins on LPC. The EspDataReadyPin needs to be from either port 0 or port 2 as it requires the use of external interrupts.
Upload speeds are about 210K/s
by
sdavi
-
Firmware - experimental, borrowed, and future
Changes from RRF v2.04 have been merged into the LPC port. Updated binary can be downloaded here:
This is likely the final update for the RepRapFirmware Version 2 series.
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotesinned
2. I will look into M570 a little bit more. Is there any logging in RRF for the messages?
The most un-nerving thins is that the fault reporting is on the PanelDue, NOT on the gcode console. So unless I am actually at the printer, I dont see the message. And PanelDue messages seem to scroll into oblivion.
Do you have a photo or written down what the error that's reported on the P
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteMKSA
For bed heating in bang bang mode (I don't see the need for PID here) I suppose you don't use PWM ?
From memory, bang-bang mode just sets pwm to 0% or 100% if the pin was HW-PWM capable or assigned to a hardware timer to generate the pwm, otherwise it would fall back to digitalWrite.
I don't have access to an oscilloscope and am no expert in interrupts on the ARM so I'm just specula
by
sdavi
-
Firmware - experimental, borrowed, and future
Quotesinned
I am pretty sure its getting noise from somewhere or there is the tiniest of connection issues. i dont have an oscilloscope to check Agnd, Aref, Vref.
every once and a while after i get 2-3 layers into a print, the controller will spit out a heater fault but I dont have any more info to figure it out with. the fault message usually only appears on the paneldue consol, not DWC.
tha
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteDocSolo
Hi sdavi,
Thanks for the quick reply. I'll look into it even if I'm not comfortable with coding. I'm always up for learning new stuff.
DocSolo
Some thoughts after quickly flicking through that driver source code on github:
For the external interrupt, you'll need to find a spare pin that needs to be on either Port 0 or Port 2 on the LPC. RRF already uses external ints in a few pla
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteDocSolo
Hi all,
I got my hands on a ENC28J60 LAN ethernet module. I have a BTT SKR v1.3 and got the RRF working when connected to USB. Is there any way to Connect this module to the SKR now that software SPI is implemented. I don't use a LCD screen.
Thanks in advance for any info.
DocSolo
The current build only supports the built-in Ethernet on the LPC.
If your comfortable doing a bit
by
sdavi
-
Firmware - experimental, borrowed, and future
Also check the stepper pulse timings you have set in the firmware. According to the CL57T requires: Min Pulse Width of 2.5us and Min Dir Setup of 5.0us.
by
sdavi
-
Controllers
RRF3 is still in beta, so for the LPC port, mostly aimed at those who want to be on the bleeding edge or help out testing other boards. I think most of the work on the official RRF3 so far has gone into supporting the new duet3 so not much in the way of new features that would be available on the LPC except the new configuration options. If the current version is working, and working well, then
by
sdavi
-
Firmware - experimental, borrowed, and future
I've just uploaded an experimental RepRapFirmware Version 3 beta for LPC . There have been a lot of changes, so those brave enough to try it should do so with caution.
Those upgrading from RRF2 will need up update their config files (see changes required for RRF3).
I have also been modifying the RepRapFirmware Configurator for use with the LPC port and RRF3 (only a few boards have been added
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteDunston-UK
Thank you dc42 and sdavi that has solved the homing of the Y.
Its now the Homeall that playing up, it moves the printhead all the way to the from of the printer off the print bed area, whereas when the Y was set to Y1 it stayed at the back because the area limits were clearly wrong, now that putting the HomeZ and Homeall out.
Assuming you want to home x and y, then move to the c
by
sdavi
-
Duet
QuoteDunston-UK
Hi
I have got my CoreXY to move in the right directions when looking from the front of the printer X+ moves the gantry to the right, and Y+ moves the gantry to the rear of the printer, BUT, when I home Y it does not do it correctly, (see code) HomeX appears to work fine (see code), and HomeAll looks like it work ok again see code.
What have I done wrong? Can someone please corre
by
sdavi
-
Duet
Quotesinned
sdavi-
Are you versioning the updates? I swear up updated the fw to the latest one. It reports as -
Firmware Version: 2.04RC1 (2019-07-14b1)
Thanks
sinneD
I don't modify the version numbers, I just use the RRF version. Generally I'll keep any changes I make until the next RRF version change, however that last binary fixed a bug that caused a reset if the network goes down so
by
sdavi
-
Firmware - experimental, borrowed, and future
Uploaded new binary (just networking fixes). Fixes a bug which caused a hard fault if the ethernet cable is unplugged after the network is up and running. Also fixes a bug when running M586.
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteMicktol
Sdavi,
I have been looking on the duet3d site and it states "Additional Motor Support: Headers for two external stepper drivers with step/direction/enable interface and optional configuration via single wire UART (TMC2208 or TMC2224). "
Does this mean that the code is available?
Yeah RRF has code for TMC22xx.cpp, TMC51xx.cpp and TMC2660.cpp.
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteMicktol
I have a SKR 1.3 with the latest firmware and the software spi, the screen and external sd card work without any extra wiring.
Thank you for testing this with the SKR1.3, good to hear this is now working.
QuoteMicktol
@sdavi, is it possible and planned to support the control of the stepper drivers via spi or uart?
The new softwareSPI code is a step towards this, as the stepper S
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteDark Alchemist
TMC2208 and we shouldn't need to be so barbaric with jumper wires if we have a pins definition file. Since Marlin 2.0 worked with the LCD then it should be as simple as swamping 3 pins over and the pins that need to be swapped are 0_18 with 1_18, 0_15 with 1_20 and 0_16 with 1_19.
Not quite as simple as just swapping the pins. The issue was, most other boards had the LCD and
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteDark Alchemist
Sigh.
Will this be made for Platform.io so we can use Atom to compile it?
Most people don't need to compile the firmware as the configuration is stored on the SDCard. Just copy the firmware.bin and config files to the SDCard, and reboot.
Currently, the LPC port does not support drivers that are configured by SPI or UART for current control, etc. I've just uploaded an examp
by
sdavi
-
Firmware - experimental, borrowed, and future
Now updated to RRF v2.04 RC1, binary available here
LPC Changes:
Networking - Added timeout for connected sockets that don't send/receive data for a period of time. SDCard - Allow SPI channel selection for the External SDCard. Experimental: Initial Software SPI to work with SharedSPI has been implemented - only mode 0 and no settable frequency yet. Works OK with the RepRapDiscount Full Graphic
by
sdavi
-
Firmware - experimental, borrowed, and future
QuoteMicktol
Would it be possible for somebody to compile this for me with paneldue enabled on the serial port. I would compile it myself but it is a bit beyond me.
Thank you in advance.
I had actually made this a configurable option in board.txt for RRF3 a while ago, so i just copied those changes back to the V2 branch and just uploaded an updated binary here. (Only quickly tested with a FTDI
by
sdavi
-
Firmware - experimental, borrowed, and future
QuotePB
I have LPC1769 and M122 shows me it is still at 100MHz. Where in sources (or in config) I can specify frequency of 120MHz which is available for my chip?
I think the SBase boards have a LPC1768. Have you checked what's printed on top of the chip on your board?
The speed is configured in system_LPC17xx.c, which reads the "Part ID" from the chip to determine if it's a 1768 or 1769, and s
by
sdavi
-
Firmware - experimental, borrowed, and future
QuotePB
Thanks! I tried to make from current source (of course I enabled it in Pins_LPC.h beforehand) and got some syntax errors I consider they are because of older version compiler.
1. ../RepRapFirmware/src//Libraries/Fatfs/port/lpc/diskio.cpp:64:51: error: no matching function for call to 'SDCard::disk_read(BYTE*&, DWORD&, BYTE&)'
while(_ffs->disk_read(buff, sector, count
by
sdavi
-
Firmware - experimental, borrowed, and future
QuotePB
I try to use nonlinear extrusion feature but firmware says "M592 not supported".
RepRapFirmware for LPC176x based Boards 2.03+2
Duet Web Control 2.0.0-RC5
According to changelog I think it is already implemented. What can be done to enable it?
Yeah I just checked the code and it's still disabled in Pins_LPC.h, so it's not currently compiled in. I'll enable it for next version.
by
sdavi
-
Firmware - experimental, borrowed, and future
QuotePB
3. On temperature plot I notice short but high spikes at all thermistors. Probably only one reading wrong. Not causing problems.
4. Only one question where it is better to place start and stop g-codes universal for each prints like M104 S0
M140 S0
G0 X0 Y0 Z220
M84
at the end. Now I insert it with slicer, but probably it is nice to do it in firmware. Should I place it in stop.g? Will ru
by
sdavi
-
Firmware - experimental, borrowed, and future
QuotePB
Quotedc42
Have you tried sending M665 and M666 without parameters after running G32, to see if they have changed? Then you can run M500 to save the new values to config-override.g.
Yes I run M665 and M666 without parameters before and after G32 and all values reported are completely same. I even tried to put 1mm thick sheet on half of bed to make it feel differently inclined for probe a
by
sdavi
-
Firmware - experimental, borrowed, and future