LPC port of RepRapFirmware

An experimental port of RepRapFirmware v1.21RC2 for LPC1768 boards. Sources: RepRapFirmware for LPC and CoreLPC.

Attached below are firmware binaries for:

• Azteeg X5 Mini (Tested normal cartesian only on AzteegX5Mini V1.1)
• Smoothieboard (Tested on Smoothieboard 4XC on my CNC, 2 drivers for Y-axis - only movement tests X,Y,Z)
• ReArm (UNTESTED don't have one) - Best guess, configured based on provided smoothie config files

Uploading firmware is same procedure as Smoothieware, i.e. copy appropriate firmware file as firmware.bin to the SDCARD and reset.

Notes:

• Very Experimental at this stage - Use at own risk - Do not leave unattended etc etc etc.
• The "Play" LED (on ReArm? and Azteeg X5 Mini) or LED1 (on Smoothieboard) should blink every 500ms which is controlled via the Systick interrupt.
• RRF doesn't mount the SD card as a MSD like smoothie does. You may need physical access to the SDCard, if things go wrong and can't upload a new firmware.bin to the SDCard, or, want to revert back to smoothieware.
• Currently the following features are disabled: SPI thermocouple; ethernet; and, Reset/fault Diagnostics.
• RRF only supports 3 endstops + probe, so on boards with both max and min endstops, the MAX endstop headers are used by default for XYZ endstops (as either max or min), and Z-Min being used for zprobe. The X Min and Y Min pins are free for other purposes.
• Currently no mapping of spare pins to Special pins controllable with Gcode for Smoothieboard and ReArm.
• Zmin (currently configured for z-probe) is not ADC capable. If need Analog In for probe then update header files to switch to a spare ADC pin.
• I've tried to pack RAMs AHB0 and AHB1 leaving around 8k main RAM free which hopefully will be enough for auto-calibrations etc?????

Unfortunately, I don't have a spare printer for testing, but I did have it temporarily connected on my printer and was able to home, heat hotend+bed, probe bed with piezo probe and print a hollow cube test print. I don't have a delta, corexy etc so haven't been able to test those.

I've got a CR-10 running a RE-ARM + Ramps 1.4 SB Premium. and willing to be a guinea pig if you'd like. I'm running marlin 2.0 right now and it's good but also been interested in RRF and their webgui if this supports the re-arm ethernet module. Besides just flashing, I assume I do the RRF online config to create the .g files?

Edited 2 time(s). Last edit at 03/09/2018 05:55PM by cyris69.

Guinea pigs very welcome, especially a ReArm one since I don't have access to one to test. Make sure to check the enstops first, as mentioned in the first post. These can be changed in source code but does need to be re-compiled tho.

I haven't looked into the ethernet part yet. It will depend on how much RAM is required etc. I really hope there is enough as the RRF web gui is very good.

Yeah, you can use the online config tool and upload to the SD Card. Fortunately they do not overlap with the smoothieware config so they can all co-exist together on the SDCard nicely. I've attached the config for my azteegx5 for reference (which is actually the same config as what i use on my Duet Wifi with some of the settings for setting the microstepping etc removed although I dont think they will cause any issue if they are left in there) - running a standard cartesian with E3Dv6.

Let me know how it goes.

Quote
sdavi
I haven't looked into the ethernet part yet. It will depend on how much RAM is required etc. I really hope there is enough as the RRF web gui is very good.

I'd love to see the Ethernet interface working on the LPC port; but I think RAM usage may be a problem. AFAIK the LPC processor on the current Smoothieboard and clones (including Re-ARM) has only 64Kb RAM. Even the legacy Duets had 96kb RAM and RRF for them used most of it. The current Duets have 128kb RAM.

You could reduce the RAM usage somewhat, for example by reducing the maximum number of stepper motors supported (maybe you already have) and therefore the number of DriveMovement objects allocated. Also you could save on RAM needed for the Ethernet interface by only allowing one HTTP connection at a time. Finally there are some buffers used to read and write info to/from the SD card, and these could all be reduced to 512 bytes, at the expense of file upload speed.

HTH David

PS - there are 2 separate networking subsystems in the RRF source tree for handling built-in Ethernet ports: the one for the legacy Duets which is based on LWIP 1.4 and in subfolder Duet, and the one for the SAME70 which is in subfolder Networking. The one for the legacy Duets almost certainly uses less RAM than the other one..

Edited 1 time(s). Last edit at 03/10/2018 04:46AM 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].

Quote
dc42
I'd love to see the Ethernet interface working on the LPC port; but I think RAM usage may be a problem. AFAIK the LPC processor on the current Smoothieboard and clones (including Re-ARM) has only 64Kb RAM. Even the legacy Duets had 96kb RAM and RRF for them used most of it. The current Duets have 128kb RAM.

