Those changes are in file ff.c. I added function isAligned and two calls to it.

---

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

@dc42

Are you still building with Arduino 1.5.8beta? I ask as I did the 1.09r-dc42-radds build with 1.6.4. The underlying gcc-arm toolchains are identical; however, there are changes to the Arduino APIs. Could be something "off" there. So, that's another possibility. (I do apply the assorted patches to the 1.6.4 Arduino APIs.) Right now, I'm behind a very slow net connection so in a bit, I'll do clean pulls of the two git repo's and diff them.

The differences are all benign.

Running the shell script

#!/bin/sh

set -x

mkdir git
cd git
mkdir dc42
mkdir dcnewman

cd dc42
git clone [github.com]
cd RepRapFirmware
git checkout dev

cd ../../dcnewman
git clone [github.com]
cd RepRapFirmware
git checkout dev

cd ../../dc42/RepRapFirmware/Libraries/SD_HSMCI/utility
for F in *.?; do
   diff $F \
	 ../../../../../dcnewman/RepRapFirmware/src/Libraries/SD_HSMCI/utility/$F \
	 > /dev/null
   if [ $? -ne 0 ]; then
     echo $F differs
   fi
done

revealed that only three files contain differences,

compiler.h differs
hsmci.c differs
sd_mmc.c differs

Manually differencing each of those three files shows

1. compiler.h -- A unicode difference in a comment and an #ifdef guard I added to prevent a compiler warning.
2. hsmci.c -- A guard to prevent Duet defs from being defined whilst compiling for RADDS.
3. sd_mmc.c -- Added a function prototype definition, perhaps to prevent a compiler warning.

% diff compiler.h ../../../../../dcnewman/RepRapFirmware/src/Libraries/SD_HSMCI/utility/
161c161,163
< #	undef __always_inline
---
> #	ifdef __always_inline
> #		undef __always_inline
> #	endif
192c194
< #if defined   ( __CC_ARM   ) /* Keil ?Vision 4 */
---
> #if defined   ( __CC_ARM   ) /* Keil µVision 4 */
201c203
< #if defined   ( __CC_ARM   ) /* Keil ?Vision 4 */
---
> #if defined   ( __CC_ARM   ) /* Keil �Vision 4 */

% diff hsmci.c ../../../../../dcnewman/RepRapFirmware/src/Libraries/SD_HSMCI/utility/
0a1
> #if !defined(SD_MMC_SPI_MODE)
911a913
> #endif // !SD_MMC_SPI_MODE

% diff sd_mmc.c ../../../../../dcnewman/RepRapFirmware/src/Libraries/SD_HSMCI/utility/
66a67
> extern void debugPrintf(const char *fmt, ...);

Also, have you tried to see if the SD card can be successfully read at boot time if (1) power is already on and stable, and (2) you press the Due's RESET button? I ask since back a few months, someone else was having a problem with both Repetier and RepRapFirmware on their RADDS 1.5 board. At issue was inadequate voltage stability on the logic rail when power was first switched on. Both firmwares had odd behaviors which went away by pressing the RESET button -- by allowing the firmware to boot up several seconds after power was stable. This doesn't necessarily explain why 1.09k would work and 1.09r wouldn't unless there was just enough of a difference in startup timings to cause a slight delay with when 1.09k accesses the SD card relative to when 1.09r does.

In fact I do all the time press reset after a boot , just to make sure but I dont have to since my rev is the e and that what the e version of due fix . I just came from the shop and I got me 2 new sc card just in case and they dont work in 1.09r

I just read what I did check 2 day ago and you ask me if the firmware hang if there is a config.g but its empty and it do not hang. That for the normal 1.09r I did not test that with the one you send me. I can recheck to make sure later today

Edited 2 time(s). Last edit at 02/25/2016 01:49PM by GroupB.

BTW, I checked and my Due's are rev R3-E (and genuine Due's, not clones).

I just did a build with Arduino 1.5.8beta and it works as well for me,

RepRapFirmware Version 1.09r-dc42 dated 16/02/25

Executing config.g... Done!
RepRapFirmware is up and running.

