LPC port of RepRapFirmware

Quote
AlexY
What's the current state of the v2 branch? If it's able to run a full print I'll try it otherwise I'll clone 1.21 first.

How is board selection done in RRF? In Marlin it's done by defining the motherboard in the config but I don't see something similar here. Also, does RRF use the onboard SD reader or the reader on the LCD controller?

Start with 1.21, i've attached the makefile i used (it is bit of a mess cause i just kept adding to it over time). The board selection is defined in the makefile (just passed as compiler flags), the only 2 options you really need to change in the makefile are BOARD and NETWORKING. The BOARD value you set will be used as the ifdef in the pins_lpc to select the variant. If your using eclipse or something else look at the makefile flags to see the other defines you also need to set.

The onboard SDCard is expected to be present at boot to read the config files etc. The last lpc 1.21 version checked in didnt support the external card - this is added in V2 (although it still expects the internal card to be present).

Getting the projects set up now. What build configuration should I use to build CoreLPC?

The makefile is configured to build both CoreLPC and RepRapFirmware. If you just want to build the core run make coreLPC which will build core.a. I've only used the makefile on macOS so it may need some changes on other OSes.

Thanks for the update, @sdavi. The Re-Arm port has been working well with the exception of disconnecting when viewing the gcode file directory via DWC. Hoping 2.0 is able to fix that.

While I'm typing, I'd just like to reiterate how much I love RRF and DWC! I had to use manual probing for delta auto calibration and it was SO easy to do within DWC. This was on a real Duet Wifi.

Edited 1 time(s). Last edit at 08/03/2018 07:04AM by digi2life.

@sdavi Is it ok to comment out the SharedSpi lines in the makefile? I'm not using an SPI thermocouple and the build is failing because it can't find the SharedSpi folder.

Quote
AlexY
@sdavi Is it ok to comment out the SharedSpi lines in the makefile? I'm not using an SPI thermocouple and the build is failing because it can't find the SharedSpi folder.

Ah yeah, sorry I forgot I changed the makefile when i started the sharedSPI in V1 branch before moving over to V2 - it's failing cause it's bringing in the LCD and SPI heat sensor sources which need sharedspi. I dug up the makefile from my backups near the date of the last commit so this one should compile. See attached.

Getting an error on line 242 about 'cc' being an unrecognized debug level. Commented out the -gcc option and it seems to work. What effect does that option have?

Quote
AlexY
Getting an error on line 242 about 'cc' being an unrecognized debug level. Commented out the -gcc option and it seems to work. What effect does that option have?

Yeah that's ok, i had to do the same thing just recently when upgrading to the latest arm compiler as well.

Unfortunately it looks like the board hangs on startup with the hotend fan on full. Might be a pin config error but not sure how to debug.

Quote
AlexY
Unfortunately it looks like the board hangs on startup with the hotend fan on full. Might be a pin config error but not sure how to debug.

Few things to check. Make sure networking is disabled if there is none - the manual says the cpu can get locked if the reference clocks are not present on the pins when configuring ethernet. Using the Non networking version (set NETWORKING to false in the makefile) is a good place to start anyway as there is a lot more RAM free to make sure its not a out of memory issue.

Use a simple terminal program to connect rather than one of the printer host programs as some will wait for certain responses etc. And connect to the board as soon as possible to see any output which can help to see where it is getting up to (and adding in any extra print statements can help too).

If you attach the new pin config header file I can have a look over it.

Here is the LPC folder. Networking should be disabled in the makefile, but I'll double check. I noticed that some of the pins in the special pin map overlap with some of the used pins. Could this cause the issue?

Edited 1 time(s). Last edit at 08/07/2018 10:39AM by AlexY.

Quote
AlexY
Here is the LPC folder. Networking should be disabled in the makefile, but I'll double check. I noticed that some of the pins in the special pin map overlap with some of the used pins. Could this cause the issue?

I had a quick look over the config and changed a few things (see attached) based on the smoothie config i found online for the board. The enable pin for X i think should be P0_4 and not P2_4 (which is also defined as the hotend heater pin). I also fixed the variable pin_port2_pos to match the stepper positions (its used when creating the bitmask for stepping).

If the board has a LED, the default in the CoreLPC is to flash the PLAY led (which is default P4_28 on most boards) from systick. It should change state every 0.5 seconds when everything is working.

