New experimental firmware 0.78za-dc42 and web interface 1.04

I've done a minor update to my firmware fork and web interface:

* Firmware 0.78za-dc42 fixes the M220 speed adjustment command, which was mostly broken in version 0.78y-dc42, and also fixes a problem with reporting directions in the M569 command. Get it via [github.com].

* Web interface 1.04 differs from 1.03 in that if you Pause and then Reset, instead of turning all the heaters off, it just sets the currently active head to standby. This makes it easier and quicker to start a new print. Get it from the SD-Image/ww folder in the dev branch of my firmware repository, or from [github.com]. You need only upload reprap.htm and js/reprap.js if you are running 1.03.

---

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 upgraded my O2 from RRP 078c to RepRapFirmware-0.78za-dc42 but are having some problems. Replaced all files on the SD card with the files from the sd-image dir. When I booted the duet it was reporting temperatures of about 350° c for both head and bed.
Copied the files from the OrmerodWebControl repo to the www dir of the SDcard.
Everything seems to be working fine now except that my y-axis is inverted. Have not seen any posts about this so I guess I'm doing something wrong.

Vizual54, you could have kept your 0.78c config and homing files, and just updated the firmware and the web interface files. I've checked the files in my repository, and I think the homeall.g file for Ormerod 2 is wrong, which will cause to go the wrong way when homing the Y axis. I'll check in a fix shortly. In the mean time, you can use the standard RRP 0.78c version of homeall.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].

Problem solved by using the home all from RRP repository.
Thanks!!

Wasn't sure if I could keep the files from 0.78c and it wasn't too much trouble to copy my changes from my old config.g

I'm glad you got it working. I have now resynced the O2 homing files in my dev branch to RRP's 0.78c ones.

---

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

*wrong post*

Edited 1 time(s). Last edit at 01/06/2015 05:11AM by antlvk.

Great firmware, web interface and SD upload is very useful. and its so stable now.
One question, how do i get the printer to turn off the heaters when the print is done?

Thanks
/Robert

Edited 1 time(s). Last edit at 01/07/2015 09:21AM by RoSt.

Quote
RoSt
Great firmware, web interface and SD upload is very useful. and its so stable now.
One question, how do i get the printer to turn off the heaters when the print is done?

Thanks! If you have M0 in your end gcode, that will turn off the heaters (but not the motors) in my fork. M1 will turn the motors off as well.

---

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 and the rest of the forum.

I'm now using 0.78za, but I'm struggling a lot.

Firstly, when printing, the Z axis refuses to move as if it doesn't get enough current. I have tried setting the current limit to 1200 in the config.g file, but no change. Via pronterface, manually moving in Z is no issue.

Secondly, the extrude speed setting in pronterface doesn't seem to work, it extrudes and retracts at maximum pace, no matter what setting you use.

Any ideas?

Thanks.

Can you post your config.g file? it sounds to me that you may have the maximum Z speed set too high.

---

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.

Thanks for the reply.

My config.g is the one from your fork.

Thanks

Actually, It clearly isn't the one from your "dev" fork

That config file looks OK to me. Can you construct a small gcode file that demonstrates the problem?

Does the extrude/retract speed work properly if you use the web interface instead of Pronterface?

Do you see the same issues when you use the standard RRP 0.78c 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].

It's a bit funny DC, I managed to print an old file and it seems ok. I will upload a Gcode example and try the RRP firmware.

I changed the config.g file to the one in your dev fork and that seems to have sorted the extruder speed.

Web interface doesn't work for me DC.

Thanks

Here's the gcode

What I notice about that gcode is that in the G1 Z layer change commands, it doesn't specify a speed. Therefore it will try to use the speed of the previous command, which is 1800. This is far too high for the Z axis, and much higher than the maximum. So it should be using the maximum Z axis speed, which you have configured as 100mm/min in config.g. Try reducing it. e.g. to 60mm/min in case your build can't reach 100.

Also check that with the motors off, you can rotate the threaded rod easily by hand.

Why doesn't the web interface work for you? Have you installed web interface 1.04 from [github.com] to the SD card? Or are you the person with the suspected faulty Ethernet connector?

---

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.

I think you're on to something there regarding the speed. I just tried with RRP 078c and it's printing fine. I'm guessing the RRP firmware (and your older versions) has an internal limit. All my Gcodes either have no speed setting in the layer change command (Cura) or very fast 4800 (slicer). Whilst writing this and checking my facts, maybe it's nothing to do with that at all.

What slicer do you use that lets you change the z speed?

Yes, i'm the guy with the suspect ethernet port. new card will be here tomorrow, so I should be able to get that up and running too.

Thanks again DC, I will change that speed in the config.g and let you know.

Quote
Yella3D
I think you're on to something there regarding the speed. I just tried with RRP 078c and it's printing fine. I'm guessing the RRP firmware (and your older versions) has an internal limit.

Strange, 0.78za should have the same default max speed (120mm/min) as 0.78c, which your config.g file changes to 100mm/min. Are you using the same config.g file with both firmware versions?

If you don't mind installing 0.78za again, please can you do the following:

1. Send M203 (with no parameters), which will return the maximum speeds. Check that the maximum for Z is reported correctly, i.e. 100mm/min as set in config.g. Also send M201 (no parameters again) and check that the maximum Z acceleration is reported as 15.

