RepRapFirmware.h has references to Roland.h and a type defined by it. However, Roland.h appears nowhere in the repository.

After updating to v1.14 I frequently get disconnects. Whenever I restart the printer I'll also need to reboot my router (hooked up as a bridge) to be able to access the web interface. Whenever my printer is done printing and if I leave it alone for a while it will also disconnect from the router.

Here are my network setttings:

M552 P192.168.1.10 ; IP address (0 = use DHCP)
M554 P192.168.1.195 ; Gateway
M553 P255.255.255.0 ; Netmask

I recently updated to 1.09r on my fisher-beta printer and hadn't spotted that the motor directions were reversed between fisher-beta and fisher-1. The first attempt at homing was a disastrous high-speed crash of the hot end and effector into the bed, resulting in a couple of broken (delta, not human) arms. I would dearly love to save other people and their printers from the same fate.

It strikes me that there is no reason that the bed probe should ever be activated during homing and that there's a good chance that the effector would be central enough on homing that the bed probe would be activated if the motors all went in the wrong direction.

There's probably not much that can be done in the scenario where the motors are going in different directions, but that's less likely to occur after a firmware update - it should be caught in the original commissioning where you're more likely to expect this sort of problem and take precautions.

So I'd like to request a feature that if the bed probe is activated at any time during homing, the homing process be immediately aborted and all motion to cease.

It may also be useful for the bed probe to cause the printing to stop during a normal print in order to catch other problems, but I'm less confident that it wouldn't be falsely triggered during normal printing. At the very least that would need to be an option that can be turned off.

When the printer is idle, don't throttle uploads so large files can be uploaded quickly.

When the printer is running, throttle uploads aggressively so printing performance is not impacted.

hi , I was wondering if this firmware have capability to control the ready to use cutting modules such as auto focus laser head or plasma THC ,
I saw couple of effort on Marlin enthusiast to check output sensor the cutting tool and control the stepper motor the module to control height during the printing
any comments really appreciated

Seems like there is something wrong with the layer counter in the web GUI, it stops at 2 every time. Percentage works though.
Running 1.09r

I believe there is still a problem with M207. When I had everything properly calibrated with M207 turned off the first layer height was being set correctly after G32. As soon as I enabled firmware retraction (M207) the first layer is very thin. Either I am doing something wrong or there is a bug there somewhere.

BTW how does one set the IR probe trigger height? Before calibration or after calibration? I do it after running G32. I lower the nozzle until it just grips the paper. Then -
G92 Z0
G1 Z5
G30 S-1
G1 Z5
G30 S-1
G1 Z5
G30 S-1
Then I average out the results and enter it in config.g G31. I restart the printer and run G32 again.
I also run G32 (6 factor, 13 points) before every print.