You could reduce the RAM usage somewhat, for example by reducing the maximum number of stepper motors supported (maybe you already have) and therefore the number of DriveMovement objects allocated. Also you could save on RAM needed for the Ethernet interface by only allowing one HTTP connection at a time. Finally there are some buffers used to read and write info to/from the SD card, and these could all be reduced to 512 bytes, at the expense of file upload speed.

HTH David

PS - there are 2 separate networking subsystems in the RRF source tree for handling built-in Ethernet ports: the one for the legacy Duets which is based on LWIP 1.4 and in subfolder Duet, and the one for the SAME70 which is in subfolder Networking. The one for the legacy Duets almost certainly uses less RAM than the other one..

Thanks for the pointers David, that will certainly save some time looking for places to squeeze some extra RAM if needed.

Yes, we only have 64k total - 32k of main RAM and another 2 16k blocks of RAM. That makes it a bit trickier juggling around the objects into the different banks. The 2 16k blocks are contiguous address wise, however the manual does mention they are each on separate slave ports on the AHB so I'm not sure if its possible to use it as a single 32k block (would make it a bit easier) but i'm unsure what would happen if an object spanned across the 2 so i've left separate for now (this is way outside of my knowledge ).

Currently, we have 8236 bytes of "never used" main RAM, 1192 free in AHB0 and 8364 free AHB1. There was a comment in configuration.h that delta calib needs 3584 extra stack for 32points, which leaves us with around 14208 bytes (minus any extra stack we need).

I did find a version of lwip 1.4 lpc port just today so i'll definitely check out the legacy duet part and hopefully this drops in just nicely.

You might not be able to do a DMA transfer that spans the junction between the two 16-bit blocks, also an unaligned 16- or 32-bit access that spans the blocks might not work (but unaligned accesses are rare in the code). So I think you should be able to treat it as a single 32k block. You can reduce the maximum number of calibration points to 16 because few people use more than that.

The code in the Lwip folder is processor-independent, but you can tweak lwipopts.h to reduce memory usage. The Ethernet code that is specific to the ATSAM3X8E is in the EMAC folder.

HTH David

PS - please keep me informed of progress! I am likely to be giving a talk on RepRapFirmware next month and one of the topics I will be covering is which electronics it runs on.

Edited 3 time(s). Last edit at 03/10/2018 09:43AM 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].

Ok, I tried RRF configurator but no serial access. I'll give yours a go and see how she chooches as I run a e3d as well.
Sucks to think it might not get RRF's web interface and functionality such as live editing which to me is a huge perk. I will be going duet ethernet on my rostock max v3 once I can afford it new by the end of the year I hope or find a sale/used one once duet2 comes out.
Marlin 2.0 has been great so far, smoothie was a horrible experience with how it's coded especially no z probe endstop but configuring was easy and nice. It also sucks that RRF is pretty limited to specific boards only, I mean I can understand that making money is needed to provide a more premium firmware so to speak.

Also, I assume I just modify you configs to suit my bed and offsets as usual. When using the config tool I set it to rrf type not like marlin so maybe thats why I got no serial support.

Edited 1 time(s). Last edit at 03/10/2018 09:29PM by cyris69.

I reran it as marlin and connected fine but running M119 but getting

Send: M119
Recv: Endstops - X: not stopped, Y: not stopped, Z: not stopped, Z probe: not stopped

Seems my stops are on the axis min just need to move them to max, then in the configuration tool set their end stop locations to 'at high end' and leave z to "at low end". Still faster than I got smoothie to even do anything lol

EDIT:
I don't know the trigger height of the capacitive probe just the offset, is this important at all and do I need to measure it?

Edited 1 time(s). Last edit at 03/10/2018 09:53PM by cyris69.

Using some of your values in config.g I was able to get xy endstops to trigger but not z probe unless I need to have a z endstop as well.

Edited 1 time(s). Last edit at 03/11/2018 12:39AM by cyris69.

Quote
cyris69
I reran it as marlin and connected fine but running M119 but getting

Send: M119
Recv: Endstops - X: not stopped, Y: not stopped, Z: not stopped, Z probe: not stopped

Seems my stops are on the axis min just need to move them to max, then in the configuration tool set their end stop locations to 'at high end' and leave z to "at low end". Still faster than I got smoothie to even do anything lol

EDIT:
I don't know the trigger height of the capacitive probe just the offset, is this important at all and do I need to measure it?

Yeah, the marlin compatibility seem best suited for most of the host programs. But yet another good reason to try and get the ethernet web GUI up and running

