New experimental firmware 1.09a-dc42

I've released version 1.09a-dc42 at [github.com]. As usual, to download it, follow the link to the version you want and then press the Raw button. The changes since 1.04f are:

Quote

Merged in zpl's latest changes to Network and Print Monitor modules. DHCP and Netbios names are now supported (thanks RRP/zpl)
Added command M999 S4321 to unlock flash memory, reset and boot to BOSSA port
Z dive height is now relative to Z probe trigger height and the default is reduced to 3mm. As before, you can use the M558 H parameter to adjust it.
Added experimental support for an acoustic Z probe for delta printers (Z probe type 5)
Bug fix: when using a simple modulated IR probe, very high readings were occasionally read (this fix was in 1.04g which I didn't officially release)
Bug fix: the firmware once again prevents Z homing before X and Y are homed, if the Z probe is used for Z homing
Various code tidying

When I have time, I'll create a document describing the differences between RRP 1.09 and my 1.09; but for now the main additions to my fork that I can think of are:

- Precise stepper motor pulse timing and acceleration limits, which some users have reported as sounding smoother and quieter
- Support for other printer architectures (Delta, CoreXY, CoreXZ, CoreYZ)
- Support for simultaneous XY homing on Cartesian printers
- Support for swapping thermistor channels over
- Configurable Z dive height
- M999 S4321 command, which avoids the need to access the Erase button

If you are switching from my 1.04 series firmware to my 1.09a version on a non-delta printer, you should not need to change any homing files or config.g. The recommended web interface is still DuetWebControl 1.06.

If you are switching from RRP 1.09 to my 1.09a on a Ormerod 1, then you need to add this line to config.g to tell it that the Y endstop is at the high end:

M574 X0 Y2 Z0 S1

You can either keep your existing homing files, or switch to mine to get simultaneous XY homing.

---

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

Good to see you continuing your work on the firmware!

Quote
dc42
- Support for swapping thermistor channels over

You can remove this one from your list though, I merged in your implementation a while ago so it should already be part of the official 1.09 firmware I haven't forgotten about your Move improvements either, it's just the fact that they're quite vast which means I'll definitely need some more time to get them sorted. But I'll gratefully adopt your improvements when I find time, IMO your new move code does run a lot smoother than the old DDA implementation! When I find some more time, I think I will add a facility to utilise your M37 code on the web interface, too.

BTW today I updated my GitHub repo as well in order to provide a boards package for Arduino 1.6.4, however it's rather unfortunate that the current Eclipse plugin still doesn't work with recent Arduino versions (>= 1.6.1). I really hope they will add support for the latest Arduino version sometime soon.

Quote
zombiepantslol
I haven't forgotten about your Move improvements either, it's just the fact that they're quite vast which means I'll definitely need some more time to get them sorted. But I'll gratefully adopt your improvements when I find time, IMO your new move code does run a lot smoother than the old DDA implementation! When I find some more time, I think I will add a facility to utilise your M37 code on the web interface, too.

One stupid question but I am looking in all directions: Can this feature maybe effects the precision especially for printing circles?

I've been using the DC42 firmware (1.04g at the moment) with my Ormerod 2, and I haven't had any difficulties with circles, granted I have yet to try printing a cylinder or something. But I've printed some gears that seemed to work fine.


DC42, did you ever get a chance try and reproduce my M226/M24 pause resume problem?
I haven't had a chance to see if the new 1.09a has this issue or not, but I'll let you know when I get a chance to update the firmware.

Many thanks for the answer. My problem is probably this little rod on the x-carriage. It is a little bit too small. Nevertheless I am going to check this to be 100% sure.

Quote
shadow651
DC42, did you ever get a chance try and reproduce my M226/M24 pause resume problem?
I haven't had a chance to see if the new 1.09a has this issue or not, but I'll let you know when I get a chance to update the firmware.

I'm sorry, I forgot about it. Can you remind me what the problem was?

I did take a look at the code, and it appears that the only difference between M226 and M25 is that M226 waits for all previous moves to complete first - which makes sense, because it is intended to be used within the gcode file being printed.

---

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

Quote
shadow651
DC42, did you ever get a chance try and reproduce my M226/M24 pause resume problem?
I haven't had a chance to see if the new 1.09a has this issue or not, but I'll let you know when I get a chance to update the firmware.

I'm sorry, I forgot about it. Can you remind me what the problem was?

I did take a look at the code, and it appears that the only difference between M226 and M25 is that M226 waits for all previous moves to complete first - which makes sense, because it is intended to be used within the gcode file being printed.

The issue was that M226 seemed to pause fine, but when M24 is sent to resume, the printer tries to go beyond the axis limits, physically hitting the ends. I think it was trying to go X high and Y low but not sure.

It's strange because M25 pause and M24 resume works fine. For whatever reason it seems to not know where it's going for a resume from M226.

Quote
shadow651
The issue was that M226 seemed to pause fine, but when M24 is sent to resume, the printer tries to go beyond the axis limits, physically hitting the ends. I think it was trying to go X high and Y low but not sure.

It's strange because M25 pause and M24 resume works fine. For whatever reason it seems to not know where it's going for a resume from M226.

Thanks, I'll test it later today.

---

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

Hey Dave.

I am planing on upgrading my firmware from current 0.78v to 1.04f. Is there anything else I need to change/add/erase/replace when upgrading? Any new lines to my config.s or can I just upgrade and leave everything as it is?

Quote
Sardi
Hey Dave.

I am planing on upgrading my firmware from current 0.78v to 1.04f. Is there anything else I need to change/add/erase/replace when upgrading? Any new lines to my config.s or can I just upgrade and leave everything as it is?

1. My current release is 1.09a so that's what I suggest you use.

2. If you have an Ormerod 1 then you need to add this line to config.g to tell it that the Y endstop is at the high end:

M574 X0 Y2 Z0 S1

If you are using endstop switches for X and/or Z homing, you will need to make changes to this line. Apart from this, your config and homing files should work OK.

3. You will need to change to my new homeall.g file if/when you want simultaneous X and Y homing.

4. The recommended web interface is zpl's DuetWebControl.

5. RepRapPro changed the standard tool numbering. The new standard is that the first head is tool 0. You don't have to make this change immediately, but once you are settled with 1.09, it's probably a good idea. This affects the M563 and G10 commands in config.g, and the T command in your slic3r start gcode.

6. By default, no tool is selected when the machine start up, so you need to send T0 (or T1 if you are using the old tool numbering) before you can extrude or heat up the hot end.

7. By default, cold extrusion is prevented.

(2) and (3) are specific to my fork, the remainder also apply to RRP 1.09 and zpl 1.08.

HTH David

---

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

Which firmware release introduced the new connection for the distance sensor? And which version needed to turn the X-axis motor?

Quote
Treito
Which firmware release introduced the new connection for the distance sensor? And which version needed to turn the X-axis motor?

0.78 did.

---

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

Okay I was not sure. So he does not have to change something here.

Quote
dc42
5. RepRapPro changed the standard tool numbering. The new standard is that the first head is tool 0. You don't have to make this change immediately, but once you are settled with 1.09, it's probably a good idea. This affects the M563 and G10 commands in config.g, and the T command in your slic3r start gcode.

6. By default, no tool is selected when the machine start up, so you need to send T0 (or T1 if you are using the old tool numbering) before you can extrude or heat up the hot end.

HTH David

So I change the P1 at commands M563 and G10 to P0?
And that also means that I dont have to add T1 manually to my CURA exported g-codes?

Quote
Sardi
So I change the P1 at commands M563 and G10 to P0?

Yes.

Quote
Sardi
And that also means that I dont have to add T1 manually to my CURA exported g-codes?

I suggest you add T0 to your Cura start gcode. My fork also allows you to put a T0 command at the end of config.g. But when a print finishes, the M0 or M1 command will deselect the head and you will need to send T0 manually before you print again, if it isn't included in your start gcode.

Edited 2 time(s). Last edit at 05/25/2015 04:40AM 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].