M115
FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09r-dc42 ELECTRONICS: RADDS 1.5 DATE: 16/02/25
ok

M20
Begin file list
duettest.g
ormaxis.g
snowman.g
square.g
whistle.g
coathook.g
End file list
ok

Care to send me that new compile so I can test it ? Unless is the exact same thing as previous build

I'll send it. However, there's no differences at the RRF source code level. It's just built with the Arduino 1.5.8beta APIs which is, I believe, what dc42 is still using. So, no changes in the firmware. But definite differences in the Arduino APIs. However, whether those differences amount to anything is not clear. The builds with 1.6.5 and 1.5.8beta both work for me.

Dan , the last one you send me don't act like the 2 other, instead of hanging while booting, this one is doing a boot loop every 2 seconds... I can hear the motor doing knock noise every 2 sec. Off course its not letting me connect , but instead of doing a connection then hang while doing baudrate detect like the others, this one connect and pass the baudrate right away and disconnect tell me :

"Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1419"

and when I connect without a card and do a m98 instead of hanging like the other it just go back to boot loop.


I think Im gonna try to remove the radds, hook a sd card reader to the due itself same pin as radds and try that, Unless you sure its not gonna work because some pin need to be pull up or connected on the radds.

My guess is that the firmware is crashing when trying to read and process config.g, and that with the Arduino 1.5.8 core the watchdog is then causing a reset, resulting in the boot loop. With the 1.6.5 core I suspect the watchdog isn't working. The watchdog init code has changed in the Arduino core since 1.5.8, so the patch I did to enable the watchdog may not work with later versions.

Dan, you can test whether the watchdog is working. Sending M122 P1001 will make the firmware hang, which should result in a hardware watchdog reset. Sending M122 P1002 will cause the firmware to go into a spin loop, which should cause the software watchdog to do a reset.

---

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

Afaik in Arduino 1.5.8 watchdog isn't enabled by default. You need to modify a file to use it.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Afaik in Arduino 1.5.8 watchdog isn't enabled by default. You need to modify a file to use it.

The RepRapFirmware build uses patched versions of some of the Arduino core files to add missing functionality, including use of the watchdog with version 1.5.8.

---

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

Where I start if I want to learn to compile my own version of the firmware? is this something anyone can do or its a very special thing ? Do I need to learn C++ or its just copy paste bit of code from left and right ? Say I want to try to compile a 1.09r starting from a k and add one modification at the time to see what wrong, is this something someone can do without spending month of learning ?

Quote
dc42
Dan, you can test whether the watchdog is working. Sending M122 P1001 will make the firmware hang, which should result in a hardware watchdog reset. Sending M122 P1002 will cause the firmware to go into a spin loop, which should cause the software watchdog to do a reset.

• Built with 1.5.8beta, WDT does work.
• Built with 1.6.5, WDT does NOT work.

I've removed the 1.09r-dc42-radds build from repo and put up a 1.09r-dc42-radds-a binary which was built with 1.5.8beta and has a verified working WDT,

... boot ...
RepRapFirmware Version 1.09r-dc42 dated 16/02/26

Executing config.g... Done!
RepRapFirmware is up and running.
M115
FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09r-dc42 ELECTRONICS: RADDS 1.5 DATE: 16/02/26
ok
M122 P1001
ok
RepRapFirmware Version 1.09r-dc42 dated 16/02/26

Executing config.g... Done!
RepRapFirmware is up and running.
M115
FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09r-dc42 ELECTRONICS: RADDS 1.5 DATE: 16/02/26
ok
M122 P1002
o
... about 20 or 21 seconds later...
RepRapFirmware Version 1.09r-dc42 dated 16/02/26

Executing config.g... Done!
RepRapFirmware is up and running.

So, with the behavior seen with a working WDT, my best guess is that the SPI bus isn't stable initially and initializing the SD card is too slow. The SPI code for the SD card does have timeout handling, but the timeouts used are those of the Atmel ASF libraries and may be too long for RRF's use of the WDT.

As an aside, when testing the WDT this way, I have to use the programming USB port for serial comms from my desktop to the Due owing to behavior of the Due's native USB port,