Here is my config.g
`; $Id: config.g 243 2016-03-29 12:16:59Z yoorek $
;
; Configuration file for yOOrek's Delta printer
;
; Communication and general
;
M111 S0 ; Debug off
M550 PyOOrek's Delta ; Machine name and Netbios name (can be anything you like)
M551 Preprap ; Machine password (used for FTP)
;
; Network
;
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC address
M552 P10.0.1.17 ; IP address (0 = use DHCP)
M554 P10.0.1.1 ; Gateway
M553 P255.255.255.0 ; Netmask
;
M555 P5 ; Set output to look like Repetier (Marlin - P2)
M575 P1 B57600 S1 ; Comms parameters for PanelDue
;
G21 ; Work in millimetres
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
;
; Axis and motor configuration
;
M569 P0 S1 ; Drive 0 goes forwards (X)
M569 P1 S1 ; Drive 1 goes forwards (Y)
M569 P2 S1 ; Drive 2 goes forwards (Z)
M569 P3 S0 ; Drive 3 goes forwards (extruder 0)
M569 P4 S0 ; Drive 4 goes forwards (extruder 1)
M574 X2 Y2 Z2 S1 ; set endstop configuration (all endstops at high end, active high)
;
;* The homed height is deliberately set too high in the following - you will adjust it during calibration
;
M665 R160.30 L370.00 B148.00 H431.62 X-0.13 Y0.26 Z0.00 ; set delta radius, diagonal rod length, printable radius and homed height
M666 X-0.19 Y-0.30 Z0.49 ; put your endstop adjustments here, or let auto calibration find them
M92 X200 Y200 Z200 ; Set axis steps/mm
M906 X1650 Y1650 Z1650 E1200 I60 ; Set motor currents (mA) and increase idle current to 60%
M201 X2500 Y2500 Z2500 E2500 ; Accelerations (mm/s^2)
M203 X18000 Y18000 Z18000 E18000 ; Maximum speeds (mm/min)
M566 X500 Y500 Z500 E3000 ; Maximum instant speed changes mm/minute (jerk speeds)
;
; Thermistors
;* If you have a Duet board stickered "4.7K", change R1000 to R4700 to the following M305 commands
;
; P0 - bed thermistor
;
M305 P0 T100000 B3950 R4700 H22 L0 ; Put your own H and/or L values here to set the bed thermistor ADC correction
;
; P1 - first nozzle thermistor (E3D V6). David recommends B4388 instead of B4267 stated by e3d people.
;
M305 P1 T100000 B4267 R4700 H22 L76 ; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
;
; P2 - second nozzle thermistor
;
;M305 P2 T100000 B3974 R4700 H30 L0 ; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
;
M570 S180 ; After a heater has been switched on, wait 180 sec for it to get close to set temperature.
; If it takes longer than this, flag a heater fault.

M143 S275 ; Set the maximum temp. of the hot-end to 275°C to prevent damage
;
; Tool definitions
;
M563 P0 D0 H1 ; Define tool 0 (first extruder & hot end)
G10 P0 S0 R50 ; Set tool 0 operating(S) and standby(R) temperatures
; P - tool number
; X - X offset
; Y - Y offset
; S - active temperature
; R - standby temperature
;
; If you have a dual-nozzle build, un-comment the next 2 lines
;
;M563 P1 D1 H2 ; Define tool 1
;G10 P1 S0 R50 ; Set tool 1 operating and standby temperatures
;
M92 E465.11:465.11 ; Set extruder steps per mm (for two BondTechs)
;
;M207 S8.0 R0.000 F4500 Z0.500 ; Hardware retraction
; S - positive length to retract in mm
; R - positive additional length to un-retract, in mm
; F - feedrate in mm/min
; Z - additional z-lift/hop
;
M572 P0 S0.10 ; Set tool 1 elasticity compensation (in seconds)
;M572 P1 S0.10 ; Set tool 2 elasticity compensation (in seconds)
;
; Z probe and compensation definition
;
; If you have an IR z-probe instead of a switch, change P4 to P1 in the following M558 command
;
M558 P1 X0 Y0 Z0 H3 F450 T8000 ; Z-probe is a switch and is not used for homing any axes
; Fnnn - Feed rate (probing speed)
; Tnnn - Travel speed to probe points

G31 X0 Y0 Z1.28 P500 ; Set the z-probe height and threshold
; If the first layer is too thin then decrease the Z value
; If the first layer is too high then increase the Z value
;
;*** If you are using axis compensation, put the figures in the following command
;
;M556 S78 X0 Y0 Z0 ; Axis compensation here
M404 N1.75 D0.4 ; Set filament diameter and nozzle size (machine default, gcode should adjust it)
M208 S1 Z-0.2 ; set minimum Z
T0 ; select first hot end`

This is something Marlin has which is pretty nice.

First I want to define a minimal value a fan has to have to run reliable without having to take care of that in the slicer.
So for example my fan runs at S30 reliable which is about 11% I wanna be able to tell that the firmware so even if I send M106 S15 the fan runs at least at S30. So everything from S1 to S30 will be S30.

Second my fan does not run if I just set it to 20%, it needs a "blip". In Marlin I can set that the fan should run at 100% for some milliseconds when it is powered the first time.
S3D has such an option to do it with Gcode but I don't like that option because it sets the fan to 100% and then waits for 500ms which stops all movements and that results in blobs and melts on the print...

