New experimental firmware 0.78t-dc42

I've just released this at [github.com] (follow the link to 0.78t and then use the Raw button to download). Changes in this release:

Quote

* Nozzle offset setting using G10 is now fully implemented

* Gcode files generated by Simplify3D are now recognised when searching for file info for use by the web interface (thanks zpl)

* Bug fix: Z-homing or bed probing when axis compensation was enabled caused the X and Y axis origins to shift every time you did it.

* Bug fix: M92 command would only set extruder steps/mm if either 1 or 5 colon-separated extruder steps/mm values were provided

* SD Image directory updated to latest web interface

* When drives are disabled (due to executing the M0 or M1 command), the axes are now flagged as not homed

* The movement commands that were previously in the tree1.g and tfree2.g files have been moved to the tpre1.g and tpre2.g files, to work better when G10 nozzle offsets are used

The full list of differences from RRP 0.78c firmware can be found at [github.com].

Things to be aware of when upgrading to this version:

1. If you have a single-nozzle machine, don't use the tpre1.g or tpost1.g files in the SD image in my repository, use empty ones instead (or comment out the commands in them).

2. If you are upgrading from RRP 0.78 (but not 0.78a or 0.78b), you need to reverse the X motor connector on the Duet board (so that the order of the colours is the same as for the other motors).

3. You don't need to change your config.g file if you already have one that works with 0.78 series firmware.

4. You can use either the RRP homing files or mine. The difference is that the RRP ones used G92 commands in the homing files to define where the endstops are, whereas mine use the axis limits set by the M208 commands in config.g. However, my homing files won't work for the Y axis on an Ormerod 2. This is because the Duet firmware (both RRP's and mine) assume that the Y enstop is a high endstop, whereas on the Ormerod 2 it is actually a low endstop.

5. The compatible web interface is version 1.03 1.02, which you can get either from the SD Image directory or from [github.com].

Edited 2 time(s). Last edit at 09/27/2014 07:39AM 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
dc42
* Bug fix: M92 command would only set extruder steps/mm if either 1 or 5 extruder steps/mm was provided

Could you elaborate a bit on this? Would the command only work if the value provided was 1 or 5? The Ormerod extruder drive normally has a value over 400, would that command then just never have had any effect earlier?

Awesome job as usual!

jstk, the M92 command supports multiple extruders using syntax in which the values for different extruders are separated by colon. So an appropriate command for a 2 nozzle system would appear to be 'M92 E420:415'. However, that didn't work. You had to use either M92 E420 (in which case all extruders were assumed to have 420 steps/mm), or supply another 3 dummy values for the other 3 possible extruders supported by the firmware.

---

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

Working great for me - just finished a long print sliced using Simplify3D and all data now showing just as it should on the web interface - nice job both @DC42 & @zpl . One pedantic point - I think the latest version of the web interface is still 1.02 rather than 1.03 isn't it? (and certainly the link at the top of the thread takes you to the github for 1.02...)

Edited 1 time(s). Last edit at 09/27/2014 07:25AM by MrCrispi.

MrCrispi, you are quite right, the web interface version is 1.02.

---

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

Just flashed the new firmware and everything looks good so far. Just fired up a test print so let's see how this works out.

The shifting of X and Y axes did not happen this time. So fingers crossed.

EDIT: Just had the test print fail because the Y-axis did not move at all. I does move at first to home itself and than fail to do any movement at all during the print. even running something like circle.g does the homing ok, moves the X-axis ok but the Y axis not at all.

Looks like there is a problem with the steps per mm for the x axis since the square does move correct in the X-axis and not correct in Y-axis

EDIT2: looks like the Y-axis thing is my fault for having M208 X210 Y28 instead of M208 X210 Y208 in my config.g

Edited 2 time(s). Last edit at 09/27/2014 07:59AM by DasBasti.

This is probably a dome Question, but i am Cur-ease. When i send the command 'M906 E800', and i have the expansion board. Dos it also set the current for the other fore Drive motors on the expansion board ?

