New experimental firmware 0.78f-dc42

I've released firmware 0.78f-dc42 at [github.com] (follow the link to the version you want, then press the Raw button to download). The main purpose of this release is to make it possible to print multi-media gcode files generated by slic3r without having to edit them first. The compatible web interface is still version 0.98 available at [github.com].

Here are the changes since 0.78e-dc42:

* M563 command extended to allow the tool number origin to be adjusted. If there is no P parameter in the command then the S parameter specifies an offset to be added to tool numbers in T, G10, M104 and M109 commands. This is so that multi-media gcode files generated by slic3r can be printed without having to edit all the tool numbers in the gcode file first. This extension is intended to be temporary, until slic3r provides a mechanism for specifying the tool numbers. A separate offset is maintained for each data source (USB, web and SD card) and the offset for data from the SD card is reset to zero when a new file is started. To use this facility to print multi-media gcode files generated by slic3r 1.1.6, just add M563 S1 to your start gcode.

* M104 and M109 commands now accept an optional T parameter to specify the tool number, as generated by slic3r in multi-media gcode files.

* Changes in the movement code from RepRapPro's 0.86 dev version have been incorporated, including a 5-point manual or automatic bed compensation mechanism. To use it, just add another M557 command to the four you already have, with a P parameter of 4 and the XY coordinates at the centre of the bed (the average of the other 4). If you are using the standard IR probe (not my differential version) for auto bed compensation, you will need a white target at that point as for the other four.

* Heater status (off/standby/on) is included in the status poll response for the web interface. This will be displayed in a future version of the web interface.

* Incorporated code from RepRapPro dev branch to allow many more M-commands to return values as well as set them.

* Incorporated code from RepRapPro dev branch to implement the M119 and M135 commands. There is currently a bug in the M135 (set heat sample interval) command, which means that if you change the interval from its default value of 0.5 seconds then to get the same PID behaviour you need to change the I parameter by the same ratio and the D parameter by the inverse ratio.

* Extrusion totals are reset to zero when starting a new print from SD card.

Thanks to Adrian at RepRapPro for the changes from their dev branch, and to zombiepantslol for merging them into my fork.

---

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