I also compiled the AZSMZ and ran it on my AzteegX5 which seems to run just fine (using the attached updated header) - I can connect to it, run M122 etc etc.

It is also worth checking the config.g files, the fan may be turning on cause its configured to by M106 but you can change that to start off by setting S0 (the online configurator has first fan starting at 30% if you accept the defaults).

I've also attached the firmware.bin using the updated pins config to test if there are some other issues when your compiling.

Looks like the fixes helped! I had to run make distclean first since simply trying to make didn't change anything. I can talk to the board now

I'm having a weird issue with fan PWM. The fan only turns on at 50% and runs at full speed from 50-100%. Looks like it's not trying to PWM at all. However, when the fan turns off, the fan LED slowly fades out instead of abruptly turning off. The hotend seems to PWM just fine, so I'm not really sure what could be causing the issue.

Quote
AlexY
I'm having a weird issue with fan PWM. The fan only turns on at 50% and runs at full speed from 50-100%. Looks like it's not trying to PWM at all. However, when the fan turns off, the fan LED slowly fades out instead of abruptly turning off. The hotend seems to PWM just fine, so I'm not really sure what could be causing the issue.

It seems RRF expects the fan to be on a Hardware PWM, and P2_7 is not a H/W PWM capable pin, so it will resort to a digital out (as you are currently experiencing).

There are still some hardware timers free which you could use to generate the PWM signals using interrupts. Each timer has 4 match registers so you just set one to the PWM period which triggers interrupt + timer reset and set pins high, and you'd have 3 match registers left to generate interrupts for 3 outputs (with the same PWM frequency) and setting the corresponding pin low. Have a look at the Step and Network timer code in platform.cpp on how to setup the timers. This is something I might look at adding to the v2 code later.

@sdavi, if you need to free up more memory here is another possibility. Currently each DDA has a table of pointers to possible DriveMovement objects. There is also a pointer to a linked list of these DriveMovement objects, in step-time order, which is filled in by Prepare(). I had it in mind to do away with the table of pointers and use just the linked list. To this end, most accesses to DMs by drive are done by calling FindDM(drive). Currently this uses the table; but it could search the linked list instead.

So you could:

- Do away with the table 'dmp' in the DDA, saving (4 * DRIVES * number_of_DDAs) bytes.
- Change FindDM to search the linked list for the DM for the specified drive instead of using the table
- When allocating DMs in DDA::Init(), link them into the linked list instead of entering them in the table
- Change DDA:: Step() so that when a DM has completed its steps, it is re-inserted into the link list after all still-active DMs
- Change DDA:: Step so that it considers the move is complete when the first DM in the linked list is complete, instead of when the linked list is empty
- Change Move:: Spin() to free up DMs from the linked list of completed DDAs instead of from the table

I may implement this in a future release myself.

btw my latest commits to branch v2-dev include an experimental feature called Dynamic Acceleration Adjustment. This increases the size of both the DDAs and the DMs; so you may wish to avoid taking this change at least until the feature is proven to be useful.

HTH David

Edited 2 time(s). Last edit at 08/12/2018 02:16PM 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].

Thanks David, will look into that.

I'm still getting into the FreeRTOS stuff, any recommendations for the priorities of new tasks? I'm using FreeRTOS+TCP for the networking, which has 2 additional tasks - one for IP and one for EMAC. Currently, I moved Heat up a priority level and have them both running at the same priority at the old heat priority. So far it runs quite well on my CNC machine (no actual cutting yet), although CNC movements are a lot slower than a printer, so im not sure how well it will go printing yet. Anything to look out for?

Quote
sdavi
Thanks David, will look into that.

I'm still getting into the FreeRTOS stuff, any recommendations for the priorities of new tasks? I'm using FreeRTOS+TCP for the networking, which has 2 additional tasks - one for IP and one for EMAC. Currently, I moved Heat up a priority level and have them both running at the same priority at the old heat priority. So far it runs quite well on my CNC machine (no actual cutting yet), although CNC movements are a lot slower than a printer, so im not sure how well it will go printing yet. Anything to look out for?

I haven't used FreeRTOS+TCP, but my guess is that it will have been designed to have both its tasks suspended when there is no network activity. If that is the case then your priority scheme sounds good to me.

---

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].

Very experimental RepRapFirmware v2.01 RTOS port now available.

Source code for CoreLPC V2 (along with PreBuilt Binaries, FreeRTOS, FreeRTOS+TCP and build scripts) and RepRapFirmware v2