oww, sorry. new build appears to be working Grate for me. No bugs so fare, and i have run several prints

Did some test prints and can say it works a treat.

Quote
gdwinslow
This is probably a dome Question, but i am Cur-ease. When i send the command 'M906 E800', and i have the expansion board. Dos it also set the current for the other fore Drive motors on the expansion board ?

Yes it does. To set them individually, use e,g, 'M906 E800:1000:900'. However, I've just checked the code and it has the same bug/feature that the M92 command has, so for now you would need to provide 5 colon-separated values. This will be fixed in my next build.

---

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

Loaded 0.78t firmware & 1.02 web interface last night and tried a quick print after reversing my X motor connector. Works a treat and recognised my Simplify3D G-code for the print progress page. The initial hotend temperature does not overshoot as it did in the previous firmware (I know I could have tweaked the PID parameters, but it was only one large 20 deg C overshoot when heated from cold then stayed rock-steady so not a big deal). Moves also seem to be smoother with this firmware - but that could be a false impression as I cannot see any changes listed that would account for it. Thanks for your efforts, David, they are very much appreciated.

Dave

Dave, thanks for the feedback! I'm glad it's working well for you.

My next planned firmware changes are:

1. Complete the serial interface support, ready for the TFT controller board.

2. Rewrite parts of the Move code to provide smoother movement, to provide adjustable pre-compensation for Bowden extruder lag, and to support delta printers. This probably won't happen until November.

---

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
Dave, thanks for the feedback! I'm glad it's working well for you.

My next planned firmware changes are:

1. Complete the serial interface support, ready for the TFT controller board.

2. Rewrite parts of the Move code to provide smoother movement, to provide adjustable pre-compensation for Bowden extruder lag, and to support delta printers. This probably won't happen until November.

I await the Bowden lag modification eagerly, I'm hoping that it will make a huge difference (but I may well be overly optimistic).

Dave

Quote
dmould

Quote
dc42
Dave, thanks for the feedback! I'm glad it's working well for you.

My next planned firmware changes are:

1. Complete the serial interface support, ready for the TFT controller board.

2. Rewrite parts of the Move code to provide smoother movement, to provide adjustable pre-compensation for Bowden extruder lag, and to support delta printers. This probably won't happen until November.

I await the Bowden lag modification eagerly, I'm hoping that it will make a huge difference (but I may well be overly optimistic).

Dave

will a bowden lag modification reduce oozing? or better starts of new perimeters?

Quote
muggi

Quote
dmould

Quote
dc42
Dave, thanks for the feedback! I'm glad it's working well for you.

My next planned firmware changes are:

1. Complete the serial interface support, ready for the TFT controller board.

2. Rewrite parts of the Move code to provide smoother movement, to provide adjustable pre-compensation for Bowden extruder lag, and to support delta printers. This probably won't happen until November.

I await the Bowden lag modification eagerly, I'm hoping that it will make a huge difference (but I may well be overly optimistic).

Dave

will a bowden lag modification reduce oozing? or better starts of new perimeters?

Not oozing so much as blobbing. That's the theory anyway, we won't know until we try it. The theory is that there is a time-lag between the extruder motor changing speed and the resultant change to the plastic flow at the nozzle. This results in insufficient plastic flow at the start of a move, and too much at the end (blobbing). So the idea is to modify the firmware so that the extruder motor moves are sent a short time ahead of the XY moves (or the XY moves are delayed, which amounts to the same thing). The hope is that it will result in the plastic flow at the nozzle becoming more in sync to the XY moves and so plastic will be deposited more accurately at the place it is needed instead of the place it had been needed a short while ago.

Dave

Does the fact that there is between 1 and 2 mm of travel where the bowden cable meets the extruder make any difference or is that taken care of with retraction.

Quote
jondel
Does the fact that there is between 1 and 2 mm of travel where the bowden cable meets the extruder make any difference or is that taken care of with retraction.

No, any play in the end fixing of the Bowden is, as you say, taken up by the retraction - the Bowden will be hard against the stops all the time it is extruding.

Dave

