Experimental firmware 0.78a-dc42

I've just released experimental firmware 0.78a-dc42. This is a merge of RRP's 0.78 version with the enhancements from my 0.65 series. I have also added zpl's FTP and Telnet support (not quite his latest version). Please regard this release as experimental. The merge was difficult, and I expect some issues will arise. I recommend that you don't use this version for unattended printing just yet, in case of problems.

The major changes from 0.65 series firmware are the ones implemented by RepRappro in their 0.78 version, namely:

* Multi-extruder support

* Improved movement algorithm, in particular better handling of combined XYZ moves

As well as the improvements and bug fixes from 0.65, I have implemented a few more minor bug fixes, mostly concerning error reporting.

If you are upgrading from 0.65 series firmware, please note the following incompatibilities, which require changes to other parts of the system:

* You must update your config.g file. You no longer need to include the T1 command in it, however you need M563 commands to define your hot ends. See the new config.g file.

* You should add files tpre1.g, tpost1.g and tfree1.g to the /sys directory on the SD card (you can upload these via the web interface). It will work without these, but then you will get error messages reported over the USB connection.

* The Z probe blue wire (and the white wire, if you are using one of my hot end boards) connect to different pins, like this:

pin 2 > ......................... < pin 50
pin 1 > ...................ST.... < pin 49

S is the ZProbe signal output (blue wire, 6th pin from right, bottom row). T is the trigger/modulator input (white wire if you are using one of my hot end boards, 5th pin from right, bottom row).

You can find the binary at [github.com] (follow the link to 0.78a-dc42 and then use the Raw button to download it). The compatible version of the web interface is still 0.95 (same as for my 0.65-dc42 series), available at [github.com]. I will add multi-extruder support to the web interface in a later version, and in preparation for this I have added support in the firmware for this.

A few notes:

* RRP have changed the default speeds and accelerations set in config.sys. I have included these changes in the copy of config.sys in my repository.

* RRP have changed the hot end PID parameters. I'm not sure that they are an improvement on the ones I used in 0.65, but I have given them the benefit of the doubt, so my fork uses the same defaults as theirs. Let me know if you find them better or worse than the old ones.

* The M221 command to set the extruder override factor now takes an optional D parameter for the extruder drive number (as well as the mandatory S parameter). Extruder drives are numbered from 0 as in the M563 command. If no D parameter is given, the first extruder drive is assumed.

* The filament consumption reported by the web interface is now the filament consumption that was requested in the G1 commands in the gcode file executed so far, before adjusting for the extruder override factor set by M221. So if you set an extrusion override factor of 110%, then 10% more filament will have been consumed than the web interface reports. On the other hand, the estimated print end time now remains accurate even when M221 is used.

* I have brought the M111 command into line with RRP's version. This means that webserver debugging can be enabled separately from other debugging. A consequence is that M111 S2 will no longer return the memory usage, last reset reason and other diagnostics. Use M122 to get these instead.

I will post the list of differences between 0.78-dc42 and RRP 0.78 when I have compiled it.

Edited 2 time(s). Last edit at 07/07/2014 04:24PM 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].

Ian
RepRapPro tech support

This is great - thanks for your hard work, David! I'll have a look at merging your changes soon.

When using the new FTP upload function, please compare the file size for any uploaded file just in case it is truncated, especially if the uploaded file is bigger than 1MB. I guess this issue will be fixed in the next firmware release.

The combined efforts of everyone working on the duet/ormerod firmware (Adrian, David and zombiepants are the ones I know of) is nothing but awesome. Spectacular job!

Here as promised is the list of extra features in 0.78a-dc42 compared to RRP 0.78:

* The Duet can serve all the files needed by the web interface.

* The USB port is responsive immediately after power up or reset even when no Ethernet cable is connected.

* Printing doesn't hang if the USB port is disconnected (or attached PC goes to sleep) during a print.

* Long filename support for files on the SD card.

* The limit of 42 files in the list of gcode files on the SD card is removed (but there is still a limit of 2000 characters).

* When pausing a print from SD card, if the printer is executing a 'wait' command such as M116, control is returned to the web interface immediately, without waiting for the command to complete (which could take a long time). If you resume the print, it will resume at the same command.

* A new file upload protocol supports much faster uploading of any type of file via the web interface, without a limit on line length, and with a check that the file length is correct when the upload is complete.

* M80 and M81 ATX power on/off commands are supported.

* M999 software reset command is supported.

* M220 (set speed factor override) and M221 (set extrude factor override) commands are supported, allowing you to adjust speed and extrusion factor while printing.

* M208 command allows you to set axis minimum positions (e.g. a negative x-axis position) as well as maximum positions.

* M122 diagnostics command shows additional parameters such as bed compensation heights, last reset reason, and up-time

