New firmware 1.04a-dc42

I have released firmware 1.04a-dc42 at [github.com]. The changes since 1.00q-dc42 are:

Quote

1. Fixed bug in version 1.00q: when uploading to SD card via USB the file was printed immediately.

2. Merged RRP's 1.04 changes:

(a) Implemented automatic control of the fan pin for extruding/non-extruding moves; except that in my fork, this is only enabled if the ancilliary PWM set by M571 is nonzero. This is so that you can still use M106 to control the fan.

(b) Added M573 command to report average heater PWM.

If you are upgrading from a firmware version prior to my 1.00 series, please note the following:

1. You can either keep your existing config.g and homing files, or adapt mine to suit your build. My config.g file still defines the first print head as tool T1, because I am waiting for zombiepantslol to release a version of his DuetWebControl that allows it to be T0 instead. You can use the M563 S1 command if necessary to temporarily renumber tools for slic3r dual-head printing.

2. If you have an Ormerod 1 and you keep your existing config.g file, you need to add this command to config.g:

M574 X0 Y2 Z0 S1

This tells the firmware that the Y endstop is at then high end. You also need to either reverse the X motor connector (so that the colours are in the same order as the other motors connectors, as on Ormerod 2), or add command M569 P0 S1 to config.g (to tell the firmware that the X motor moves in the opposite direction).

3. If you want to take advantage of faster (i.e. simultaneous) X and Y homing, then you must use my homeall.g file and ensure that you have set up the axis positive and negative limits using M208 commands in config.g.

Edited 3 time(s). Last edit at 03/21/2015 11:15AM 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].

I've just released a minor update, version 1.04b-dc42. It's at [github.com]. The changes from 1.04a-dc42 are:

Quote

Changed tool numbers to start at T0 in all /sys files
Added sample macro files
Improved speed of integer square root function (thanks dmould)
Fixed bug in GCodeBuffer IsEmpty function (thanks zombiepantslol)

The compatible web interface is DuetWebControl 1.04 from zombiepantslol, available at [github.com].

---

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 DC42,

Is there a config file for the Huxley Duo - As i cannot see one,

i have started with the omeroid 2 configs,

So far I have added the 2 lines for the X axis being reversed and the Y sensor being Hi,

Also changed the R1000 to R4700 for the hothead and bed sensor.

This is where I have hit an issue, my bed now reads -22 where as it should read somewhere between 5 and 10.

the head reads about 24 which is what i would expect

Is there some other value/setting i need to make?

James...(JMKnox)

Hi James,

If you have a config.g file that works with RRP 0.78c on your Huxley Duo, then I suggest you use that. Or use the one from the RRP 1.04 release if you want to use the new tool numbering scheme. Either way, the only line I think you should need to add for my firmware fork is the M574 one to tell it what endstop switches you have.

Regarding the bed temperature reading, looks like the M305 line for the bed needs to be M305 P0 T100000 R4700, because the Huxley as a 100K bed thermistor (firmware default is 10K) and your Duet has a 4.7K series resistor (firmware default is 1K)..

---

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,

Thanks for the advise.

Had to alter a few other things,

Had to change the X and Y co-ords in the bed.g as the auto bed compensation was trying to move to locations that did not exist on a huxley, bed is only 140x140.

Also changed the homez to be at x45, y5 to ensure the sensor was well away from the edge of the bed.

I have attached the sys folder I have created that is a good startpoint for the normal configuration stage.

Please feel free to use/abuse the changes I made thay appear to work for me.

James

Thanks James, I'm glad you got t working. I should have mentioned that to start with, it's probably a good idea to keep your existing Huxley Duo homing files and bed.g as well as the config.g file. But if you are now using homing files based on my Ormerod ones, then I guess you have simultaneous XY homing working on the Huxley.

I'd add a sys-Huxley folder to my guthub repo, based on your files with some changes (see below). Please let me know if you find anything else you need to alter.

Comparing the config.g file in your zip file with the RepRapPro 1.04 version for the Huxley, I see a few changes that I think you should consider reverting to the RRP values for Huxley:

- M906 motor currents appear to be lower for the Huxley. I guess it has smaller stepper motors. You might overheat the motors if you continue to use the Ormerod values.
- M201 accelerations are very different
- M92 extruder steps/mm is different

Also you should change the M208 commands at the end to fit the bed size of your Huxley.

---

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

Dave,

Thanks for the feed back - I will update my files also as you suggest.

One other thing I found is that the pause.g goes to Y=200... not good on a huxley - i set it to go to Y 0.... Much safer as the huxley has a end sensor at 0.

James