With the endstops, it gets a bit confusing on the Smoothieboard and Re-Arm as they have both min and max endstops for each axis. Whereas the Duet (Reprapfirmware) and the AzteegX5 only have 1 endstop per axis - which causes a bit of a naming convention issue on the boards that have both.

At the moment, I have set it so that the Z-Probe connects to Z-Min header on the board, and the 3 axis endstops are connected to X-Max, Y-Max, Z-Max headers (regardless if they are at physically at Min or Max on the printer). So in the configuration just choose where they are physically on the printer (for most people on cartesian printers they are home to min) and choose if they are active high or not. In my config, I only have X and Y configured as normal NC microswitch (which is homed to min) and a piezo Z-Probe.

There is some documentation here. I'm not all that familiar with the RRF configuration, but the documentation is very good and there are lots of examples out there.

Quote
cyris69
Endstops aren't working no matter how configured as well as the pins must not be right for the axises. Is this something I could compile?

Hmm this is whats in the config now: X Max - P1_25, Y Max, P1_27, and Z-Max P1_28 which i got from the PDF on the Panucatt website. I'll see if i can find the smoothie config for the rearm and check that too.

Can you run M122 for me and make sure it says ReArm as the board type just under the ===Platform=== heading, just to make sure i actually put the right firmware file there?

And can you confirm what endstops your using i.e. normal microswitches etc? And attach the config.g your currently using?

Thanks for being patient with this.

I was able to get xy to trigger they are your run of the mill reprap endstops. Your re-arm pins are correct I went through your code.
Can't get probe though, here is all the output. Also in the rrf tool I picked the unmodulated or smart ir probe since it was default and not sure which for capacitive NPN NO probe. Also seems motors aren't activating using the values taken from your config. Sorry, I'm not a big software configurer so a lot of this is still new to me. Been printing for over 5 years but never really did much besides use pre-built firms.