Everything was working well with 0.78e-dc42, but I upgraded to 0.78f-dc42 last night and changed to five bed plane compensation (BPC) probe points near the four corners and in the centre, and now my Z homing and BPC has gone up the creek. Relevant files attached.
config.g
Testspot0.3PLA.gcode
homeall.g
start.g
When performing homeall.g as part of the testspot file, its omits to do the final line (G30 - z homing). I put a 1 second pause before it but that didn't help.
Then, when performing start.g, it stalls at the final line (G32 - bed plane compensation), and the status goes to 'ready' in the browser. If I then manually give a G32 command, it doesn't do any BPC, but instead carries on with the testspot file; but since it hasn't been Z-homed, the print is in thin air.
All the time, the hot end is high enough off the bed so that the Z probe (dc42's differential version) isn't triggered.
If I manually perform homeall.g and start.g, they both work as expected.
Any ideas?
Thanks in advance.
Ken.

CORRECTION:-

If I manually perform G30 and G32, they both work as expected. However, homeall.g has the same problem as described above. start.g sends X and Y crashing off limits.

Edited 2 time(s). Last edit at 07/29/2014 04:09AM by KenF.

UPDATE.

I downgraded back to 0.78e-dc42 and removed the fifth BPC point from the config.g file, but still had the same problems with homeall.g and start.g. Very odd.

Then, realising a common link was that the problem commands were the last commands in the file, I added G4 P1000 to the ends of homeall.g and start.g . That solved the problem, using 0.78e-dc42.

I then re-upgraded to 0.78e-dc42 0.78f-dc42 and reinstated the fifth BPC point in config.g. homeall.g then worked fine, whether called with the 'home all' button in the browser or an M98, and start.g worked fine when called with an M98. However, when printing the testspot file, although the M98 Phomeall.g line does its job, when it gets to M98 Pstart.g, and specifically the G32 command, the printer sends the X and Y drives crashing to the ends of their travel, and only tries to do a Z probe at the third and fifth BPC points. To see if it helped, I then put a G4 P1000 command after the M98 Pstart.g command in the testspot file, but that didn't help. Relevant files as they stand now:
config.g
Testspot0.3PLA.gcode
homeall.g
start.g

Any ideas???

Ken.

Edited 1 time(s). Last edit at 07/29/2014 02:27PM by KenF.

Hi Ken, i'll take a look at this issue when I get the chance, maybe tonight.

---

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, Dave. I'll look forward to hearing from you. Must say, I don't know how you find all the time to do what you do on this forum.Very much appreciated by me and, I'm sure, by everybody else on here.

UPDATE 2:

Instead of calling M98 Pstart.g in my testspot file, if I put the code of start.g in the testspot file, then all seems to work fine. I.e this works:
Testspot0.3PLA.gcode
in combination with the previous config.g and homeall.g files.

If I delete both of those G4 P1000 commands, then I get the problem with the X and Y drives crashing to their limits, but with just the first G4 P1000 command it works OK. I.e. this works:
Testspot0.3PLA.gcode

I then thought, let's combine homeall.g and start.g into a single homeBPC.g file in my sys folder, and call that in my testspot.g file, as in:
homeBPC.g
Testspot0.3PLA.gcode
but that sent the X and Y drives crashing to the their limits during the BPC.

But if I put another Wait command at the end of the homeBPC.g file, then it worked OK again:
homeBPC.g

Not sure if that will help, or just confuse the issue further.

Ken.

Edited 1 time(s). Last edit at 07/30/2014 05:37AM by KenF.

Hi Ken, I've reproduced the original problem. It looks like there is sometimes a problem when the last command in a macro file is a command that is executed via canned cycle gcodes, such as G32 or G30. However, when I added G4 P1000 commands to the end of both macro files, calling them from the test gcode file worked, even with 5-point compensation.

I shall look into the problem I reproduced. The other one may be related.

Edited 1 time(s). Last edit at 07/30/2014 05:37AM 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].

We crossed.

Ken, I've identified a few issues:

1. There is a bug in the Move code when G32 is used with 5-point compensation. Running G32 changes the XY probe coordinates, putting all except the centre one off the bed. So if you run G32 a second time without using M557 to reset all the probe points to the required values, you get the head crashing off the end of the X and Y axes.

I'll fix this soon, in the meantime the workaround is to define your 5 bed probe points in the macro file containing the G32 command.

2. If the last command in a macro file is G30 (and probably others such as G32), it may not be run unless you have some blank lines or a dummy G4 command after it. I'm still trying to work out the cause of this one.

3. I've had some strange things happen when the G32 command has failed and ended up setting some stupidly high bed compensation values. If you know you will be running bed compensation after homeall.g, then putting M561 at the start of homeall.g would be no bad thing.

---

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 Dave. I'll try those tweaks this evening. While you're thinking about the G32 command, and if it wouldn't be too much trouble, would it be be possible to let us add an argument to the G32 command so we can specify the height at which the head travels from one BPC point to the next. At the moment it's fixed at 8 mm absolute, I think. It would suit me far better, and save time, if it was say 1 mm above the trigger height of the first BPC point. If you're too busy, don't worry about it.

Ken,

I've put a new firmware build at [dl.dropboxusercontent.com]. I don't have time to do a print with it right now so I'm not putting it on general release yet. It fixes 2 bugs:

1. If the last command in a macro file did not have a new line character at the end, the command might not be fully executed.

2. If 5 bed probe coordinates were set and more than one G32 command was sent without resetting at least the first 4 probe coordinates in between them using M557 commands, then the G32 command would try to move the head off the edges of the bed and the wrong compensation would be set.

I've also reduced the Z dive height from 8mm to 5mm, which is what is used to be in the 0.57 series.