Quote
jondel
Does the fact that there is between 1 and 2 mm of travel where the bowden cable meets the extruder make any difference or is that taken care of with retraction.

Do you mean play where the Bowden cable meets the extruder drive? I don't have any play there, provided that I have the tongue inserted properly.

---

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
jondel
Does the fact that there is between 1 and 2 mm of travel where the bowden cable meets the extruder make any difference or is that taken care of with retraction.

Do you mean play where the Bowden cable meets the extruder drive? I don't have any play there, provided that I have the tongue inserted properly.

Yes I have tried two reprinted tongues and I always have had play at this point,so I thought it was normal. I will retry reprinting this with a mind to making it fit better.
Thanks

It's not only the play in the tongue. Its the Bowden cable itself that is slightly bigger than the filament. So there is an outer and inner radius the filament can take whether it is extruding or retracting. Also the Bowden tube may stretch a little when the filament is under pressure. This all leads to some dead time before the filament is fed into the hotend.

Quote
DasBasti
It's not only the play in the tongue. Its the Bowden cable itself that is slightly bigger than the filament. So there is an outer and inner radius the filament can take whether it is extruding or retracting. Also the Bowden tube may stretch a little when the filament is under pressure. This all leads to some dead time before the filament is fed into the hotend.

That is more or less what I am aiming to compensate for - the effective elasticity of the filament in the Bowden tube.

---

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 DC, if your going to add compensation for this, then it might be best to have it added as a variable in the config.g file, as not every ones
Bowden PTFE tube is going to act exactly the same. Lengths will be different, the tube hardening over time etc....
Also I noticed there is a setting in Slic3r to compensate for this by adding to the initial feed length after a retraction.

Kim..

---

Please send me a PM if you have suggestions, or problems with Big Blue 360.
I won't see comments in threads, as I move around to much.
Working Link to Big Blue 360 Complete

Hi Kim, yes the extruder elasticity factor will be configurable via a gcode.

---

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

Help please, this is a very simple question, excuse my ignorance if it has already been answered. I upgraded to 0.78t but just tried a print today. I ran my model through slic3R and ran it. Although the head followed its path the extruder motor did not move and so nothing was built. I am sure that this is something to do with the change to 2 heads (mine still has only one) but do not know how to change it. Do I have to change any slic3R profiles or hand edit the gcode produced?

Alan

Alan, what firmware were you using previously? If it was pre-0.78 then you need to update your config.g file, and also make sure there is a T1 either in your slic3r start gcode (recommended) or in config.g.

---

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,
It was 0.58 I think. Where can I find instructions for updating the file and what to add?

Alan

This [forums.reprap.org] covers the upgrade from 0.65. Coming from 0.57, you will also need to replace the T0 command in your slic3r start gcode by T1.

Edited 1 time(s). Last edit at 10/09/2014 11:21AM 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, found the problem, I had forgotten to remove the T0 command from the slic3r file. Once removed all is ok.

Alan

Please note that if you want to try this firmware on an Ormerod 2, then you should not use the versions of homey.g and homeall.g in my repository. They need to be modified to account for the Y axis endstop being at the other end of the axis. I'll add Ormerod 2 versions of the files when I get a chance. The ones for RRP 0.78c firmware will work with my firmware too, but they assume the X homing position is X=0 whereas mine assume the X homing position is the X axis minimum as set by M208.

---

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

Not sure how to dig into this any further, and it may have been addressed. but i Could not find any mention of this kind of error:

10:20:48 Error: GCodes: Attempt to read a GCode float array that is too long: G92 E0
10:20:47 File [FrameVertex.g] sent to print
10:20:36 FrameVertex.g Upload Complete in 41s
10:19:55 File Upload of FrameVertex.g to gcodes/FrameVertex.g started
10:17:19 File [bed.g] sent to print
10:17:12 T:155.4 B: 63.5
10:17:11 M115
FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:0.78t-alpha-dc42 ELECTRONICSuet (+ Extension) DATE:2014-09-26
10:17:09 Page Load Complete

Ok, Wont let me attach a File