Pre-built binaries are also available for various boards.

• As with the previous version there are two versions: Networking and No-Networking.
• *IMPORTANT* those using the special pins i.e. for Servos etc the logical pin numbering has changed compared to previous version (for future LCD support), please check with M122 and update where necessary.
• SharedSPI now implemented, enabling external SD card and also SPI thermocouple. ReArm has the thermocouple CS pin set to a spare Pin 0_27 (which i believe is on Aux1). Others will need to edit the header files and select a spare pin for their board and recompile. Untested.
• Configured 3 hardware timers to do PWM (10Hz, 50Hz and 250Hz) as HW PWM only operates at 1 frequency for all channels and some board variants have heaters/fans connected to non HW PWM pins.
  - You will need to re-run Autotune for all heaters again as there was a previous issue with PWM (where the bed and heater were both on HW PWM) which is fixed, and heaters not on a HW PWM Pin are now on Timer PWM pins
  - Most boards will now have Heated Beds running on TimerPWM1 at 10Hz even if the pin is a HW PWM pin (unless there is no hotends on HW PWM). HW PWM defaults to be used for Hotends/Fans and will be run at 250Hz
  - Any Spare pins can also be configured to use TimerPWM by editing the header file and recompiling. Ensure the frequency used in GCode to enable PWM, matches the frequency of the TimerPWM used, otherwise it will fall-back to being a digital output.
  - A Hardware Capable PWM pin can also be configured as a TimerPWM and TimerPWM will be used instead of Hardware PWM. If the Requested frequency doesnt match it does not fall back to hardware PWM, and will be Digital Out.
  - ReArm now has Servo outputs 1, 2 and 3 configured to use Timer2 at 50Hz for better servo compatibility.
  - Boards other than ReArm will need to configure a spare pin onto Timer 2 PWM to use servos in the variant header file and recompile.
  - TimerPWM must be defined in the variant header file and recompiled. This saves memory and also saves searching arrays in ISR to make them as fast as possible.