Recv: ; Configuration file for Duet Ethernet (firmware version 1.20 or newer)
Recv: ; executed by the firmware on start-up
Recv: ;
Recv: ; generated by RepRapFirmware Configuration Tool on Sun Mar 11 2018 00:13:13 GMT-0500 (Eastern Standard Time)
Recv: 
Recv: ; General preferences
Recv: G90                                       ; Send absolute coordinates...
Recv: M83                                       ; ...but relative extruder moves
Recv: ; Network
Recv: M550 PMy printer                          ; Set machine name
Recv: M540 PBE:EFE:AD:FE:ED                   ; Set MAC address
Recv: M552 P0.0.0.0 S1                          ; Enable network and acquire dynamic address via DHCP
Recv: M586 P0 S1                                ; Enable HTTP
Recv: M586 P1 S0                                ; Disable FTP
Recv: M586 P2 S0                                ; Disable Telnet
Recv: 
Recv: ; Drives
Recv: M569 P0 S0                                ; Drive 0 goes forwards
Recv: M569 P1 S1                                ; Drive 1 goes forwards
Recv: M569 P2 S1                                ; Drive 2 goes forwards
Recv: M569 P3 S0                                ; Drive 3 goes forwards
Recv: M350 X32 Y32 Z32 E16 I0                   ; Configure microstepping without interpolation
Recv: M92 X160 Y160 Z800 E95                    ; Set steps per mm
Recv: M566 X900 Y900 Z12 E120                   ; Set maximum instantaneous speed changes (mm/min)
Recv: M203 X6000 Y6000 Z180 E1200               ; Set maximum speeds (mm/min)
Recv: M201 X500 Y20 Z250 E250                   ; Set accelerations (mm/s^2)
Recv: M906 X800 Y800 Z800 E800 I30              ; Set motor currents (mA) and motor idle factor in per cent
Recv: M84 S30                                   ; Set idle timeout
Recv: 
Recv: ; Axis Limits
Recv: M208 X0 Y0 Z0 S1                          ; Set axis minima
Recv: M208 X300 Y300 Z400 S0                    ; Set axis maxima
Recv: 
Recv: ; Endstops
Recv: M574 X1 Y1 S1                             ; Set active low endstops
Recv: M574 Z0 S0                                ; Set endstops controlled by probe
Recv: M558 P1 H5 F120 T6000                     ; Set Z probe type to unmodulated and the dive height + speeds
Recv: G31 P600 X-41 Y0 Z-3.45                   ; Set Z probe trigger value, offset and trigger height
Recv: M557 X15:285 Y15:285 S20                  ; Define mesh grid
Recv: 
Recv: ; Heaters
Recv: M301 H0 S1.00 P10 I0.1 D200 T0.4 W180 B30 ; Use PID on bed heater (may require further tuning)
Recv: M305 P0 T100000 B4138 C0 R4700            ; Set thermistor + ADC parameters for heater 0
Recv: M143 H0 S120                              ; Set temperature limit for heater 0 to 120C
Recv: M305 P1 T100000 B4138 C0 R4700            ; Set thermistor + ADC parameters for heater 1
Recv: M143 H1 S280                              ; Set temperature limit for heater 1 to 280C
Recv: 
Recv: ; Fans
Recv: M106 P0 S0.3 I0 F500 H-1                  ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
Recv: M106 P1 S1 I0 F500 H1 T45                 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
Recv: M106 P2 S1 I0 F500 H1 T45                 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on
Recv: 
Recv: ; Tools
Recv: M563 P0 D0 H1                             ; Define tool 0
Recv: G10 P0 X0 Y0 Z0                           ; Set tool 0 axis offsets
Recv: G10 P0 R0 S0                              ; Set initial tool 0 active and standby temperatures to 0C
Recv: 
Recv: 
Recv: ; Automatic saving after power loss is not enabled
Recv: 
Recv: ; Custom settings are not configured
Recv: 
Recv: ; Miscellaneous
Recv: M501                                      ; Load saved parameters from non-volatile memory
Recv: ok
Send: M122
Recv: === Diagnostics ===
Recv: Used output buffers: 1 of 32 (28 max)
Recv: === Platform ===
Recv: RepRapFirmware for LPC17xx based Boards version 1.21RC2 running on ReArm
Recv: CPU Clock Speed (MHz): 100.000000
Recv: Static ram used: 5880
Recv: Dynamic ram used: 14952
Recv: Recycled dynamic ram: 3744
Recv: Stack ram used: 3040 current, 4008 maximum
Recv: Never used ram: 4184
Recv: AHB0 Static ram used: 0
Recv: AHB1 Static ram used: 316
Recv: AHB0 Dynamic ram used: 15388/16384
Recv: AHB1 Dynamic ram used: 7712/16068
Recv: -- RAM Totals --
Recv: Main RAM: 23872/32768 (8896 free)
Recv: AHB0 RAM: 15388/16384 (996 free)
Recv: AHB1 RAM: 8028/16384 (8356 free)
Recv: Error status: 1
Recv: Free file entries: 10
Recv: SD card 0 detected
Recv: SD card longest block write time: 0.0ms
Recv: Date/time: 1970-01-01 00:00:00
Recv: Slowest main loop (seconds): 0.356111; fastest: 0.000019
Recv: 
Recv: === GPIO Special Pins available === (i.e. with M42)
Recv: LogicalPin - PhysicalPin
Recv:  60 - P7_31
Recv: === Move ===
Recv: MaxReps: 0, StepErrors: 0, LaErrors: 0, FreeDm: 100, MinFreeDm 100, MaxWait: 0ms, Underruns: 0, 0
Recv: Scheduled moves: 0, completed moves: 0
Recv: Bed compensation in use: none
Recv: Bed probe heights: 0.000 0.000 0.000 0.000 0.000
Recv: === Heat ===
Recv: Bed heaters = 0, chamberHeaters = -1 -1
Recv: Heater 0 is on, I-accum = 0.0
Recv: === GCodes ===
Recv: Segments left: 0
Recv: Stack records: 1 allocated, 0 in use
Recv: Movement lock held by null
Recv: http is idle in state(s) 0
Recv: telnet is idle in state(s) 0
Recv: file is idle in state(s) 0
Recv: serial is ready with "M122" in state(s) 0
Recv: aux is idle in state(s) 0
Recv: daemon is idle in state(s) 0
Recv: queue is idle in state(s) 0
Recv: autopause is idle in state(s) 0
Recv: Code queue is empty.

Edited 2 time(s). Last edit at 03/11/2018 12:47AM by cyris69.

I'm a visual learner so not sure if images might help or not, here is my machine.



Edited 1 time(s). Last edit at 03/11/2018 12:55AM by cyris69.

Quote
cyris69
I was able to get xy to trigger they are your run of the mill reprap endstops. Your re-arm pins are correct I went through your code.
Can't get probe though, here is all the output. Also in the rrf tool I picked the unmodulated or smart ir probe since it was default and not sure which for capacitive NPN NO probe. Also seems motors aren't activating using the values taken from your config. Sorry, I'm not a big software configurer so a lot of this is still new to me. Been printing for over 5 years but never really did much besides use pre-built firms.

At least we are getting somewhere with the X and Y triggering. I've only been using RRF for about 6 months now but don't know a lot about the different configurations - configured it once and never had to touch again.