* The ADC resolution when measuring temperatures is increased from 10 to 13 (i.e. 12-bit ADC + 1-bit oversampling) to gives increased temperature resolution.

* Thermistor parameters and ADC corrections can be set (M305 command).

* All ADC readings are done in the tick ISR to avoid the processor having to wait for ADC conversions and provide faster thermistor and z-probe response.

* Additional over-temperature protection is done in the tick ISR, and the watchdog timer resets the system if the tick interrupt fails.

* If the processor gets stuck in a spin loop, a software watchdog saves an error code in non-volatile memory and resets the system.

* G1 commands with S1 parameter (i.e. seeking for endstops) do not need to be followed by a G92 command to work properly. When an endstop is hit, the software assumes that the position is the axis minimum or maximum specified by the M208 command.

* Option to invert cooling fan PWM.

* Additional z-probe type 3 is supported, for z-probe boards that incorporate more than one type of z-probe (e.g. my hot end boards).

* Separate G31 parameters can be saved for z-probe types 0, 1/2, and 3.

* Various parameters (G31 values, IP address, MAC address, thermistor parameters, PID parameters) are saved to flash memory (note that these values do not survive a firmware upgrade).

* FTP server supported (thanks zombiepantslol).

* Telnet server supported (thanks zombiepantslol).

* Bug fix: uploading file whose name includes an uppercase G now works. Similarly for setting a machine name containing an uppercase G (M550) or password containing an uppercase G (M551)

* Bug fix: if the machine name in an M550 command is followed by a tab character, then the name is assumed to terminate just before the tab character. Similarly for passwords set using M551.

* Bug fix: setting a machine name that contains a quote or backslash character no longer causes the webserver to return a bad JSON response in response to the rr_name request.

* Bug fix: indentation of multipart messages sent to the USB interface now works properly.

* Bug fix: low-speed printing moves work at the requested speed, provided it is above the minimum speed permitted.


Additional functionality in web interface 0.95 compared to RRP web interface:

* Faster (>6Mbytes/min), more reliable file uploading, with reporting and graceful recovery if an upload fails

* All web files and config files can also be uploaded

* More accurate (usually!) estimate of print completion time, based on filament consumption

* The machine name is displayed

* The filament requirement and object height are fetched automatically from the SD card file being printed, for use in estimating the completion time

* Works with FireFox as well as Chrome

* "Upload & Print" button (replaces direct web print button, uploads to the SD card first for more reliable printing)

* The extruder position box reports total filament extruded, instead of the amount extruded in the last move

* Additional status Halted is shown (if emergency stop has been used) as well as Ready and Active

* The Print Status tab includes slider controls to allow the speed and extrusion factor to be adjusted during printing

Edited 5 time(s). Last edit at 07/07/2014 01:14PM 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].

WOW!!!!! - just read the update and the comparison list.

The improvements are amazing, just about to update.

Thank you to all who contribute in the improvements of ormerod.

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

hi david,


i tried your new firmware 078a but have to roll back to 065.

I have added the new files in the sysfolder, edited my config.g and wired the orginal zprobe blue wire to pin 6.


But the webinterfaces crashes if i want to home my x,y,z axis.

The log shows the message : The webserver pobably broken.....


Here my files, maybe i´ve done a mistake.


Thanks for helping

Quote
dc42

* The Z probe blue wire (and the white wire, if you are using one of my hot end boards) connect to different pins, like this:

pin 2 > ......................... < pin 50
pin 1 > ...................ST.... < pin 49

S is the ZProbe signal output (blue wire, 6th pin from right, bottom row). T is the trigger/modulator input (white wire if you are using one of my hot end boards, 5th pin from right, bottom row).

Just trying to make sure I am understanding the pin changes as the multiple mappings of the pin names can get quite confusing. I think the above piece of text came from the original reprap explanation.

As I understand it sensor input is Arduino A10 which is actually AD12 on the processor and this goes to pin 39 of the 50 way connector which is indeed 6 pins from right. Modulator is Arduino D52 which is PB21/AD14 on the processor which goes to pin 41 of the connector which is 5 pins from right. So that seems to make sense except I don't understand where the pin 50 and pin 49 came from and the S and T somehow got stuck together.

I've put code tags around the diagram now so hopefully it makes more sense in a fixed width font. Each dot represents a pin and so do the S and the T. The 49 and 50 are the end pin numbers in each row.

EDIT: here is a photo:



Edited 2 time(s). Last edit at 07/08/2014 05:02AM 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 I can see now it was supposed to represent the physical connector.

I have done the update now (built from source) and everything seems to function OK including modulated Z probe.

