Welcome! Log In Create A New Profile

Advanced

LPC port of RepRapFirmware

Posted by sdavi 
Re: LPC port of RepRapFirmware
October 12, 2019 04:32AM
Quote
DocSolo
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 places, so luckily its already implemented in the core (although I have only done very basic tests on it some time ago), so you just need to call attachInterrupt with the callback handler and what pin condition you want to trigger on, i.e falling edge etc.

For the SPI, if you are going to dedicate spp0 port to the lan, you could just copy whats needed straight from the SharedSPI code. Otherwise you probably could use the sharedSPI but would need to also add in the lock from RRF for the spiMutex.


Also, it looks like its using BufferAllocation_2 (dynamic allocation) for +TCP buffer management, so to use it, you'll have to comment out BufferAllocation_1 currently used in the makefile and uncomment BufferAllocation_2. Otherwise need to implement the extra function for static allocation to work. See here for differences between the two.

Edited 2 time(s). Last edit at 10/12/2019 06:52AM by sdavi.
Re: LPC port of RepRapFirmware
October 13, 2019 01:22AM
for all that work, why not solder a wire to the pin on the chip to get a LAN8270 module to work?
if you map out the pims on the SKR all but one are available on the board.
Re: LPC port of RepRapFirmware
October 13, 2019 03:28PM
Quote
DocSolo
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

If you want to add WiFi to your board and run RRF on it, you would be better off using the wiz820io module. It uses the W5500 chip that we use in Duet Ethernet and Duet Maestro, so the code to drive it is already in RRF. We used that module to prototype the Duet Ethernet.



Large delta printer [miscsolutions.wordpress.com], Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: LPC port of RepRapFirmware
October 15, 2019 06:56PM
Quote
PB
3. On temperature plot I notice short but high spikes at all thermistors. Probably only one reading wrong. Not causing problems. [attachment 112100 Untitled.jpg]

@PB- did you get this figured out? I have similar and its driving me nuts tryging to track it down.

Anyone elser get this behavior ?



Edited 1 time(s). Last edit at 10/15/2019 06:56PM by sinned.
PB
Re: LPC port of RepRapFirmware
October 25, 2019 02:26PM
As far as I remember the spikes are indeed present but not causing problems as my (autocalibrated) PID parameters are not sensitive to it so temperature of heater is stable despite one wrong reading sometimes. I forgot about this because really there is no problem to me.

Also I remember that once I got vastly increased number of wrong readings and the cause was self-unsoldering of heater (!) connector due to heating of a joint. One day it stopped heating and temperature readings got strong noise. Eventually I manually repaired it with thick air wire and since then everything is working nice (but weak noise like on your picture is still present I think).
Re: LPC port of RepRapFirmware
October 26, 2019 02:50AM
I can't see any spikes on my dev board. Watching the numbers it only varies by 0.1 deg.

Re: LPC port of RepRapFirmware
October 26, 2019 04:18PM
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.

that is one thing i miss about octoprint- the tempsgraph and the log.

Edited 1 time(s). Last edit at 10/26/2019 04:18PM by sinned.
Re: LPC port of RepRapFirmware
October 27, 2019 12:31AM
Quote
sinned
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.

that is one thing i miss about octoprint- the tempsgraph and the log.

RRF also allows you to define what conditions define a "heater fault" with M570. You can set how far it can deviate from the set temp and also how long the fault must exist before it triggers the heater fault.

In RRF3 I moved all heater PWM to software so they could be individually configurable, I had to change the priority of the timer generating the software PWM as I noticed that only while printing many very short moves the temp would fluctuate a bit, I suspect this was caused by the step interrupt, so now it is a higher priority than the step interrupt. That priority issue would likely be affecting the V2 version too, but only for those boards that didn't have the heater pin on a hardware capable PWM pin. Although there has been no interest in RRF3 on lpc so I haven't bothered releasing anymore updated binaries for it.

Edited 1 time(s). Last edit at 10/27/2019 12:34AM by sdavi.
Re: LPC port of RepRapFirmware
October 27, 2019 02:20AM
Quote
sdavi
Quote
sinned
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.

that is one thing i miss about octoprint- the tempsgraph and the log.

RRF also allows you to define what conditions define a "heater fault" with M570. You can set how far it can deviate from the set temp and also how long the fault must exist before it triggers the heater fault.

In RRF3 I moved all heater PWM to software so they could be individually configurable, I had to change the priority of the timer generating the software PWM as I noticed that only while printing many very short moves the temp would fluctuate a bit, I suspect this was caused by the step interrupt, so now it is a higher priority than the step interrupt. That priority issue would likely be affecting the V2 version too, but only for those boards that didn't have the heater pin on a hardware capable PWM pin. Although there has been no interest in RRF3 on lpc so I haven't bothered releasing anymore updated binaries for it.