M36 doesn't seem to work from a Telnet connection. There's no response, and Telnet commands stop working completely until I restart the Duet board. The same command works fine in the web G-code console.

M36 /gcodes/foobar.gcode

Firmware version: 1.10+4 (2016-03-30)

Hi David,

As I am using my newly built delta more and more I find that it would be useful to display alongside each uploaded gcode file its last printed time, number of times the file has been printed and actual print duration.
Would this be possible? I don't know if Duet has a notion of current date and time.

On firmware version 1.11 with no tool selected, requesting a print causes the network interface to crash/become unresponsive (Using Ormerod).

Steps to reproduce (From web interface):
Request a print
Click pause
Click cancel (At this point, no tool is selected and the bed is Off)
Without re-enabling any tools, request another print.
The network interface is now shut down/crashed and will not recover without the power being cycled/reset.

The firmware still executes the print/queued commands just fine, but the network is now gone.

When printing G-code with non-relative extrusion distances, some features like filament usage and estimated time left based on filament usage, stop working properly. Filament usage works for a while, but resets periodically, presumably because the G-code uses G92 E0 before every layer change. This also causes the web interface progress bar to stop working, because it uses the used filament length. timesLeft.filament in /rr_status is always zero.

These things should either be fixed (or absolute extrusion be declared unsupported).

Tested using Slic3r 1.2.9 with a Kossel Mini (T3P3 R3).

Here's the same print with both absolute and relative extrusion distances: example_absolute+relative.zip

I just started using the Duet Wifi and have a question about the M109 and M190 commands.
The Reprep Gcode page states that those are command toi heat and wait for the temp to be reached and that Marlin for example has the additional parameter "R" to wait for cooling down too.
So I found that RRF also wait for cooldowns when I specified just "S".
I thought that in RRF M116 was for waiting on cooldowns...

Hi!

Sorry if I'm asking for something that already exists or asking for it in the wrong place. I have some experience with Marlin firmware but none with Reprapfirmware.

I have a custom made cartesian 3D printer with 2 independent carriage extruders along the X-axis. For some reasons, the electronics I'm using now is on its limits (in terms of CPU speed, it is a 16MHz Megatronics V3.0) and I am considering moving to the Duet.

I would like to know if the use of independent X-axis with the Duet is an option in the firmware and if not if it would be very difficult to implement.

Marlin firmware has it implemented and from my understanding, what it does is that, when there is a tool change, it changes the X-axis pins (motor and end-stop) to the ones used to move the second extruder.

Thanks in advance

Hi, could/should I upgrade my ormerod 1 with dual color extension
FIRMWARE_VERSION:1.09 ELECTRONICS:Duet (+ Extension) DATE:2015-04-21

to this firmware?

While there are many new methods to do contactless Z probing now, I still prefer the reliability and simplicity of my gravity based IR probe. I currently get deviations of 0.002 with this probe.

My probe uses a micro 3.3v hobby servo like the ones used on a nano sized heli to hold the probe up when not in use. I currently have to deploy/retract it manually which is a real pain.

I'm looking at adding M280 to the firmware and hijacking the Fan1 code since I don't currently use it on this printer.

When a print is canceled either from the web interface or PanelDue, stop.g is not run.

Hello,
Marco Antonini from 3D Artists did a port for the Alligator Board with you Reprap Firmware 1.09h-dc42 a long Time ago. My Question is your current Version of Reprap Firmware compatible to the Alligator Board or can you make an compatible Version ?

I like the Firmware, because i only need to configure the Printer over the SD Card, not flashing the Board for changes in the Firmware everytime :-)

Greetings

Ability to measure multiple points on the bed to account for an unflat surface. similar to the mesh/matrix levelling features being developed for Marlin. this isnt the same as standard ABL where its just a plane. but its a mesh of points. 5x5 grid to detect peaks and valleys on the bed