1. When the WDT triggers, the Due's native USB port does some sort of reset killing the connection to the desktop system. From the desktop system, things appear hung since there's no more I/O until the port is closed and re-opened.
2. The act of opening a connection to the Due via the native USB port causes a reset of the SAM3X8E.

The WDT (hardware watchdog) is kicked by the 1ms tick interrupt. So it shouldn't matter how long the SD card takes to initialise, as long as you don't have interrupts disabled while waiting for it. There is a separate software watchdog that will time out if the main spin loop gets stuck, but that has a much longer timeout (20 seconds).

What I find odd is that he can insert the SD card after bootup and run M503, and it successfully reads and echoes the config.g file. But he can't execute it. One difference that may be significant is that M503 does a block read direct into a temporary buffer; whereas when executing the file it is read one character at a time via the buffered I/O code in module FileStore.

---

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
The WDT (hardware watchdog) is kicked by the 1ms tick interrupt. So it shouldn't matter how long the SD card takes to initialise, as long as you don't have interrupts disabled while waiting for it. There is a separate software watchdog that will time out if the main spin loop gets stuck, but that has a much longer timeout (20 seconds).

Code paths are identical for Duet and RADDS here so, if nothing is disabling interrupts for Duet then nothing is for RADDS either. (Indeed, there are no interrupt disables in any of the RADDS-specific code.)

Quote

What I find odd is that he can insert the SD card after bootup and run M503, and it successfully reads and echoes the config.g file. But he can't execute it. One difference that may be significant is that M503 does a block read direct into a temporary buffer; whereas when executing the file it is read one character at a time via the buffered I/O code in module FileStore.

Main difference between the 1.09k build for RADDS and 1.09r is introduction of the DMA support back in p or thereabouts. So, there's a good chance that this is somehow DMA related. But since things work fine for me -- with two different production runs of the RADDS v1.5 boards nonetheless -- I lack a means of reproducing the problem.

I wonder if there might be something in the config.g file which causes an issue. That is, a command which triggers a problem. One could do a divide-and-conquer search and try to identify any troublesome command. Split the file in half, and boot with the first half only. If that works, then boot again with the second half only. Whittle things down until the single troublesome command is identified.

unless you guys see an error in this code... is not a problem of code inside the config. I got the same reset loop with this config, and the same with a stock one taken from the git:

; Configuration file for The Imp

; Communication and general
M111 S0                             ; Debug off
M550 Theimp		        	; Machine name and Netbios

hardware wise, is there something that can cause my problem ? I dont mind testing all the pinout of the due or the radds one by one

Edited 1 time(s). Last edit at 02/26/2016 09:30PM by GroupB.

Quote
GroupB
unless you guys see an error in this code... is not a problem of code inside the config. I got the same reset loop with this config, and the same with a stock one taken from the git:

; Configuration file for The Imp

; Communication and general
M111 S0                             ; Debug off
M550 Theimp		        	; Machine name and Netbios

hardware wise, is there something that can cause my problem ? I dont mind testing all the pinout of the due or the radds one by one

That's what I'm not sure of. I don't use Z probes nor fans with RPM signals on RADDS nor have I tested them on RADDS. I've been using my RADDS boards on a couple of Core-XY (Cartesian) printers.

I only have 3 dvr8825 and 1 a49888 so far , and 3 endstop ( halls sensor using 3.3v,gnd,signal) and im in the process of replacing the sensor they not very good, One thing I saw that I dont like , when the motor work or are on hold my 3v3 look unstable cause my hall report 0.560V at high when they trigger and when the motor are not holding or not working my sensor report the usual 3.3V.

But that wont explain why the K work and not the R

Edited 1 time(s). Last edit at 02/26/2016 09:54PM by GroupB.

Doesn't the M550 Command need a P before the Name such as

M550 PTheimp

Pretty sure it does and maybe that is what is causing the issue


See M550 Command

HTH

Doug