For bed heating in bang bang mode (I don't see the need for PID here) I suppose you don't use PWM ?


"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)
Re: LPC port of RepRapFirmware
October 27, 2019 05:43AM
Quote
MKSA
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 speculating about the priority issue based on observations (however I did change how PWM was handled in RRF3 too). I also think the heater i was using for testing was a bit too over-powered for the job which may have made it more noticeable. Most of peoples issues with temp spikes are usually caused by interference/noise as they are present when the machine was idle and/or disappeared when turning motors off. I just thought I'd mention another possible source of "spikes" that only occur in specific parts when printing?

If anyone is interested in the specifics:

In early RRF2 LPC days, and to save memory, 3 Hardware Timers provided the 3 default PWMs (10Hz, 50Hz and 250Hz) to non-pwm pins (or for pins to run at a different frequency than the hardware pwm as it only has 1 frequency shared across all 6 channels) and all the on/off times were held in the MRx registers of the timer and the timer reset to 0 at the end of the period. Interrupts occur at each pins "On" time, and at the end of the period (to reset the timer and any pins that are not set to 100% PWM). Each timer configured that way could only handle 3 pins each.

In RRF3 you can configure the PWM frequency for heaters etc in GCode. Checking and making sure those values matched with the ones in the board.txt config was adding extra work and possible source of confusion with configurations, so with the extra memory available to store the freq and pwm values of each pwm output, I thought I'd use a single free running timer to generate the interrupt when needed. Servos were moved to (and automatically use if possible) the hardware PWM with an automatic fallback to timer2 pwm as used in RRF2. No entries in board.txt anymore and no real need to determine if pins are HW-PWM capable etc. You can also change the frequencies on the fly which makes testing a bit easier.

Edited 3 time(s). Last edit at 10/27/2019 05:51AM by sdavi.
Re: LPC port of RepRapFirmware
October 27, 2019 06:15AM
A simple regular Prusa bed heater is around 8 A at 12V. When switching and in case of improper wiring, ground loop will induce spikes that may be picked by the thermistor wiring and explain these T° jumps.
A scope could show if they happen during switching (bang bang or PWM).


"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)
Re: LPC port of RepRapFirmware
October 27, 2019 02:27PM
Thanks all.

1. My silicone bed heater is mains powered and controlled from the heater output to an SSR. The aluminum bed has an additional ground, going back to mains ground. The thermistor is 'built in' to the bed.

My hotend is controlled similarly- I have a 24V buck converter feeding an external MOSFET unit.

I am considering the DSO138 mini-scope from JYTech /Banggood? It seems to be well regarded for what it is, and I think will suffice for this and other light duty applications.

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.

This is the only reasonable thing I found so far - [duet3d.dozuki.com]

3. RRF v3: I am very interested in upgrading. The thing that keeps me from doing so is having a self-built printer that seems to have random issues that I do not want to set myself up for failure fighting random grrmlins. I was planning on doing so once I got a stable printer and config.

sinneD
Re: LPC port of RepRapFirmware
October 27, 2019 11:55PM
Quote
sinned

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 PanelDue?

I just did some experiments with resistors to simulate some temp faults, and temps not falling/rising as predicted and excursion errors were all displayed in DWC (version 2 used in testing) with an alert at the bottom (that requires manual dismissal) as well as a big popup saying that the print had been paused. It also shows fault under the Heater in the tools section too. The console also shows a log of all the errors as well.

There is debugging for the Heat module (M111 P5 S1 that will print over USB connection) but all the errors that were printed there were also displayed within DWC as well.

I used the default 5seconds before a fault is triggered, and 15deg excursion. 3 second fault did not trigger a heater fault as expected. 5 seconds the popups appeared and the print was also automatically paused. Everything seems to be working and reported as expected.



Edit: (BTW ignore the blue line in the graph, that input was left "floating" and was influenced by the value of the pin next to it)

In my opinion the defaults in M570 are already quite generous, so if you have a fault that's triggering it then best bet is to track down the fault/source of interference.

Edited 1 time(s). Last edit at 10/28/2019 12:32AM by sdavi.
Re: LPC port of RepRapFirmware
November 02, 2019 11:51PM
Changes from RRF v2.04 have been merged into the LPC port. Updated binary can be downloaded here: [github.com]

This is likely the final update for the RepRapFirmware Version 2 series.
Re: LPC port of RepRapFirmware
November 04, 2019 11:25AM
Just installed it on the MKS S base. So far so good.

I never experienced any issue with T° spikes as described above but never paid attention either. This time I looked and can confirm that on Pronterface, no T° spikes for the hot end (230° PID 12V 40W) or the bed (60° bang bang 12V 100W), idling, X Y moving (Gcode to move in X Y quite violently) or printing.

Edited 2 time(s). Last edit at 11/04/2019 11:31AM by MKSA.


"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)
Re: LPC port of RepRapFirmware
November 05, 2019 12:10AM
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 using when using a 1K sdcard file write buffer and the 2K SPI transfer rx/tx buffers. So far seems to be running quite well.
Re: LPC port of RepRapFirmware
November 05, 2019 07:09PM
Interesting... my temperature fluctuations have been dips, not spikes.



On a SKR 1.3, with the RRFv2 build. The larger dip ended right as the screenshot was taken.
---

Since there's no software uart, I swapped out my tmc2208s for tmc2209s to use pressure advance. Dunno how they'd handle a large M572 Snn value in standalone mode, but they work well enough for the tiny ones my titan aero uses.

Edited 2 time(s). Last edit at 11/05/2019 07:13PM by keifermiller.
Sorry, only registered users may post in this forum.

Click here to login