After updating to 1.09x-beta3 (why no dc42 in the name btw) I noticed that the LED on the sensor board is not working during G32.
It seems to work otherwise. After the machine is powered up it blinks. When I put a piece of paper close to the sensor board the LED will light up as expected. During print it does blink as before. Only during the calibration (G32) it remains off.
Is this intentional? I thing it should be blinking when it approaches the bed. The calibration is being done as before. I know this is beta version, but so far no-one has reported this (AFAIK).

Also, just noticed that when the sensor is high up in the air (i.e. when machine is homed) the probe reads around 99. I just read the original notes from the blog and it is stated there that the probe should be reading 0.

"Babystepping", as implemented by Marlin firmware, allows fine adjustment to the machine's position in realtime, during printing, through a control knob. Among other uses, this can enable minor corrections to first-layer alignment by adjusting the Z-axis.

Similar functionality, perhaps in the form of a g-code that could be called by macro from the PanelDue, would bring similar functionality to the Duet platform.

Hey,
First of all, really great job! I just get my Duet Wifi for some weeks, no way that I come back on Rumba...

As I see that you're right now working on temperature stuffs, I would be pleased to get a M143 with more functions.
Ok, both of my Hot End are the same, and I guess it's like this in most of the cases, but what I would like is to be able to set a maximum temperature to any temperature sensor connected.

My printer is in a chamber, and for instance, if the temperature at this sensor exceed 80°C, that will just mean something goes wrong.
I guess setting such limit on the Bed could make sense as well.
I was also thinking about putting a second thermistor on the heat sink of the Hot End, this could both prevent fan and primary thermistor failure, but for this second point the firmware seems to have already a lot of nice protections, so maybe this is just paranoia...

To go further, it would be really nice also if any of theses emergency stop (actioned by the firmware itself) could lead to a warning, the most adaptive could be a "emergency_stop.g" script, then M42, latching relay and buzzer would make it. (It's seems that the PanelDue have a buzzer, but I don't have £60 for this, especially since you can get an Android tablet second hand three time cheaper).

I can hardly program but let me know for testing.

I was also looking for a M460 but I just realized that M106 can do it. I'll ask for a wiki account to put a reference there.

I can't find the file "core.h".
Can you help me.thanks.

rr_status intermittently reported inf for timesLeft.filament. This causes the web interface to fail to load.

"timesLeft":{
    "file":0.0,
    "filament":inf,
    "layer":135.4
}

This is very similar to the bug I reported in December here: http://forums.reprap.org/read.php?146,594372,594372#msg-594372

Firmware version: 1.09r-dc42 (2016-01-16)

Perhaps it's time to feed numbers through a function to make sure they're not infinite/NaN (and fall back to something parseable) before printing them as JSON :-)

Hi,

I want to remap one of my axis drivers to the expansion header and reprap wiki lists:
"M584: Set drive mapping NEW (1.14) Was handled by M569 before."
Is this fork also using the new M584 to do this?

Cheers

Having the new Pins_duet.h file declare global variables causes problems as that header file needs to be included into multiple source files. Either that, or the declaration of global variables needs to be guarded by an #ifdef so that only when it is included in Platform.cpp are the globals declared.

For example, the MAX31855 support needs to include it to get info about the pins associated with the MAX31855 chips. On Radds, it needs to be included by the SD card support for info on the SD card pins. Etc.

dc42,

Your build instructions say to build the CoreDuet project first in the same workspace. What is the purpose?

I'm just getting started on the port so any tips would be greatly appreciated. I plan to build your code as-is this weekend before I start hacking on it. The controller is going in a Kossel Mini and I like the way you are handling the Deltas so I would like to use your firmware on my hacked RAMPs controller. I'm just using up some bits I found laying around on my bench to get ARM horsepower for my new Delta.

I don't want to distract you away from this awesome work. If you have no interest in my project just close this issue and I won't bother you any more. I'll figure it out, but I'll do it faster with a little help TIA.

It'd be nice to have a non-logged in user able to see the printer's current status, but lock out all controls. In several use cases, many people are going to want to be able to check if the printer is free or how long the current print will take from their desk, but you wouldn't necessarily want everyone to have the ability to control the printer through the web interface.