I did find some documentation about Connecting a ZProbe and M558 Setting Z probe. The docs mention a capacitive NPN probe needs to use Mode 4 (on a duet) - but this uses the E0 endstop rather than the Probe connector. However, Mode 4 wont work for us currently as its set to NoPin in the config. There must be a good reason they use NPN sensor on E0 (hopefully someone in the know can shed some light on this???). A quick look at the RRF code shows E0 doesn't have the internal pullup enabled, so possibly the pullups affect those sensors? However, I've never used a capacitive sensor before so i really don't know sorry. Hopefully someone else here has some answers?

Edited 1 time(s). Last edit at 03/11/2018 05:24AM by sdavi.

On the Duets you can use NPN sensors with the Z probe input too, but depending on the amount of leakage from your sensor output you might need to add an external pullup resistor to +3.3V. The reason we suggest using the E0 input is because on the Duets it includes an LED + resistor pullup already.

---

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
On the Duets you can use NPN sensors with the Z probe input too, but depending on the amount of leakage from your sensor output you might need to add an external pullup resistor to +3.3V. The reason we suggest using the E0 input is because on the Duets it includes an LED + resistor pullup already.

Thanks for the quick response.

Looks like the ReArm has external pullups to 3.3v on the endstops, so in that case try it at Mode 5, such as M558 P5 H5 F120 T6000 I1

I'm running a Re-Arm with RAMPS as well. I'll have to give this a try when I get a chance. Thanks for your work!
Ethernet is also going to be a fairly important want for me.

Ok, that line of code worked in terminal and all motors moved to home, just my x/z axis thinks min is to the right when it should be left/down. How do I save it to memory, does M500 work with RRF? Also anyway to set z to home to XY 150+offset before probing?

Send: M119
Recv: Endstops - X: at min stop, Y: at min stop, Z: not stopped, Z probe: at min stop
Recv: ok

EDIT:
SO my probe has an x offset of -41 from nozzle, z offset to move down at start of print is -3.45mm, I know large value but I'm lazy to relevel etc. But this is how it's shown in config, why is the offset to move down after homing for print set in the Y axis and I assume the Z is trigger height which I think I make it 3mm from nozzle when setting the probe up

G31 P500 X-41 Y-3.45 Z2.5                 ; Set Z probe trigger value, offset and trigger height

However, I assumed it should look like this?

G31 P500 X-41 Y0 Z-3.45                 ; Set Z probe trigger value, offset and trigger height

Edited 3 time(s). Last edit at 03/11/2018 02:36PM by cyris69.

Also, I'm using DRV88235's physical pot, all but extruder is 1/32 but getting:

M350: Drive Z does not support 32x microstepping

If this helps at all, this is my working marlin 2.0 config.

EDIT: I got it going messing with gcode via terminal. Just need to make sure extruder is proper first. That and it's not turning on my bed.

EDIT #2:

Recv: Error: Attempting to extrude with no tool selected.
Changing monitoring state from 'Operational' to 'Error:  Attempting to extrude with no tool selected.

Edited 3 time(s). Last edit at 03/11/2018 04:06PM by cyris69.

Quote
cyris69
Ok, that line of code worked in terminal and all motors moved to home, just my x/z axis thinks min is to the right when it should be left/down.

Good to hear the probe is working now. If the axis moves the wrong way when jogging then just need to change the settings in config.g where it says drives: i.e. M569 P0 S0 change to M569 P0 S1 (for the x-axis). P0 (Drive0) is X, P1 is Y etc. The S value is 0 or 1 to make it go backwards or forwards. Also, RRF has macros for homing (in /sys on the sd card) so also check homex.g, homey.g, homez.g and homeall.g. If they are homing to min you should see a -ve move, i.e my homex has G1 X-255 to make it goto the endstop at the min side. Its a bit different to the other firmwares, RRF is very configurable but does take a bit of extra learning.

Quote
cyris69
Also anyway to set z to home to XY 150+offset before probing?

Yep, just edit those home files on the sdcard and tell it where to move to. Have a look at my config files homez.g and homeall.g as I move to the center of the bed to do the probe to home Z.

Quote
cyris69
How do I save it to memory, does M500 work with RRF?

Yes it does support M500. It will save it to the SDCard, but you need to edit the config.g to tell it to load those overrides when you reset the board by adding this to the bottom:

M501 ; Load saved parameters

Quote
cyris69
SO my probe has an x offset of -41 from nozzle, z offset to move down at start of print is -3.45mm, I know large value but I'm lazy to relevel etc. But this is how it's shown in config, why is the offset to move down after homing for print set in the Y axis and I assume the Z is trigger height which I think I make it 3mm from nozzle when setting the probe up