I want to use the RADDS 1.5 with Arduino Due and RADDS LCD only to control and fine tune the hotend of my CNC based printer.
Can anyone tell me the quick way to use these electronics stand alone for this purpose? Which firmware settings are needed beyond heater, thermistor and fans?

You'll need to run the Repetier firmware to do this; RepRapFirmware presently doesn't support the "local" RADDS LCD screen and UI. OTOH, RepRapFirmware supports a much richer touch screen UI which likely can do everything you want and more. (E.g., adjust the printing speed and flow rate whilst a print is running.) The device is called the PanelDue.

Quote
dougal1957
Doesn't the M550 Command need a P before the Name such as

M550 PTheimp

Pretty sure it does and maybe that is what is causing the issue


See M550 Command

HTH

Doug

Good catch!! I post my config already a couple time and even dc42 did not saw it. With the Pname ONLY in the config All version r work ( original, A and

But Dan you did not do that work for nothing... because it like I said early I also test it with stock config like the kossel one in the sd-image of the git and it appear there something wrong in those config file that bug the firmware ( R and up), So I bet the diff between the K that work with stock sd image and R is the watchdog that if read a bad code hang/loop the firmware..

So Dan to reproduce my hang , simply put the stock sd image core or kossel ( I remember I tried a bunch). It maybe was not a problem for you guys that did the full config yourself but only those who start with premade image in the git.

Edited 1 time(s). Last edit at 02/27/2016 05:47PM by GroupB.

Agreed: that was extremely valuable finding that the WDT wasn't working with my builds using Arduino 1.6.5. Had I stuck with 1.5.8beta (and not "gone off the reservation" to use an American phrase), all would have been fine. (As an aside, this is one of the reasons why it was nice back in the day when the Gen 3/Gen 4 RepRap firmware, G3Firmware, jettisoned all use of the Arduino APIs. Those APIs change regularly with no warning and many software projects have been bit by ass't side effects of the changes. Net, net, projects which want to increase their stability either nail down to a specific, qualified Arduino release or remove all dependence upon the Arduino API.

Now, I need to try that command on my Duet and see if it hangs. The gcode processing isn't code unique to the RADDS port: it's the exact same code shared by both Duet and RADDS builds. The specific code for M550 just attempts to print out info when it doesn't see a parameter prefixed with "P" so either that printing at that stage in boot is causing a problem or the more general gcode parser is doing something unwanted with that leading "T" in the machine name.

Okay, I tried

M111 S0
M550 Theimp

in my config.g on my Duet with 1.09r-dc42 and no hang.

"M550" without a "P" parameter attempts to print the name of the printer,

https://github.com/dc42/RepRapFirmware/blob/dev/GCodes.cpp#L3961

That invokes this code,

https://github.com/dc42/RepRapFirmware/blob/dev/Reprap.cpp#L1332

The myName variable is initialized in RepRap::Init(),

https://github.com/dc42/RepRapFirmware/blob/dev/Reprap.cpp#L35

And so, as long as RepRap::Init() was called before the code which executes config.g, then everything is okay and myName is properly initialized. And that is indeed the case: several lines later in that same routine is where config.g gets executed,

https://github.com/dc42/RepRapFirmware/blob/dev/Reprap.cpp#L63

So, I'm not sure what might be up here that it would hang on RADDS and not Duet. In both cases, the primary serial output device is the Native USB port, "SerialUSB". So, if that output of the default device name done when executing M550 is going to the primary serial output device, then that should be the same between Duet and RADDS. Now, if that code is doing something else to output that string, then perhaps there's an issue relating to no network/webservice? The RADDS build #ifdef's out all the web/net related stuff and maybe there's a missing #ifdef somewhere that is triggered by how that output is directed (or directed at boot time)? I certainly do a lot of talking over serial to RADDS and issuing commands like "M550" and the responses work fine for me.

Did you try to load the stock kossel sys/ into your radds, see if this hang also ?

Quote
GroupB
Did you try to load the stock kossel sys/ into your radds, see if this hang also ?

Why would I try that: you cannot use ANY of those example files with RADDS. They all contain commands not supported on the RADDS. Namely commands for configuring a network and, in some cases, commands to set stepper motor currents. Neither of these are supported on RADDS hardware as the hardware lacks ethernet support and lacks means of changing the stepper motor current limits via firmware.

Now, out of curiousity, I did try the file you mentioned. I figured that if your "M550 Theimp" command was causing an issue owing to its generation of output, then those unrecognized commands would do likewise as they will generate an error message. Sure enough, they cause the same issue. Likely because of the error message.

Now, between 1.09k and 1.09r, a fair amount of work was done on that comms code which reports command responses and errors. My guess is that a change there which is causing this issue. It may be a spot where it's trying to report down multiple paths including the network. Or a path impacted by the network code not being initialized. I should have all such paths #ifdef'd out. But something is causing grief.

Can you check this specific code, its my code right now its loop reset by lets me connect then drop 2 sec later, so must be an error near the bottom or something, I dont there there anything duet related, tell me if im wrong

; Configuration file for The Imp

; Communication and general
M111 S0                             ; Debug off
M550 Ptheimp		        	; Machine name and Netbios
M555 P2                         ; Set output to look like Marlin

G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Axis and motor configuration
M569 P0 S0						; Drive 0 goes forwards
M569 P1 S0						; Drive 1 goes forwards
M569 P2 S0						; Drive 2 goes forwards
M569 P3 S0						; Drive 3 goes forwards
M574 X2 Y2 Z2 S0					; set endstop configuration (all endstops at high end, active high)

M665 R174.6 L350.0 B152.0 H256.0		; set delta radius, diagonal rod length, printable radius and homed height
M666 X0 Y0 Z0		; put your endstop adjustments here, or let auto calibration find them
M92 X160 Y160 Z160				; Set axis steps/mm
M201 X1000 Y1000 Z1000 E1000		; Accelerations (mm/s^2)
M203 X20000 Y20000 Z20000 E3600		; Maximum speeds (mm/min)
M566 X1200 Y1200 Z1200 E1200		; Maximum instant speed changes mm/minute

; Thermistors
M305 P0 T100000 B3950 R4700 H0 L0	; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 B3950 R4700 H0 L0	; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
M305 P2 T100000 B3950 R4700 H0 L0	; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
M570 S180				; Hot end may be a little slow to heat up so allow it 180 seconds

; Tool definitions
M563 P0 D0 H1                       ; Define tool 0
G10 P0 S0 R0                        ; Set tool 0 operating and standby temperatures
;*** If you have a dual-nozzle build, un-comment the next 2 lines
;M563 P1 D1 H2                      ; Define tool 1
;G10 P1 S0 R0                       ; Set tool 1 operating and standby temperatures
M92 E663:663                       	; Set extruder steps per mm

; Z probe and compensation definition
M558 P3 X0 Y0 Z0					; Z probe is a switch and is not used for homing any axes
G31 X0 Y0 Z4.80 P500		; Set the zprobe height and threshold (put your own values here)

M556 S78 X0 Y0 Z0                   ; Axis compensation here

M208 S1 Z-0.2						; set minimum Z

T0							; select first hot end

You can comment out sections of lines until it no longer causes a problem. When it ceases to cause an issue, then you've commented out the line(s) causing the problem.

In a couple of days, I'll have time to look and see where in the new error reporting code the problem might be. On RADDS there is no webserver and no tertiary serial device. They are #ifdef'd out. However, it's possible there's code declaring a reporting object for one of those, but it's not being initialized but then used elsewhere in some place which should have been #ifdef'd. Depending upon the nature of the object, there may then be use of an unitialized pointer or other access violation which causes the processor to go off into la la land.

I found and fixed the issue with config.g causing a hang when it generates error responses (or any response which isn't an Ok response). The fix is checked in to the RADDS port. A new build (with 1.5.8beta) is at

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09r-dc42-radds-b.bin

The issue was specific to the RADDS port. It related to there not being network-based reporting paths. I had missed #ifdef'ing out a section. Was easy enough to #ifdef out a couple of enumerations and then let the compiler tell me where all they occurred. (That will also prevent that exact issue from biting again in the future should new code be added using those enum members.)