One slight weirdness on mine I noticed is with Y homing. The initial move to the microswitch position was at a normal speed but then the return to home was slower than normal, maybe half the speed. After homing Y speeds then act normally. I checked the homey.g and it looks normal and is the same as on your github. Also Y acceleration and speed settings in config.g are as normal.

Thanks for doing this merge so that we continue to enjoy all the extra improvements you have made.

Edited 1 time(s). Last edit at 07/07/2014 05:36PM by bobtidey.

Hi Bob, the homing files in my github repository are ones from RRP, not the ones I use. I attach the ones that I use. There are 2 main changes:

1. Removed the G92 commands after the homing moves, so that the endstop positions are taken from the axis limits set by the M208 commands (this works with my firmware but not with RRP firmware).

2. The Z homing position is the centre of the bed. I am using a differential IR sensor.

I have also set a specific feed rate on the Y axis return move so that it happens quickly.

Edited 1 time(s). Last edit at 07/07/2014 06:36PM 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].

Quote
muggi
But the webinterfaces crashes if i want to home my x,y,z axis.

The log shows the message : The webserver pobably broken.....

I'm sorry to hear that you are having problems with this firmware. Which log are you referring to? You didn't attach a log file.

---

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

Hi David,

The Message was in the log of the Webbrowser Interface.But i used my old config.g. After reading a lot i try it with the new config today. I will report.....

Edited 1 time(s). Last edit at 07/07/2014 11:53PM by muggi.

Try connecting Pronterface as well. When the web interface freezes, check the Pronterface message log for error messages, and see whether the printer still responds to commands from Pronterface.

---

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

David,
Thank you for the new board. The set up went well, however I am not printing anything because the extruder is not extruding.

In slic3r I commented out T1.

Do I need to put anything else in it's place?

What else could be causing this?

I have M563 P1 D0 H1 in my config file

I also have a problem with the Y0, I am using your home files but when I home y after homing X the bed moves hard right and vibrates because it can not go any further. If I home y a second time the bed moves slowly to the left until the micro switch is activated and then moves to the Y0 position. I am stumped and can not see what could be causing this.

regards Paul

Edited 1 time(s). Last edit at 07/08/2014 10:54AM by appjaws1.

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi Paul, I think you need to leave the T1 command in the slic3r custom gcode. It's the config.g file that RRP removed it from.

In my experience, Y homing problems are usually caused by the wires falling off the microswitch, or being loose. The connectors that RRP supplied with my kit are meant for PCB header pins and don't fit the microswitch tags very well. I am going to solder mine, or find some spade connectors that are a better fit.

---

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

David, Thank you for the reply.

All of the wiring is correct and if I activate the micro switch then the red led in the duet goes out, so the wiring looks to be ok. This has only started happening since I upgraded the firmware and made the alterations to the config and home files
I am attaching the relevant files, would you mind taking a quick look because I'm sure it will be something stupid that I have done.

Thank you
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Paul, is the y-homing problem reproducible? I've just tested it on my system and it all worked:

Power up
Check LEDs, Y endstop light is on because Y axis it not at max travel
Home X using the web server button
Home Y using the web server button - it moves slowly to endstop, then rapidly to Y=0.

I wonder whether you had a dodgy microswitch connection at first, then the vibration caused by the homing failure fixed it? Please try the same sequence. Or, just check that the Y endstop LED is on, then send G1 Y220 S1, which should move the head slowly to the Y endstop.

---

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

David, this is getting stupid.

I thought I had found the problem, I didn't have an M208 X200 Y215 ; Set bed size command in my config. - I have never used this before
So I added it and now when I power up this is the results.
Hot end at Y100 and bed at Y100
Web interface connects and online.
Home X - the x carriage moves up 5mm and then the head moves a very small amount towards the X bearing. - Home X is now blue
Home Y - the x carriage moves up 5mm and the bed rapidly moves to the right, can't go any farther, vibrates then stops. - It did not go in the correct direction towards the micro switch. - Home Y is still yellow.

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

David,
Another thing I have just noticed is that the Z probe readings have 2 numbers i.e. 0(539) 134217724(539) and it is the first part that is going from the high number to 0 whilst the number in brackets is only moving by +-2or3.

I am going to reboot everything and see if that clears this, perhaps the system is totally confused.

I'll let you know.
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Paul, which type of Z probe are you using? You should only get 2 readings if have selected a modulated Z probe where the modulation is controlled by the Duet, which is type 2 in the M558 command. This corresponds to RRP's new z-probe or to my original kit 2 or 3. If you are using my kit 4 or 5, or the new differential IR board, you should set the Z probe type to 1, because the modulation on these probes is controlled by a microcontroller on the board.

Edited 1 time(s). Last edit at 07/08/2014 02:36PM 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].

David you were right, I had P2 in the config file.