• PWM frequency must be set when configuring Cooling Fans. For most boards this will be Set to the Hotend Frequency of 250Hz i.e. M106 F250 in config.g.
• External interrupt pins are limited to 3 and must be defined in the variant header file before being used, i.e. for Fan RPM, filament detection etc. This saves a lot of memory this way, and also avoids searching arrays within the ISR. To use this feature update variant header file and recompile.
• Added new board variants for AZSMZ (based on AlexY's config) and MKS SBase - both untested check pinouts in headers file before using.

Networking

• As before, if using the Networking firmware on a board without a PHY chip then you must ensure that your config.g does not enable Networking.
• Networking version currently has the same restrictions as previous v1 port:
  
  • Max 16 calibrations points for delta
  • 121 max points for Grid probing (with 21 max points per X row)
  • Max 32 Probe points for G30
• Switched to FreeRTOS +TCP for networking instead of lwip
• Recommended to upgrade DWC to the latest version
• There is only 1 HTTP Listener running so there can only be one connection at a time.
• Telnet and FTP access are disabled.

Non-Networking

• The non-networking version does not have the previous restrictions and has the same probing/calibration settings as the DUETs, which are:
  
  • Max 32 calibrations points for delta
  • 441 max points for Grid probing (with 41 max points per X row)
  • Max 32 Probe points for G30

Reminders

• Default timing for drivers may not be suitable for certain drivers (i.e. DRV8825) and timings should be set in config.g (i.e, M569)
• Endstops E0 and E1 are not available by default, so be aware when following documents for configuring zprobe and selecting the mode.
• 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 (configured as either max or min in config.g), and Z-Min being used for Z-probe. The X-Min and Y-Min pins are free for other purposes.
• M122 now shows if PWM and TimerPWM are running (and their frequencies) and also Special Pins and their logical pin mappings to use from GCode

Known Issues
For some reason, some older SD cards fail to initialise (not sure why yet - this may have been an issue in previous versions too) however doesn't seem to be an issue with newer cards.

***Note this experimental and used at your own risk. I don't have access to most of the boards so it is recommended to not leave the printer unattended and test all movements, correct heater operation etc are working correctly before attempting a print.***

Edited 1 time(s). Last edit at 08/22/2018 01:57AM by sdavi.

Thank you so much! I've been running your previous port on the ReArm with no issues other than networking connectivity wonkiness. I'll give this a try and report back.

@sdavi looks good; I'll run some test prints soon. Once 12864 LCD support is added, I'll finally be able to run Duet standalone .

Edited 1 time(s). Last edit at 08/22/2018 08:15PM by AlexY.

Looks like this version is having issues with homing - when I home x or y it resets the board, though z is fine. Do you know what could be causing the issue? The previous version worked with the same gcode configuration.

Quote
AlexY
Looks like this version is having issues with homing - when I home x or y it resets the board, though z is fine. Do you know what could be causing the issue? The previous version worked with the same gcode configuration.

I just loaded up the AZSMZ binary onto my smoothieboard (fortunately the motor and endstops match up to the smoothieboard) and it had no issues with homing X or Y.

Does it reset soon as you run G28 or do the motors move before it resets? Are you using regular microswitches?

Can you confirm that M119 shows correct output when the switches are pressed and released?

Also, I recently added in the Software Reset Data so can you run M122 after the reset which hopefully will show the cause of the reset to help narrow it down.

I'm using normal microswitches. During x or y homing the printer moves correctly but the software resets when it reaches the endstop. This happens when homing all, or x and y individually. Could CoreXY have something to do with it? I'll run M122 later today to see the message.

M119 works correctly for all endstops. The error I got was the following:

22:39:32.817 : Last software reset time unknown, reason: Assertion failed, spinning module GCodes, available RAM 1108 bytes (slot 0)
22:39:32.818 : Software reset code 0x0093 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00428811 BFAR 0xe000ed38 SP 0x10007cdc Task 0xa5a5a5a5
22:39:32.818 : Stack: 10007b80 00000001 00011103 2007f95c ffffffff ffffffff 2007efd4 2007f95c ffffffff 00000000 02000000 2007f510 000089f7 10007d40 10007d6c 00000002 0000e095 10007d9d 0000e0db 2007f510 0000cf4b 2e353132 a5003030
22:39:32.818 : Error status: 0

Quote
AlexY
M119 works correctly for all endstops. The error I got was the following:

22:39:32.817 : Last software reset time unknown, reason: Assertion failed, spinning module GCodes, available RAM 1108 bytes (slot 0)
22:39:32.818 : Software reset code 0x0093 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00428811 BFAR 0xe000ed38 SP 0x10007cdc Task 0xa5a5a5a5
22:39:32.818 : Stack: 10007b80 00000001 00011103 2007f95c ffffffff ffffffff 2007efd4 2007f95c ffffffff 00000000 02000000 2007f510 000089f7 10007d40 10007d6c 00000002 0000e095 10007d9d 0000e0db 2007f510 0000cf4b 2e353132 a5003030
22:39:32.818 : Error status: 0

Ahh, usually that crops up when using DebugPrintf, which makes me suspect that debugging has been turned on i.e. with M111. Check that its not enabled in config.g. Also, if you using Repetier Host, and if "easy mode" is turned off, make sure that in the Manual Control tab at the bottom that Echo, Info, and Errors are all unchecked (see Documentation at bottom of page). If you run M111 it should show that all modules are disabled for debugging. Other host programs may also enable debugging too.

I was able to replicate the Assertion fault when debugging is turned on (M111 S6) and homing X axis in CoreXY mode, so hopefully turning it off will fix your problem.

Works now, thanks. Repetier-Host sends M111 S6 on connection, which caused the problem. Is there a way to disable debugging to eliminate the need for manually setting M111 each time, or alternatively preventing Repetier-Host from sending M111 S6 on connection start?

Quote
AlexY
Works now, thanks. Repetier-Host sends M111 S6 on connection, which caused the problem. Is there a way to disable debugging to eliminate the need for manually setting M111 each time, or alternatively preventing Repetier-Host from sending M111 S6 on connection start?

I don't use Repetier Host so I don't really know.

Now I know that some programs turn it on I'll look into it. You could recompile and change DebugPrintf in RepRapFirmware.cpp to be an empty function as a temporary fix so it doesn't actually print anything.

I don't know your fork, but my guess is that enabling that debug caused a stack overflow during a debugPrintf call, that was detected by FreeRTOS.

---

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].

@sdavi I tried a relatively high-speed print and it looks like the printer is stuttering in some areas causing layer shifting. Not sure what the cause is; perhaps slow SD reads or something with memory usage? Unfortunately I won't have access to my printer for a while so I'll be unable to test.