I have a Kossel with a very weak bed heater. When I'm trying to print I get the following error string:

Error: heating fault on heater 0, temperature rising much more slowly than the expected 0.0°C/sec

I suspect 0.0°C/sec is a truncated value and the measured value gets truncated to exactly 0.0°C/sec and triggering the heating fault. I can clear the error with M562 P0 but it keeps triggering as it heats up which gets very tedious and so far I have been unable to reach the target bed temperature of 100°C for my particular blend of ABS.

Is there any way to disable fault checking for a specific heater? If not, may I suggest adding an extra parameter to M562 for doing so?

Edit:
As mentioned in the title I have tried with tuned values, I have also tried the legacy values which worked just fine in RRF 1.11 with the same result.

I'm running 1.13b1, and sometimes extrusion stops working. The motor doesn't move and no error is printed. It has happened three times now, but I'm not sure how to reproduce it. A reboot fixes it.

Diagnostics
Used output buffers: 4 of 32 (28 max)
Platform Diagnostics:
Memory usage:
Program static ram used: 45208
Dynamic ram used: 40440
Recycled dynamic ram: 368
Current stack ram used: 2728
Maximum stack ram used: 6652
Never used ram: 5636
Last reset 17:24:50 ago, cause: software
Last software reset code & available RAM: 0x0003, 6644
Spinning module during software reset: GCodes
Error status: 0
Bed probe heights: -0.203 -0.092 0.081 -0.139 0.157 -0.109 -0.061 0.063 -0.177 0.017 0.000 0.000 0.000 0.000 0.000 0.000
Free file entries: 10
Longest block write time: 124.3ms
SD card speed: 0.2MHz
Slowest main loop (seconds): 0.206177; fastest: 0.000000
Move Diagnostics:
MaxReps: 6, StepErrors: 0. Underruns: 163
Heat Diagnostics:
Heater 0: I-accumulator = 0.0
Heater 1: I-accumulator = 0.0
GCodes Diagnostics:
Move available? no
Stack pointer: 0 of 5
macro is idle
http is ready with "M122"
telnet is idle
serial is idle
aux is idle
file is idle
Network Diagnostics:
Free connections: 14 of 16
Free transactions: 22 of 24
Webserver Diagnostics:
HTTP sessions: 1 of 8
FTP connections: 2, state 0
Telnet connections: 1, state 3

The sheer number of these messages renders the interface unusable. I understand the the error message is harmless but it is really bothersome.

Is there any way to disable this error message?

I have tested my firmware config with both M572 activated and deactivated, it seems to cause steps to be lost in the XY when turned on.

Please let me know if I can send any info to help diagnose the problem. I am using this line:

M572 D0 S0.1 ; compensate for springiness

Are there any plans to add support for multiple drives per axis?
I am asking because the Duet only has one socket for the Z-axis which often requires 2, if you don't want to solder 2 motor leads together.

I will be implementing this locally.

Some kind of "jerk" parameter, adjusting the smoothing between velocity changes, may improve print quality in some cases.

Theoretically, this might be implemented as a limit on the rate of change in acceleration (ie. jerk), just as acceleration is the rate of change in speed.

For TazMega, the threaded rod drive can couple extreme instantaneous force into the workpiece and toolheads. Even with 24 V-Slot wheels, this seems to cause the bed to bounce vertically when suddenly reversing direction. This may be contributing to front and back areas of printed parts showing gaps, as well as rough layers at heights above two centimeters.

Please consider adding some more tuning knobs to manage acceleration parameters.

Messages sent by the PanelDue on the aux serial port show up in debugging output on the USB serial port. However, responses generally do not seem to be sent to the same. Additionally, messages sent on the PanelDue console "M114" do not show up on the same. Only the "Connecting.../Idle" and uptime information seems to reach the PanelDue.