That came from the web config tool? Maybe you accidentally entered the numbers in the wrong spot? But yeah the Z offset will use the Z param as you would expect it should I believe the Z offset are different to marlin, in your case should be Z3.45 and not negative - i.e. when you home Z it triggers the probe and stops so now the machine's Z position (nozzle height from bed) is actually at z=3.45.

Quote
cyris69
Also, I'm using DRV88235's physical pot, all but extruder is 1/32 but getting:
M350: Drive Z does not support 32x microstepping

Don't worry about that, M350 isn't actually needed and you can delete that line if you want - microstepping is set by jumpers on the RAMPS. I'll make it ignore those warnings for the next update.

Quote
cyris69
Recv: Error: Attempting to extrude with no tool selected.
Changing monitoring state from 'Operational' to 'Error: Attempting to extrude with no tool selected

RRF starts up with no tool selected. You need to send the command T0 to select the first tool (hotend). I have T0 at the end of my config.g so its already selected when it starts, but i think most slicers these days will put that in the start of the gcode file.

Ok good to know, I reset the machine and assumed it would keep settings but it didnt so I'll mess with that again. I'll look at your config about the tool selection..

Have any idea why hotend is working but bed isn't being triggered? It is controlled by a mosfet board which is wired into the board like you'd normally do if direct. Worked on marlin/smoothie but haven't gotten down to reading more of the code yet. However, this all feels quite promising at its current state as the issues are PEBCAK. I plan on if all goes well to get another rearm and use it on my rostock max v3 since duet no matter how much I drool over just won't ever happen

So what you are saying is that the offset for the probe where I had in marlin as -3.45mm which I'm sure if you've used marlin, I assume you have so know how it works. So when printing it would be at default 10mm from bed then move down 10+offset from nozzle to bed so technically -13.45mm total down to bed with enough space between to print a normal first layer.. With that said I'd actually just put offset how high I want the nozzle to be not how much its moving down, so I'd use lets say I like my nozzle to be about 0.05 to 0.10 from the bed I'd just enter positive 0.05 or 0.10 not -3.45. I don't have an LCD so not sure how to babystep it down so just use octoprint to move down until the prob trigger and measure distance from nozzle to bed or just from probe to bed?

EDIT:

How I did my probe setup originally was put a 3mm thick piece of aluminum under the probe then let the probe rest on it and tighten it down then put the same metal under the nozzle and let that settle while the bed is up to temp then adjust the trigger distance which will be ~3mm. Then add my positive offset or 0.05-0.10 or whatever. I also noticed that I hade T0; at the end of my config already.

Edited 5 time(s). Last edit at 03/12/2018 01:10AM by cyris69.

Quote
cyris69
Have any idea why hotend is working but bed isn't being triggered? It is controlled by a mosfet board which is wired into the board like you'd normally do if direct. Worked on marlin/smoothie but haven't gotten down to reading more of the code yet. However, this all feels quite promising at its current state as the issues are PEBCAK. I plan on if all goes well to get another rearm and use it on my rostock max v3 since duet no matter how much I drool over just won't ever happen

Yes, sounds like its very close now, mostly just getting config files sorted so far. Can you confirm that the bed temperature is reading the right value (around room temp) by running M105 or looking at the temps in the host program. Also, I think there was a LED on the bottom of the RAMPS board which goes on when the heaters were enabled, is the LED turning on? The ReArm pinout says the Heated Bed is P2_7 which is what i've used in the code.

Quote
cyris69
So what you are saying is that the offset for the probe where I had in marlin as -3.45mm which I'm sure if you've used marlin, I assume you have so know how it works. So when printing it would be at default 10mm from bed then move down 10+offset from nozzle to bed so technically -13.45mm total down to bed with enough space between to print a normal first layer.. With that said I'd actually just put offset how high I want the nozzle to be not how much its moving down, so I'd use lets say I like my nozzle to be about 0.05 to 0.10 from the bed I'd just enter positive 0.05 or 0.10 not -3.45. I don't have an LCD so not sure how to babystep it down so just use octoprint to move down until the prob trigger and measure distance from nozzle to bed or just from probe to bed?

To measure the offset go down until the probe triggers, then measure the distance from that position until the nozzle touches the bed. Lets assume that you measure 3.45mm. Update config.g to have your G31 P500 X-41 Y0 Z3.45 and when you run G30 (do a single probe) soon at the probe triggers RRF then loads that offset, in this case 3.45mm, as the new current Z position. If you dont like that as a starting point, then you can edit homez.g and homeall.g and tell it it move closer to the bed after it probed. Here is an example for homez.g (assuming there is no z_max endstop, using probe to home z and the offset is correctly set) to lift up 5mm (to always ensure the probe is above its offset height), move to bed center, probe, then move nozzle to be 0.1mm from bed:

; Lift Z 5mm up relative to current position
G91
G1 Z5 F6000
G90 ; Back to absolute positioning

;move to center of bed
G1 X125 Y100 F6000
G30; do probe

;slow move to desired z position
G1 Z0.1 F100

However, I'd probably recommend to not do it like that in case you want to run auto level or something before each print. My preference is to move back up the 5mm after a probe in homez.g, and in the slicer start G-code tell it to move close to bed before it starts heating so it doesnt ooze out at the start. But RRF is very configurable so you can do what ever suits your needs best

Edited 2 time(s). Last edit at 03/12/2018 02:09AM by sdavi.

Apparently My hot end has been at 200C for like 18 hours without me knowing... however the M105 reports the correct room temp for the bed.

This is how I have my ramps wired, haven't noticed any new lights flashing and on my mosfet board for controlling the bed has an LED that will blink light when its sending power to bed. If you look at the LED closets to the group of mosfets the LED labeled LED1 is red and constant lit as normal no other LEDS are lit


Edited 1 time(s). Last edit at 03/12/2018 12:37PM by cyris69.

Got motors going correct way, can extrude and its pushing the right way. Part fan doesn't do anything but maybe thats the firmware. I just used second hotend terminals like I found to do online so maybe need to adjust that somehow. Alos, when setting the z offset, if I do a home for Z it just goes down 5 then back up even though I tested at Z5 offset.

Also seeing if it was because I wasn't using G30, so I tried that and got this:

Send: G30
Recv: Error: Z probe already triggered at start of probing move
Changing monitoring state from 'Operational' to 'Error:  Z probe already triggered at start of probing move
'

Edited 1 time(s). Last edit at 03/12/2018 07:17PM by cyris69.

Quote
cyris69
Apparently My hot end has been at 200C for like 18 hours without me knowing... however the M105 reports the correct room temp for the bed.

This is how I have my ramps wired, haven't noticed any new lights flashing and on my mosfet board for controlling the bed has an LED that will blink light when its sending power to bed. If you look at the LED closets to the group of mosfets the LED labeled LED1 is red and constant lit as normal no other LEDS are lit

Number one rule of 3D printing safety, never leave it running unattended and make sure power is off.

Hmm, I checked the smoothie config for rearm and it also says 2.7. My AzteegX5 pin out is actually quite similar to the rearm, and luckily the Bed on it is also 2.7, so i loaded up the rearm bin onto the azteeg and my bed heater led does turn on. So i'm not sure why its not working for you on the ReArm. I dug out my old RAMPS board, and the LED for the bed is behind the mosfet, between the mosfet and extruder driver, the led is labelled LED2. I assume the external mosfet board is powered by the same power supply as printer ?

Quote
cyris69
Got motors going correct way, can extrude and its pushing the right way. Part fan doesn't do anything but maybe thats the firmware. I just used second hotend terminals like I found to do online so maybe need to adjust that somehow. Alos, when setting the z offset, if I do a home for Z it just goes down 5 then back up even though I tested at Z5 offset.

Found out why the cooling fan doesnt work. I had it setup as 2nd heater in the config, and inadvertently also again the same pin as cooling fan pin. Attached updated firmware.bin for ReArm with 2nd heater (as named in the docs) configured as cooling fan - see if that fixes the fan issue.

Is the Z-axis confirmed to be moving the right way? It should move up 5 (or whatever is in the homez.g and/or homeall.g) to make sure the probe isnt triggered before beginning the G30 probe.

The probe is working and z is moving in correct direction. So the probe will always go back to 5 no matter what until it prints then uses the value you've set?

Also should I be uploading the .g macro files to octoprint and not using the homing buttons or terminal for those functions? Wish octo had a macro plugin

I'll see if I can run a print on a cold bed since that isn't working yet and see what it does. We need a discord somewhere to chat more real-time to aid in holding my hand more

Updated experimental version released: download here. There are now 2 versions: Network and non-network versions. Currently, they are the same except one does not have the networking code compiled in.

Changes:

• Updated to RepRapFirmware 1.21
• Combined AHB SRAM 0 and 1 to make memory management a bit easier. Both locations are DMA safe addresses for ethernet DMA transfers.
• Bug fixes from first version:
  
  • Updated to detect CPU speed for LPC1768 (100MHz) and LPC1769 (120MHz)
  • Fixed bug affecting correct heater operation on P2.7
  • Updated step interrupt timing to match 128 divisor which DDA was also expecting.