Cura adds T0 by default. I had to manually change it to T1 since the default tool was 1, now I dont any more.

Thank you Dave, youve been very helpful

"I've updated from an old dc42 firmware (0.x) to 1.04f and 1.09, tested with old and new sys/www folders but I can't connect to the web interface anymore.
The OM1 does work via arduino/serial monitor, I just can't access to web interface."

Fixed... had a problem with the ethernet plug.

Edited 1 time(s). Last edit at 05/31/2015 04:51AM by mirkov.

Quote
mirkov
I've updated from an old dc42 firmware (0.x) to 1.04f and 1.09, tested with old and new sys/www folders but I can't connect to the web interface anymore.
The OM1 does work via arduino/serial monitor, I just can't access to web interface.

oliveD-image mirko$ telnet 10.0.0.5 80
Trying 10.0.0.5...
telnet: connect to address 10.0.0.5: Operation timed out
telnet: Unable to connect to remote host


The web interface worked fine just before updating the firmware and the sdimage. (I have tested with the old folders)
Any ideas?

Two things to check:

1. If you connect Pronterface as soon as you run the printer on or reset it, or alternatively turn the printer on with the network cable disconnected, connect Pronterface, and then connect the network cable, you should see the message "Network up, ip=###". Do you, and it so, it is the IP address you are expecting?

2. Can you ping the printer at the IP address you are expecting?

---

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
Two things to check:

1. If you connect Pronterface as soon as you run the printer on or reset it, or alternatively turn the printer on with the network cable disconnected, connect Pronterface, and then connect the network cable, you should see the message "Network up, ip=###". Do you, and it so, it is the IP address you are expecting?

2. Can you ping the printer at the IP address you are expecting?

I've found the problem. It was the ethernet plug with partially broken secure tab that caused this problem. My fault.

Could you please tell me what's wrong with this code?
I've tested many variants but I only get this:

21:33:03 Error: Attempting to extrude with no tool selected.
21:32:59 Error: Setting temperature: no tool selected.


G21 ; set units to millimeters
M107
M190 S60 ; wait for bed temperature to be reached
M563 S1
T0
M104 S200 ; set temperature
; layer_height = 0.24
G28 Z0
M83

M109 S200 ; wait for temperature to be reached
G90 ; use absolute coordinates
M83 ; use relative distances for extrusion
G1 F3600.000 E-2.40000

Do you have (added) these lines in your config.g?

M563 P0 D0 H1 ; Define tool 1
G10 P0 S0 R0 ; Set tool 1 operating and standby temperatures

Quote
Treito
Do you have (added) these lines in your config.g?

M563 P0 D0 H1 ; Define tool 1
G10 P0 S0 R0 ; Set tool 1 operating and standby temperatures

Yes, I've replaced all the files of my sd card with SD-Image/OM1 found in [github.com] and fixed IP and bed points

Can you please post your config.g?
Can you print the default files like calibration.g?
Besides your M563 looks not that good. You should try to remove.

Here is my start-code from Slic3r:#

;G28 ; home all axes
M83;
G10 P0 S240 R210                       ; Set tool 0 operating and standby temperatures
T0

Quote
mirkov
Could you please tell me what's wrong with this code?
I've tested many variants but I only get this:

21:33:03 Error: Attempting to extrude with no tool selected.
21:32:59 Error: Setting temperature: no tool selected.

Nothing is wrong with your code. The problem is that when slic3r generates a gcode file, it outputs the command to heat up the hot end before it outputs your custom gcode containing the T0 command. Fortunately, it sends another command to heat up the hot end before it starts printing, so the errors don't actually matter.

You can avoid the messages by sending T0 before you print. Using my fork, you can also put T0 at the end of config.g if you like.

---

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

Also, if you use Slic3r's variable names instead of a number, Slic3r does not send its own heater commands prior to your custom start codes. e.g. change your start code to:

G21 ; set units to millimeters
M107
M190 S[first_layer_bed_temperature] ; wait for bed temperature to be reached
M563 S1
T0
M104 S[first_layer_temperature] ; set temperature
; layer_height = 0.24
G28 Z0
M83

Slic3r will replace the square brackets and the variable names inside them with the temperatures you have set under the "Filament settings" tab. Enter the lines exactly as above (with square brackets and underline characters).

Dave

Hello Dave,

good to know. The supported Slic3r settings from Reprap does not support this so maybe someone can check this and change the Github files?

Many thanks,

Sven

Hi Dave,
I'm thinking of getting a second paneldue for my second (smaller) setup but am thinking of a smaller screen for this one, are you still supporting the Itead 3.2 screen? and if you are would something like the link below theoretically work as it uses the same drivers?

(http://www.ebay.co.uk/itm/3-2-TFT-Display-Touch-Panel-PCB-262K-Color-screen-MicroSD-SSD1289-Arduino-TE175-/400916125089?pt=LH_DefaultDomain_3&hash=item5d587695a1)


Thanks

Riz

Quote
mynamesriz
Hi Dave,
I'm thinking of getting a second paneldue for my second (smaller) setup but am thinking of a smaller screen for this one, are you still supporting the Itead 3.2 screen? and if you are would something like the link below theoretically work as it uses the same drivers?

(http://www.ebay.co.uk/itm/3-2-TFT-Display-Touch-Panel-PCB-262K-Color-screen-MicroSD-SSD1289-Arduino-TE175-/400916125089?pt=LH_DefaultDomain_3&hash=item5d587695a1)


Thanks

Riz

The hardware and low level drivers still support the 3.2 inch widescreen display, however I gave up supporting that display in the high-level software because I found it too difficult to get all the information I wanted on the screen. The code for supporting that display is still in the source code, but I am sure that there would be some fields that no longer fit.

The display you linked to is the 3.2 inch non-widescreen version, so is only 320 pixels wide instead of 400. The hardware should drive it, and the low-level drivers for that display are present in the code - currently disabled by some macro definitions, but trivial to re-enable. However, you would need to adjust the field layouts in the software to make the fields fit on the screen.

---

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

OK, thanks for the reply, I really appreciate it.

Riz

Sorry, weak connection somewhere...

Edited 1 time(s). Last edit at 06/04/2015 03:09PM by Treito.