Oscilloscope probing seems to confirm this, showing messages on the blue, but not green, wire. SImilarly, disconnecting the green wire still allows the PanelDue to send messages, but not receive any status updates, including "Connecting.../Idle" or uptime.

Is there some g-code needed for configuring this with the new firmware? For diagnostic use, being able to send abritrary messages to arbitrary serial ports would also be useful.

When the config.g cannot be accessed, the firmware still runs using compile-time defaults. For the network, the default IP address is 192.168.1.10. Might it make more sense to instead use 0.0.0.0 as the default IP address and thus kick the network stack into attempting to use DHCP to get a more-likely-to-be-useful IP address?

Impacted file would be Network.h

I've seen several printers lately running dual X-carriages (mainly https://www.bcn3dtechnologies.com/en/catalog/bcn3d-sigma/). Advantages include no drooping from the inactive extruder and no dragging the inactive extruder on the print due to slight height differences. We would need additional drive electronics but the expansion header could easily be leveraged.

EDIT: Just realized that this was briefly discussed in a previous issue (#38).

Hi,

I'm running v1.11-ch.

Once I missed L option for M665 command line in config.g. Then I uploaded it using DWC.
When I executed G28, the nozzle was heading towards extreme side. It crashed into the side pannel.
GCode console didn't leave any error message. After reloading config.g, reset, power cycle, the symtom wouldn't go away.

Out of frustration, I ran M665 without any parameter.
It reported 'Printer is not Delta mode.' It's unexpected behavior IMHO.

Does newer version provide alternative way of setting printer type permanently like Marlin?

Regards,

I tried to find info on this with google, I know it must have been addressed before, but I could not find anything.

My PanelDue is locked in the the new Version. Tapping on the screen is doing nothing. All Values are ok and are updatet, but if you klick on a button nothing happens. Like it´s locked.
Did a reset of the Panel and it was going to the print screen, but you cant click. Every time I do a reset it´s going back to the print screen updating all values correctly but the buttons are locked.

SamNonDuePin.h no longer defines the extended pins X0, X1, X5, X7, etc. However, they are still used.

Moreover, their definition does not appear in any header file. Here's a search across a fresh copy of the dev repo,

% find . -name .h | xargs -n1 grep -l X1
./Libraries/EMAC/mini_ip.h
./Libraries/Lwip/lwip/src/sam/include/arch/cc.h
./src/Pins_duet.h
./src/Platform.h

% grep X1 Libraries/EMAC/mini_ip.h
/* 0X14 through 0x1D Reserved for robustness experiment */

% grep X1 Libraries/Lwip/lwip/src/sam/include/arch/cc.h

define X16_F "hx"

% grep X1 src/Pins_duet.h
const Pin ENABLE_PINS[DRIVES] = { 29, 27, X1, X0, 37, X8, 50, 47, X13 };
const Pin STEP_PINS[DRIVES] = { 14, 25, 5, X2, 41, 39, X4, 49, X10 };
const Pin DIRECTION_PINS[DRIVES] = { 15, 26, 4, X3, 35, 53, 51, 48, X11 };
const Pin HEAT_ON_PINS[HEATERS] = { 6, X5, X7, 7, 8, 9, -1 }; // Heater Channel 7 (pin X17) is shared with Fan1. Only define 1 or the other
const Pin Z_PROBE_MOD_PIN07 = X12; // Digital pin number to turn the IR LED on (high) or off (low) on Duet v0.7 and v0.8.5 (PC10)
const Pin COOLING_FAN_PINS[NUM_FANS] = { X6, X17 }; // Pin D34 is PWM capable but not an Arduino PWM pin - use X6 instead

% grep X1 src/Platform.h
// initialized until configured via a "M305 Pn X10m" command with 0 <= n < HEATERS

This is just a suggestion.

The name RepRapFirmware is really hard to get useful information about. There is definitely tons of information out there about the project, but search engines seems to think I am searching for general RepRap project information about Firmware. Also many people either do not know about it or get confused when I talk about it because they also think I am talking about firmware for the general RepRap project. I cannot tell you how many times in the last few weeks while setting up RRF on my RADDS board I have had people say, "You mean line Marlin or Repetier?" when asked which firmware I am running.

dc42's fork of the RRF from reprappro has clearly become the default version people should use. I think by changing the name of the firmware it will help to differentiate it better from the original firmware and make the project become more recognizable in the community as a whole.

Hi,
I am running 1.09r-dc42 version on my Duet 0.8.5. Ever since I started commissioning my new delta (based on David's blog) I had problems with object height and other information about the file. I guess is must be my gcode. I use Slic3r 1.2.9. In G-code Files the object height is never shown. In print status Layer Time and Last Layer Time are showing as n/a. Layer statistics graph is never updated.

I attach the start.gcode(txt) (first 5 layers) and end.gcode(txt) (last 4 layers) of the file that gives me problems. Actually all my g-code files give me this problem. I had a quick look at the code and it looks like you are searching backwards for 'G1 Z' pattern that is not in the comment. In vi, when I do backward search I do find this pattern without any problems.

Is this a bug or is it something in my generated g-code files?

start.txt
end.txt

It appears that G-code commands that contain an S1 directive are ignored entirely.

For instance, if I run this G-code:

G1 X240 F3000 S1

Absolutely nothing happens.

If I take off the S1, like so:

G1 X240 F3000

It moves X 240 at a rate of F3000 as expected.

This of course makes homing impossible as it requires those commands to stop once hitting the endstop switches. In effect, if I run a homex.g script which looks like this:

G91                ; relative mode
G1 X240 F3000 S1   ; move up to 240mm in the +X direction, stopping if the homing switch is triggered
G1 X-4 F600        ; move slowly 4mm in the -X direction
G1 X10 S1          ; move slowly 10mm in the +X direction, stopping at the homing switch
G90                ; back to absolute mode

It effectively runs this:

G91                ; relative mode
G1 X-4 F600        ; move slowly 4mm in the -X direction
G90                ; back to absolute mode

Let me know if you need any additional information.

Possible theory is it's expecting more data than really exists. My guess is webserver.cpp lines 500-660.

I just switched to the DuetWIFI and am having some major trouble getting the printer to pay nice with my settings. This is to say these settings worked fine on the Duet 0.8.5

At the end of my config.g file I write the setting to EEPROM using M500. If I have my system read back the setting they appear correct, using M503. However if I send to M501 command the setting are changed, the most obvious change is Z prob is wrong but a number of settings are not correct, but when I run M503 it reads back all the correct values. The correct setting seem to load when I send M999.

Crash occurrs when "G30 P3 S0 Z-10000" is executed.Simply reporting the data, without calculating bed compensation, works normally. Executing "G30 P3 S-1 Z-10000" returns valid data - "Bed probe heights: -0.350 -0.387 -0.335 -0.237, mean -0.327, deviation from mean 0.055".

Notably, this did not occurr prior to installing a new tool platform (MightyTool). May be related to the use of positive X/Y coordinate offsets with the differential optical probe - ie. "G31 C0 P500 X40.8 Y8.7 Z0.35", instead of "G31 C0 P500 X0 Y0 Z1.3".

When in simulation mode, G28 seems to be ignored. Thus, if my delta hasn't been homed before simulation, I get the Attempt to move the head of a delta printer before homing the towers error.

I'm guessing 28 should be in the simulation code whitelist in HandleGcode.

Firmware Version: 1.13beta1 (2016-05-27)

Whilst deprecated, there is still code for M27 (SD status) in GCodes.cpp and it appears to be inverted?

case 27: // Report print status - Deprecated
    if (!reprap.GetPrintMonitor()->IsPrinting())
    {
        reply.copy("SD printing.\n");
    }
    else

So if IsPrinting() is false, then the response is "SD printing".

When I use M0 or M1 from Telnet, nothing happens. The print continues, I get no reply, and Telnet functionality doesn't work until I reboot the Duet. Even new connections are non-responsive; the TCP connection opens, but no G-code commands work.

The behavior is similar to #42.

Firmware Version: 1.12a (2016-05-10)