I've added a sys-Huxley folder to SD-Image in my github repo. I used RepRapPro's version of config.g with added M574 and M208 commands (the M208 command seems to be missing in RRP's version), and your versions of the other sys files, including the change you suggested to pause.g. Thanks for contributing them!

---

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

Dave,

Any advise on how to find the settings for M208 - Or is it a matter of moving the head around to map the printable area locations?

James

You need to decide what you want the bottom and top X and Y coordinates to be. On an Ormerod, the X home position places the nozzle off the edge of the bed, by 8mm for my build. So I want to define the home position as X= -8, so that X=0 is one edge of the bed. The head will safely move 220mm along the X axis, so I define the upper limit as 220m + (-8) = 212. So my X axis goes from -8 to 212mm.

The Y axis on my Ormerod moves 210mm and is set up so that at the ends of its travel, the nozzle is over the edges of the 210mm wide bed. So I want the Y limits to be 0mm at the low end and 210mm at the high end.

To set the upper limits, use M208 without the S parameter, To set the lower limits, use M208 with the S1 parameter. So I use:

M208 X212 Y210	; set axis maxima
M208 X-8 Y0 S1	; set axis minima

The axis minima/maxima values serve two purposes:

1. In any move that is not a homing move, if the axis has been homed already then the firmware will truncate the move if necessary to prevent the head from being moved outside these limits, thereby avoiding possible damage. You can override this with the M564 command.

2. When you home an axis and the endstop switch or probe is triggered, the head is assumed to be at the position defined by M208. So in my example, when I home the X axis and the probe moves over the target, movement is stopped and the head is assumed to be at X= -8. Likewise, when I home the Y axis on my Ormerod 1 and the Y high-endstop switch is triggered, the head is assumed to be at Y=210. [This is one reason why my firmware likes to know where the endstop switches are, hence the M574 command.] You can set a different value by putting a G92 command immediately after the homing move in the homing file, which is what RepRapPro tend to do in their homing files.

Edited 2 time(s). Last edit at 03/27/2015 07:07PM 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].

Dave,

Thanks for that description - Got it working fine now and can also confirm that the home all works great... well it did after I changed this,

M574 X0 Y1 Z0 S1 ; end stop type

I had it set as Y2....

Also, If you wish, My M208 settings are:

M208 X130 Y138 ; set axis maxima (adjust to suit your machine)
M208 X-13 Y-4 S1 ; set axis minimum (adjust to make X=0 the edge of the bed)

This makes the config work fine for my Huxley Duo...

Having done all that the Bed.g needed to be changed to check the levels at X120 and Y120, not X130 and Y130 as this was too close to the edge.

Many Thanks again

James

Edited 1 time(s). Last edit at 03/27/2015 07:08PM by jmknox.

Thanks James, I've updated the config.g for Huxley in my repo.

---

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

Awesome that you put together the files for the Huxley! The bed.g file is still missing so. As the other printers do not seem to have that file either in you fork I am wondering if your firmware just doesn't need it or if I am supposed to supply my own file?

My firmware fork runs bed.g in response to G32 if it exists. Otherwise, it uses the coordinates provided by M557 commands, which is what the 0.78 and earlier series firmware did. I'll add bed.g files in my next release, to make transitioning from RRP 1.04 to my fork easier.

---

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

Nice! I already thought that having to specify the bed probing positions twice (once in the config.g and once in bed.g) is a bit stupid.

Hi Dave,
I hope you can help.
I'm using the duet on a custom reprap and upgraded the firmware to 1.04c (I just flashed the bin file). I have endstop switches for X Y and Z, X and Y are homing fine but Z isn't. I have set the M574 command to: M574 X1 Y1 Z1 S1 in the config file.

Any ideas?

I assume you are using a low-end microswitch for Z homing, connected to the Z endstop pins. By default, the Z probe is used for homing X and Z on the Duet. To use switches instead, you need to disable homing using the Z probe. This is the command I use for the Mini Kossel:

M558 P4 X0 Y0 Z0 H8 ; Z probe is a switch and is not used for homing any axes

The Z0 tells the firmware not to use the Z probe for Z homing.

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

That did the trick!
I had to connect the endstop to the E0 terminal rather than the Z terminal but that's it.

Quote
mynamesriz
That did the trick!
I had to connect the endstop to the E0 terminal rather than the Z terminal but that's it.

I think you must be using the homeall.g and homez.g files for an Ormerod or a Huxley. Those use a G30 command for homing, which activates the Z probe. In my fork, the P4 parameter in the M558 command tells the firmware that the Z probe is a switch connected to the E0 endstop pins, which explains why it is working for you.

The alternative would be to connect the switch to the Z endstop pins, and then write the homez.g and the Z homing part of homeall.g the same way that homey.g is written, but specifying the Z axis in the movement commands instead of the Y axis.

---

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 cool, I'll give that a go. Thanks!

BTW, the reason for the upgrade was so I could use the Paneldue board I bought recently with it... It's working a treat now, thank you for all the hard work and support.

Quote
mynamesriz
BTW, the reason for the upgrade was so I could use the Paneldue board I bought recently with it... It's working a treat now, thank you for all the hard work and support.

Thanks for the feedback!

---

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