---

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

Did a test print last night. Looks good. Did not have to reset my Z Home Switch (This is good, some of the other releases. wall). Starting a Bigger print now. will let you now it terns out tomorrow, when it finishes. Looking good Though

Bigger print worked good. Had to change my fan on my hotend (Rely load). Discover sum thing that has not happen in a couple of releases Steps to reproduce

1. Home all.
2. hit the Z+10 button using the web interface.
3. Send this command: G1 X25.0 Y25.0 Z0

All three motors start to move wall in my case all 4 motors. The Z motor starts to lose steps. Not as bad on Ormerod, but my RepRapPro Mendel with Duet + expansion board controller really tweaks my printer frame. Any way, only way i have been able to reproduce it. everything is printing fine, even with a 24 hour print. still don't have my 4 to 1 bow-den tube adapter on my hot end. waiting for connectors for my extrude-er drives

Sorry, setup files for anyone trying to reproduce problem above

Hi gd,

Thanks for your feedback.

Regarding the Z motor missing steps on a combined XYZ move, I have a plan to generate all the steps in smooth sequences, which is not what happens at present on combined moves. In the meantime, to avoid this problem you should reduce your max Z speed and/or acceleration, or possibly increase Z motor current. You have max Z speed set to 250 in config.g, which is rather high - at least for an Ormerod.

---

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 done a couple of prints now including a 10 hour one using 5-point bed compensation, so I've decided to release these and a few other changes I made. The new release is 0.78h-dc42 and is available via [github.com]. The compatible web interface version is still 0.98.

Bugs fixed in this release:

1. Fixed 5-point bed compensation so that it doesn't go haywire if you run G32 more than one without setting up the probe coordinates each time

2. Fixed bug that sometimes caused the last command in a macro file to be incompletely executed if it did not end in a newline character

3. Corrected returned string when the M201 command is used with no parameters

Bug #1 was inherited from the RRP dev build, #2 was inherited from the RRP live build, and #3 was of my own making.

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

Nice! I can already confirm these changes work, I did a 3-hour print yesterday with your changes for 0.78g and everything worked well. Don't forget to merge in my networking changes sometime soon

Thanks for the response DC, i cut the feed rate down on Z to 220, tried to increase current, but the max feed rat change seams to be more effective. Still sounds like its chewing nails, so this morning i cut down to 200. If i get a chance tonight i will try the h release.

Thanks age-an for all the hard work.

Have the compile options changed for build 78h? I noticed the bin has decreased in size quite a bit.

Well-spotted Bob, looks like the compiler options somehow got reset to -Os instead of -O2 or -O3 that I was using before. I'll change it back in the 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].

Thanks. Following is the reason why I found this. It is a little strange and at the moment unresolved.

Normally I compile my own version from sources just using a later Arduino library and 78h was the first one that didn't run. When I started checking I found the size difference.

Now just changing the compiler to -Os resulted in a bin close in size to your released 78h bin and that did run OK.

Digging a bit deeper using the -O3 compile version that didn't work Pronterface reported config being read and then the connection died. So I stripped config down to the basics and that then worked OK.

I could then manually send the commands I had removed from the config.bin and I found that issuing any of these killed the connection.
M558 P2
G31 Z0.4 P530
M305 P0 H30
M305 P1 H30

These seem to be ones associated with ADC operations.

If I load the bin compiled with -Os without changing any source then all is fine and I can issue these commands or include them in config.bin without issue.

Made a small testprint this afternoon, worked well for me!

---

Björn
Umeå Universitet
Sweden

I've just released version 0.78i-dc42 at [github.com]. I've changed the optimization level to -O2. Apart from this, I've set the number of decimal places returned in various responses to gcode commands, and I've incorporated some improvements made by zombiepantslol in his 0.89d release (thanks zpl!). Mu Ormerod one and a half hours into a 2-colour print with this firmware, looking good so far.

---

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