Now X does home but Y still goes in the wrong direction, it should go to the left to activate the micro switch but it is travelling to the right and stops and vibrates when it can't go any where else.

I am using your new probe and have made all of the config adjustments and am using your home files so I can't see why my machine should not perform the same as yours.

This is very worrying, I just don't know what to try next

Should I remove the M208 X200 Y215 command and use reprap Home files?

What would cause the bed to move in the wrong direction?

Thanks for your help
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi Paul,

The only thing I know of that causes the Y motor to go in the wrong direction at the start of homing is the microswitch not being connected, or not making contact. The z-probe is not used at all for Y homing. But I can't rule out a firmware problem that affects your machine but not mine.

By all means try using the RRP homing files instead, but I don't expect it to make any difference.

Please try the test I suggested before, i.e. check that the Y endstop LED is lit, then send G1 Y220 S1 to tell the machine to move to the Y endstop.

Edited 1 time(s). Last edit at 07/08/2014 03:31PM 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].

Hello,

with the new firmware I have some trouble with the temperature readings, especially the bed temperature. How can I get the right values for the parameters? I played with them, they seems to be acceptable now, but some form of calculation would be nice. The first time, I had over 180°C bed temperature (according to the readings). But I like the new features. My extruder always was 10° too cold (according to the readings). Now it shows the room temperature after starting.

I'm nearly there.

I have removed the M208 X200 Y215 command and am using the reprap Home files. Now I can home all three axis properly. I still don't understand what I had wrong before.

So it looks like my only problem now is that the extruder is not turning. I thought I had followed the instructions correctly. How do you select the correct extruder?

This is my config file.:-

; Configuration file for RepRap Ormerod
; RepRapPro Ltd
M111 S0 ; Debug off
M550 Pappjaws-Ormerod ; Machine name (can be anything you like)
M551 Preprap ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.1.14 ; IP address
M553 P255.255.255.0 ; Netmask
M554 P192.168.1.1 ; Gateway
M555 P2 ; Set output to look like Marlin
G21 ; Work in millimetres
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
;M208 X200 Y215 ; Set bed size
M906 X900 Y1000 Z900 E800 ; Set motor currents (mA)
M563 P1 D0 H1 ; Define tool 1
G10 P1 S0 R0 ; Set tool 1 operating and standby temperatures
M92 E420 ; Set extruder steps per mm
M558 P1 ; Use an unmodulated Z probe
G31 Z1.6 P500 ; Set the probe height and threshold
M557 P0 X30 Y20 ; Four...
M557 P1 X30 Y180 ; ...probe points...
M557 P2 X210 Y180 ; ...for bed...
M557 P3 X210 Y20 ; ...levelling
M556 S74.5 X-0.56 Y0.18 Z0.267 ; Put your axis compensation here
M201 X800 Y800 Z15 E1000 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600 ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20 ; Minimum speeds mm/minute
M140 R30 ; set bed standby temperature to 30C

Thanks again
Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Paul, here is one of my short test prints. Does it print OK for you? Feel free to edit the bed and extruder temperatures.

I'd still like to know what was the cause of your Y-homing problem, as switching to RRP's homey.g file shouldn't have made any difference. I still suspect an intermittent microswitch connection,

Edited 1 time(s). Last edit at 07/08/2014 04:17PM 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].

David,
I have just noticed that my external fans are permanently on even though the bed and hot end heaters are both off.

Could this be a problem in the firmware?

I'm really having fun today????

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1

Hi Paul,

Is the hot end still warm from a recent print? The fan should cut out when the hot end temperature drops below about 36C, if the thermistor is connected. If the fan is on at a lower temperature, this probably indicates a poor (higher than normal resistance) connection to +3.3V at one end or the other of the 4-way sensor loom connector, or a missing ground connection (but then the z-prove reading will probably be high too).

---

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

David,
I think we were at cross purposes.
The fans I was referring to are the extra fans I have fitted which are controlled via the duet fan connections and controlled by slic3r.

You suspected an intermittent microswitch connection, but I have checked and rechecked, the connections are tight, also I did mention that the x movement was only a few steps in the middle, it did not travel to the homing point.

It is a mystery and was probably a combination of problems by me through out the day.

Things seem to have sorted out now and I am printing my curve test item

I'm still jet lagged so will pick this up again in the morning.

Bye the way, this is the first ever print I have made using automatic bed levelling and Z height setting. --- Thank you, a great improvement.

Paul

---

appjaws - Core XYUV Duet Ethernet Duex5
firmware 3.1.1 Web Interface 3.1.1
Ormerod 1-converted to laser engraver, Duet wifi
OpenSCAD version 2020.07
slic3r-1.3.0, Simplify3D 4.1.2, Cura-4.4.1