• Added Ethernet support (8720A PHY chip only)
  
  • !Important! If running the network firmware on a board without a PHY chip or on a board with optional LAN adapter disconnected, you must disable Networking in config.g. The LPC will stop responding if attempting to initialise EMAC without the PHY chip connected. Networking can be disabled by setting M552 S0 in config.g
• Networking currently requires a lot of memory. In order to free enough memory and also allow for a delta configuration + calibration, the following compromises were needed:
  
  • Reduced maximum number of probe points to 121
  • Delta maximum calibration points to 16
  • Max files open limited to 3
  • Only 1 HTTP connection permitted at a time. This will also make the initial load of the webpage a slightly longer. Since there is only 1 listener downloading from the GUI can cause it to "disconnect" as the ajax status update calls will fail. Increasing the AJAX retries in the Settings Panel on the GUI can help - a retry count of around 10 seems sufficient for general usage including loading/saving config/macro files. The main cause for disconnect would be downloading a large file from the SDCard, which is probably not something most people would do anyway - just need to click connect again after the download to reconnect. Uploading GCode files to the SDCard doesn't cause any issue.
  • MDNS and Netbios disabled.
  • Telnet and FTP access disabled.

Reminders:

• RRF only defines a single endstop per axis. It can be configured as a max (high end) or min (low end) endstop.
• Boards with both Min and Max endstop headers should be wired as:
  

  X_Min	(Spare)
  X_Max	Wire to X Endstop
  Y_Min	(Spare)
  Y_Max	Wire to Y Endstop
  Z_Min	Wire to Z Probe
  Z_Max	Wire to Z endstop

• By default there are no E0 and E1 endstops. So don't choose a probe mode which requires them (or if needed can modify header config file and compile). Those using induction NPN probe should use Mode 5 (confirmed by cyris69).
• RRF is optimised for drivers on the Duet board, therefore some boards will require different pulse timings (see below) to avoid losing steps.
• v1.21 by default now requires all axes to be homed before any axis can be moved.

As a starting point, use the RepRapFirmware Configuration Tool to create and download initial config files. Select the Duet Ethernet as the board, but please be certain to check the config.g afterwards, specifically: disable Networking if needed, adding correct stepper driver timing pulses (see next) and ensure correct z-probe setup (if using one). Please refer to the RRF GCodes for detailed information for settings in config.g.

Motor driver configuration M569 add the T parameter to select correct step pulse timings. The Azteeg X5 Mini has DRV8825, ReArm has pluggable drivers (refer to datasheets for specific driver settings). I have extracted some popular driver settings from the datasheets as a starting point.

Driver	Width	Interval	Setup	Hold
DRV8825	1.9	1.9	0.65	0.65
A4988, A4982	1.0	1.0	0.2	0.2
A5984	1.0	1.0	0.4	0.4

Known Issues

• Running GCode that returns large amount of text to the "console" through the Web Gui will cause the firmware to become unresponsive (I.e. running M503). Do not run these commands during a print.

Experimental: Use at own risk, do not leave unattended etc etc

Wow, I'm impressed that you managed to enable networking using only 64kb of RAM!

I suppose it's too much to hope that there's another chip pin-compatible to the LPC1769 with 128kb RAM, that could be used to upgrade existing boards? 128kb is enough to run the in-development RTOS version of RepRapFirmware.

You might be able to fix the M503 issue (and I suspect you may find an issue with M122 as well) by generating part of the response, then returning to allow the web client to take that part and release the buffers, before you generate the next chunk. But this might still cause momentary pauses if you use those commands during a print.

---

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
Wow, I'm impressed that you managed to enable networking using only 64kb of RAM!

It is very tight at the moment. When configured as a delta, there is only 1928 bytes free in main RAM and only 8 bytes left in the AHB SRAM.

I ended up using lwip2 which actually saved a bit of memory compared to 1.4 and ended up using the newer networking code too. Reduced to 1 network buffer and even that was cut down to 1.5k from 2k.

Quote
dc42
I suppose it's too much to hope that there's another chip pin-compatible to the LPC1769 with 128kb RAM, that could be used to upgrade existing boards? 128kb is enough to run the in-development RTOS version of RepRapFirmware.

That's an interesting idea. I'll be keeping an eye out on the RTOS version in the future for my Duet Wifi tho!

Quote
dc42
You might be able to fix the M503 issue (and I suspect you may find an issue with M122 as well) by generating part of the response, then returning to allow the web client to take that part and release the buffers, before you generate the next chunk. But this might still cause momentary pauses if you use those commands during a print.

M122 is currently ok. Unless there are other commands that produce long output it seems to be a minor issue if its only M503, especially when there is a much better way to look at (and edit) the config settings through the GUI editor