2. Send G91 to select relative mode, then G1 Z0.24 Fxxx for various values of xxx. See if you can find a highest value of xxx above which the Z axis doesn't go up as much as it should. In theory, any value of xxx above 100 should behave the same as 100 does.

---

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'm using the RRP supplied config.g with the 078c, as far as I can see, it has the same max speed settings.

I will check that and the other points tomorrow, it's getting a bit late here.

Thanks DC

When you try 0.78za again, I suggest you keep your config and homing files from RRP 0.78c, in case there is a hidden error in the config.g you were using with 0.78za before. My firmware fork is compatible with the RRP homing and config files, it's only the web interface files that need to be changed (when you have a working Ethernet port).

---

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.

I have just tried as you asked. It all seems normal.

I tried your firmware with both your config.g and the RRP version, both the same, also the 078c acts the same with both your config.g and the RRP version.
Here's what I get on all counts baring the X,Y and E accelerations, where yours are quicker.

I tried some really high numbers too, but the moved at 100mm/min correctly.

M203
Maximum feedrates: X: 15000.0, Y: 15000.0, Z: 100.0, E: 3600.0:3600.0:3600.0:3600.0:3600.0

M201
Accelerations: X: 500.0, Y: 500.0, Z: 15.0, E: 500.0:500.0:500.0:500.0:500.0

G91
G1 Z0.24 F10 OK as 30
G1 Z0.24 F20 OK as 30
G1 Z0.24 F30 OK
G1 Z0.24 F40 OK
G1 Z0.24 F50 OK
G1 Z0.24 F60 OK
G1 Z0.24 F70 OK
G1 Z0.24 F80 OK
G1 Z0.24 F90 OK
G1 Z0.24 F100 OK
G1 Z0.24 F110 OK as 100
G1 Z0.24 F120 OK as 100
G1 Z0.24 F130 OK as 100
G1 Z0.24 F140 OK as 100
G1 Z0.24 F150 OK as 100

I tried the same test print I sent you with all combinations. Z just doesn't move with your firmware.

I also found out that your homing commands don't work with the 078c firmware. I know it's not damaging the steppers, but I hate that stalling shudder sound!

I would suggest editing your G-code file to insert a sensible feedrate in the Z move line(s) in order to see whether it makes any difference. If the code works with a feedrate inserted it would help David to figure out what is going wrong (and also give you a way to get printing with his firmware immediately, by editing all the Z moves).

Dave

Thanks for trying that. I don't understand what is going wrong. If you have time, please can you try this version: [github.com]. No need to change any config or homing files, use whatever you are using already.

---

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
Yella3D
I also found out that your homing commands don't work with the 078c firmware. I know it's not damaging the steppers, but I hate that stalling shudder sound!

What axis fails to home? Ensure you have the correct command to set the Z sensor type you are using, and that the X axis motor is connected the correct way around (there was a change between versions of both RRP and DC42), and that the Z sensor is connected to the correct pin on the Duet (again the pin number changed between firmware versions).

Dave

Edited 1 time(s). Last edit at 01/13/2015 11:44AM by dmould.

The RRP firmware relies on the homing commands being followed immediately by a G92 command. Mine doesn't, so in my O1 homing files there are no G92 commands and the home position will be taken from the configured axis lengths. But the RRP homing files can be used with my firmware too. The O2 homing files in my fork are identical to the RRP ones.

---

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

I just modified the test gcode by adding a speed for the z move.

It still does the same. the Z stepper does knock, like it's trying to move.

I switched back to 078c just to be sure and it works fine.

I tried the RepRapFirmware-0.80c-delta-dc42.bin. It seems to works fine. I was going to report that manual extruder moves cause the duet to freeze, then I realized i have it set to move at 1mm/min.

Does this help to shed any light on my issue? and can i use the 0.80c firmware as is?

So for am I right in thinking that your homing files will cause problems when used with the RRP firmware?

Thanks again.

Quote
Yella3D
Does this help to shed any light on my issue? and can i use the 0.80c firmware as is?

Thanks, that indicates that a problem has crept into my the firmware fork at one of the late 0.78 series revisions. I intend to replace 0.78 by 0.80 within a few days anyway. I have been using 0.80c myself for a while with no problems. One thing you may notice is that the final X homing speed is very low. This is because RRP specifies 200mm/min final X homing speed in the homing files, however this gets increased to a minimum speed (generally 800mm/min or 900mm/min) in the RRP firmware. My 0.80 series has no minimum speeds, so if you ask for something very slow, you get what you asked for.

Quote
Yella3D
So for am I right in thinking that your homing files will cause problems when used with the RRP firmware?

Yes. The RRP firmware has a bug that (perhaps they would call it a feature) that the homing moves don't cause the position on the axis to be set properly prior to the next move when the endstop switch or probe is triggered. They get round this by always having a G92 command after the homing move. So if you remove the G92 commands as I did in my O1 homing files, then homing doesn't work when using the RRP official firmware. If you want to be able to switch firmwares, use the RRP homing files. They work OK with my firmware fork too, it just means that if you want to change the axis lengths or offsets, you have to change them in the G92 commands in the homing files as well as 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].

Excellent, thanks DC, you're a star!