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.

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.

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], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

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.

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

I can't see any spikes on my dev board. Watching the numbers it only varies by 0.1 deg.

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.

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.

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)

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.

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)

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

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.

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.

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)

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.

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.

original post/thread is here- [forum.duet3d.com]

i stuck an ammeter inline to try and see what is going on.

i am getting random 'Heater Fault" reporting. It does not show up on the GCode console. the print does not pause either- the heaters are still on and the print is still going.





the false positive is just as bad as a real one in my mind.

Is this a RRF issue or LPC port issue?

here is M122 output -

12:15:20 AMM122
=== Diagnostics ===
RepRapFirmware for LPC176x based Boards version 2.04RC1 running on LPC176x at 100Mhz
Used output buffers: 4 of 16 (13 max)
=== RTOS ===
Static ram: 2940
Dynamic ram: 29192 of which 0 recycled
Exception stack ram used: 392
Never used ram: 212
Main SRAM : 32524/32768 (244 free, 212 never used)
RTOS Dynamic Heap : 40384/46720 (6336 free, 5792 never used)
=== LPC PWM ===
HWPWM:250Hz T1:10Hz T2:0Hz T3:250Hz
Tasks: EMAC(blocked,44) NETWORK(ready,460) IP-task(blocked,64) HEAT(blocked,928) MAIN(running,2268) IDLE(ready,164)
Owned mutexes:
=== Platform ===
Last reset 133:53:26 ago, cause: [reset button][software]
Flash Slot[34]:
Last software reset at 2019-11-14 00:23, reason: User, spinning module GCodes, available RAM 248 bytes (slot 0)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0xe000ed38 SP 0x00000000 Task 0x2007cfc0
Stack: 00000000 00000002 0001860d 20080110 2007ff90 00000000 10003410 10004258 10003450 00000001 000187a7 00000000 10003410 10003b30 00000050 00000007 10003b30 10003410 2007eb94 00000001 a5a5a5a5 000003e7 a5a5a5a5
Error status: 8
Free file entries: 3
SD card 0 detected
SD card longest block write time: 291.8ms, max retries 0
Date/time: 2019-11-26 00:15:30
Slowest loop: 1511.63ms; fastest: 0.06ms
=== Move ===
Hiccups: 0, FreeDm: 92, MinFreeDm: 67, MaxWait: 62600638ms
Bed compensation in use: none, comp offset 0.000
=== DDARing ===
Scheduled moves: 276597, completed moves: 276577, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
=== Heat ===
Bed heaters = 0, chamberHeaters = -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.2
=== GCodes ===
Segments left: 1
Stack records: 2 allocated, 0 in use
Movement lock held by null
http is idle in state(s) 0
file is doing "G1 X158.998 Y182.396 E0.0183" in state(s) 0
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
lcd is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 1715.19ms; fastest: 0.02ms
Responder states: HTTP(2) HTTP(2)
HTTP sessions: 1 of 2
Interface state: active, link 10Mbps half duplex
Socket States: Connected(2ms) Connected(25ms)
NetBuffers: 3 lowest: 0
IP Event Queue lowest: 9
EthDrv: Dropped packets (no buffer): 104

Have you run heater tuning? [duet3d.dozuki.com]

---

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

@sinned your also still running RC1 of 2.04. The latest v2.04 was uploaded earlier this month.

Quote
sdavi
@sinned your also still running RC1 of 2.04. The latest v2.04 was uploaded earlier this month.

@dc42- I have done M303 a couple of times. I was reading the wikipedia page on it too before this happened.

I was actually contemplating going to RRF3 .... I will stay with 2.04 for now I think.

Edited 1 time(s). Last edit at 11/26/2019 01:26PM by sinned.

I am hoping to confirm this- if you are using a board with modular stepper drivers, like A4988 or DRV8825's, there is no need for using the M906 command to define motor or idle currents.

M906 X800 Y800 Z800 E800 I30 ; set motor currents (mA) and motor idle factor in per cent

thanks in advance

Quote
sinned
I am hoping to confirm this- if you are using a board with modular stepper drivers, like A4988 or DRV8825's, there is no need for using the M906 command to define motor or idle currents.

M906 X800 Y800 Z800 E800 I30 ; set motor currents (mA) and motor idle factor in per cent

thanks in advance

Yep, current control will only work on those boards with built-in digipots and also having stepper.hasDriverCurrentControl = true in board.txt. If stepper.hasDriverCurrentControl = false then it has no effect.

Updated binary to RRF 2.05RC2 (download from the releases page): [github.com]

Also included is the latest version of DWC for those using DWC2.

Quote
sdavi
Updated binary to RRF 2.05RC2 (download from the releases page): [github.com]

Also included is the latest version of DWC for those using DWC2.

That was quick!

---

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

Updated binary to RRF v2.05. Download here: [github.com]

Yay-Thank You!

Just wondering how many are we, using this firmware ?

It is so quiet here. I am a bit bored, no problem.

---

"A comical prototype doesn't mean a dumb idea is possible" (Thunderf00t)

Quote
MKSA
Just wondering how many are we, using this firmware ?

It is so quiet here. I am a bit bored, no problem.

I'm not sure how many are using the LPC port, but I can get the download stats from github since I've started using the github releases:

v2.04 - 21
v2.05RC2 - 5
v2.05 - 7

BigTreeTech released the SKR 1.4/Pro/Turbo whatever with the 1769 chip and apparently all the pins available on the board. Good news for connecting other drives and Ethernet.

They have a Fb site- though its dominated by Ender/BL Touch/Marlin queries.

I considered ordering one to play with for giggles- they are ~$20. I was thinking to do it with RRF3.

Thoughts anyone?