|
Re: LPC port of RepRapFirmware March 10, 2018 06:15AM |
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.
|
Re: LPC port of RepRapFirmware March 11, 2018 12:21AM |
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.
|
Re: LPC port of RepRapFirmware March 11, 2018 12:42AM |
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.
Edited 2 time(s). Last edit at 03/11/2018 12:47AM by cyris69.
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.
|
Re: LPC port of RepRapFirmware March 11, 2018 12:52AM |
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.
Edited 1 time(s). Last edit at 03/11/2018 12:55AM by cyris69.
|
Re: LPC port of RepRapFirmware March 11, 2018 06:35PM |
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.
|
Re: LPC port of RepRapFirmware March 11, 2018 11:53PM |
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.
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.
|
Re: LPC port of RepRapFirmware March 12, 2018 01:55AM |
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.
|
Re: LPC port of RepRapFirmware March 12, 2018 12:29PM |
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.
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.
|
Re: LPC port of RepRapFirmware March 13, 2018 03:14AM |
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
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
|
Re: LPC port of RepRapFirmware March 30, 2018 09:25PM |
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
Sorry, only registered users may post in this forum.