New firmware: fix for XY moves after Z moves,ultrasonic Z probe support

I have just released firmware 057v-dc42. Changes in this release are

1. Fixed bug whereby the first XY move after a Z move would often be at a speed much higher than requested.

2. Added support for direct-mode ultrasonic z-probe using command M558 P3. Command M558 P4 selects the differential-mode ultrasonic sensor that was selected in previous versions by P3. The direct mode works well with the early Kit 5 sensor boards I am shipping and is easier to use than the differential mode.

3. Changed temperature parameter in G31 command from T to S, because T used for the tool selection command.

Download using the Raw button at [github.com].

Edited 1 time(s). Last edit at 03/23/2014 07:34PM 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].

Sounds good DC42. I The last version I used, (the 't' version I think) has worked great. I hope to try out the new version ASAP!

regards
Andy.

---

Ormerod #318
www.zoomworks.org - Free and Open Source Stuff

Hello dc42,
Thanks for your update, your work is really appreciated One thing I have noticed though is that the first XY move after a layer change takes ~3 seconds before it continues, although the speed seems to be okay. Is this normal?

Quote
zombiepantslol
One thing I have noticed though is that the first XY move after a layer change takes ~3 seconds before it continues, although the speed seems to be okay. Is this normal?

I have just noticed that on one print I did today, but not on another print. I'll look into it.

---

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
zombiepantslol
One thing I have noticed though is that the first XY move after a layer change takes ~3 seconds before it continues, although the speed seems to be okay. Is this normal?

I've managed to replicate this, although the longest delay I got is just over 1 second. I think rounding in the acceleration calculation is resulting in the deceleration starting a little too early, so that the last few steps in the XY move that follows a Z move and precedes an E move take place at 0.2mm/sec. In previous firmware, because of the bug I just fixed, under the same conditions the feed rate would have been higher than requested, so it didn't matter that the deceleration started a little early. I think I'll need to adjust the deceleration so that it fits in an exact number of steps.

---

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 worked out what's going wrong. The DDA code works out at which step it needs to stop accelerating, and at which step it needs to start decelerating. But for simultaneous XY moves, these calculations are wrong, because the interrupt code increases the time step when it simultaneously steps both X and Y. So the actual acceleration and deceleration occur for longer than calculated. For example, for a 45 degree move, they occur for sqrt(2) times longer. In the original code, both the acceleration and deceleration times will be too high by this factor, and the feed rate after accelerating and before decelerating will also be too high by about this factor. But the deceleration will finish at just the right time.

What my fix does is to limit the feed rate to the requested feed rate. So the acceleration error is corrected, by stopping the acceleration earlier than previously calculated. However, deceleration will still happen at too high a rate. So the velocity will become close to zero too soon, and the last few steps will happen at the instantDv rate, which after a Z move is only 0.2mm/sec.

The more I look at how the step code works, the more I don't like it. The code calculates the number of steps there would be between the start and end points as if a single stepper moves the head between them. It generates an interrupt for each of these 'virtual' steps. This is fine for plain X moves and plain Y moves. But for combined XY moves, at each virtual step it looks to see whether the X and/or Y steppers need to be stepped - and then if both need to be stepped, it lengthens the interval to the next virtual step by a factor of sqrt(2). The result is that neither the X nor the Y stepper motor is stepped at a uniform rate. This can't be good for getting accurate steps.

What I'd like to do instead is to step the X, Y, Z and extruder motors uniformly, independently from each other. This would mean changing the ISR to work out which stepper needs to be moved next, and setting the interrupt to occur at that time. The result would be smoother and perhaps more accurate movement. I think it might also make it easier to support combined XYZ moves.

I'm still considering what to do as a quick fix. I'm not convinced that it makes sense to increase the virtual step interval by sqrt(2) when X and Y are stepped at the same time, because I can't see the point of it, and it will make the stepper movement even less uniform than it otherwise would be.

Edited 2 time(s). Last edit at 03/25/2014 09:16AM 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 version 0.57w-dc42 and withdrawn 057v-dc42. I thought about the physics of the system and decided that changing the velocity calculation depending on how many axis were moving was the wrong thing to do, given that the steps are tiny and the X and Y axes move completely independently from an inertial point of view. The new code should result in slightly smoother movement and perhaps a reduced likelihood of missed steps, especially for moves at angles of 60 to 65 degrees off the X or Y axis. However, this version should be regarded as experimental, in case something is going on that I haven't realised. I've only done one real print using this firmware so far, and I'd be interested to see how other users find it.

I'd still like to rewrite the code to generate the steps for each motor independently, but I haven't time to do that as I need to get on with revenue-generating activities right now.

---

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
which Version would you recommend currently?

Quote
dc42
I'd still like to rewrite the code to generate the steps for each motor independently, but I haven't time to do that as I need to get on with revenue-generating activities right now.

If / When you return to this:
I'm just wondering if this problem hasn't been solved before?
From what I hear grbl is regarded to have good code for that, [github.com] and for arm cortex-m3 there is
smoothie (movement based on grbl) this seems to be the part that deals with stepping / accelerating.

[github.com]

thanks a lot for your continued help & support
it is gratly appreciated!
ps: still wondering where you hid your tip-jar.... you don't happen to have e.g. a amazon wishlist or "some such"?

Hi dc42,
just terminated my first print with 0.57w (a part with a lot of small and big circular holes)
No problems at all.
All holes are perfectly rounds and also external perimeters are very good.
My speed settings of slic3r 1.0.0RC3
60mm/s perimeters
60mm/s infill
120mm/s travel

Roberto

---

RS Ormerod #117

I just printed a small part with 0.57w as well - straight after printing the same part with 0.57v. It is 20mm diameter X 15mm high. It has a serated edge, so lots of small X & Y moves. 70mm/s speed all round, 40% infill. It printed quite a bit more quickly than 0.57v

I found that the speed changes significantly on various layers. On layers that have a solid infil (top & bottom 3 layers plus a layer about halfway up where there is the base of a vertical nut trap), the speed is high for both perimeters and infill. On the infill layers however, the speed is significantly lower for both perimeters & infill. Not sure what's going on there - I have attached the STL and Gcode (compressed with WinRar as they are too big otherwise) in case it is worthy of investigation. Maybe an extrusion speed related issue

Dave
(#106)

As an addition, I'm printing another of those parts (I need 4), and I noticed that the second (solid) layer prints slower than the first layer. Which is odd because Slic3r is set to print the first layer at 80% speed - so it should be the second layer that is faster than the first.

Dave
(#106)

Quote
dmould
As an addition, I'm printing another of those parts (I need 4), and I noticed that the second (solid) layer prints slower than the first layer. Which is odd because Slic3r is set to print the first layer at 80% speed - so it should be the second layer that is faster than the first.

Thanks Dave, I'll try printing that file myself and look at the gcode file.

---

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
gammasistemi
Hi dc42,
just terminated my first print with 0.57w (a part with a lot of small and big circular holes)
No problems at all.
All holes are perfectly rounds and also external perimeters are very good.
My speed settings of slic3r 1.0.0RC3
60mm/s perimeters
60mm/s infill
120mm/s travel

Roberto

Roberto, thanks for your feedback!

Do you notice any difference with slic3r 1.0RC3 compared to earlier versions? Since I upgraded from RC2, my printer appears to be under-extruding. But it could be caused by something I have done.

---

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
auser
Hi dc42
which Version would you recommend currently?

0.57w if you don't mind being a guinea-pig, and 0.57u otherwise.

Thanks for the link to grbl, I'll take a look at it if I get time to do any work in that area.

I don't have an Amazon wish-list, but you've already bought one of my sensor boards, so no need to add to my tip-jar yet!

---

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, just printing the 4th and last of that part. I reverted to 0.57t before printing (I've not got 0.57u on this PC). Verified the firmware load with M115 - definitely back to "t". It appears to behave in a very similar way to 0.57w as far as layer speed changes are concerned, so I guess the speed differences are either caused by Slic3r somehow, or are caused by a part of the code that has not been changed in "w". Very puzzling. The layers on that small part print fast enough to easily check on an "air print" (or a real print - under 1m of filament for the whole print). I can understand the infill part of the 40% & solid layers might change because the wider 40% infill needs a higher extrusion speed, and it's maybe hitting a limit there, but the perimeters are the same width & height, so why would the perimeter speed change between a solid layer and an infill layer?

Dave
(#106)

Quote
dmould
As an addition, I'm printing another of those parts (I need 4), and I noticed that the second (solid) layer prints slower than the first layer. Which is odd because Slic3r is set to print the first layer at 80% speed - so it should be the second layer that is faster than the first.

David, this is commanded in Leg.g. Here are some extracts:

Line 34:

G1 F2400.000 E-6.00000
G1 Z0.200 F7200.000
G1 X97.265 Y88.030 F7200.000
G1 E6.00000 F2400.000
G1 X97.995 Y87.270 E0.03650 F3360.000

1022:

G1 F2400.000 E-6.00000
G1 Z0.400 F7200.000
G1 X112.499 Y100.030 F7200.000
G1 E6.00000 F2400.000
G1 X112.481 Y100.313 E0.00983 F1229.063

So first layer is printed mainly at F3360 (falling to 2400 for a time) and the second layer starts at F1229.063 (rising to F1720.689 a little later). Maybe a bug in slic3r 1.0RC3?

Edited 1 time(s). Last edit at 03/25/2014 02:59PM 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

Quote
dmould
As an addition, I'm printing another of those parts (I need 4), and I noticed that the second (solid) layer prints slower than the first layer. Which is odd because Slic3r is set to print the first layer at 80% speed - so it should be the second layer that is faster than the first.

David, this is commanded in Leg.g. Here are some extracts:

Line 34:

G1 F2400.000 E-6.00000
G1 Z0.200 F7200.000
G1 X97.265 Y88.030 F7200.000
G1 E6.00000 F2400.000
G1 X97.995 Y87.270 E0.03650 F3360.000

1022:

G1 F2400.000 E-6.00000
G1 Z0.400 F7200.000
G1 X112.499 Y100.030 F7200.000
G1 E6.00000 F2400.000
G1 X112.481 Y100.313 E0.00983 F1229.063

So first layer is printed mainly at F3360 (falling to 2400 for a time) and the second layer starts at F1229.063 (rising to F1720.689 a little later). Maybe a bug in slic3r 1.0RC3?

Thanks for that analysis - yes, looks like a Slic3r bug, as I cannot see that any of my settings would cause a *decrease* in second layer speed. I'll go back to Cura for everything except parts with long bridges. In fact I'm going to slice that same part in Cura right now and see how it prints.

Dave
(#106)

Cura printed the layers at a consistently fast speed, and the print took half the time. The circular vertical (M3 clearance) hole was larger (more accurate) than Slicer's parts, but was not a good circle, and the hexaganal nut-trap Cura printed was mis-shapen (to the extent that the part is unusable), and the top solid infill was not as good as Slic3r managed. See photo - Slic3r's part on the left, Cura's on the right. The wrong shapes may of course be entirely due to the faster print speed causing overshooting. All in all, Slic3r made a better finished part even if (or perhaps because) it was slower. So maybe I'll stick with slic3r after all.

(The part is a simple adjustment knob to take an M3 hex bolt).

Dave
(#106)

David, perhaps you should report this issue to the developer of slic3r? As it is still a release candidate, there may be a good prospect of getting it fixed promptly.

---

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 sliced with slic3r RC3 and printed some parts today with fw 057w
First layer is printed slowly and all the others are printed at normal speed.
The final quality is unchanged from RC2.
May be that you have set one parameter that affect the infill/solid every n layers?
i.e. Infill every n layers , Only infill where needed , Solid infill every n layers , Infill density , ...

Roberto

---

RS Ormerod #117

Oops... I'm somewhat embarrassed to say that in release 57o-dc42 I broke the automatic bed compensation code, and it hasn't been working properly in any of my releases since then. I have a release candidate that fixes this at [dl.dropboxusercontent.com]. I'll release it when I or someone else has done some successful prints with it.

---

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
Oops... I'm somewhat embarrassed to say that in release 57o-dc42 I broke the automatic bed compensation code, and it hasn't been working properly in any of my releases since then.

Odd - I've been printing for weeks with your post-o firmware releases, and the bed compensation definitely seems to be working fine for all prints. A couple of my prints were 170mm X 200mm with a solid base area, and my bed height varies by nearly 0.2mm - the first layer was printed very evenly, so the head must have been pretty much the same distance from the glass over the whole area, and the Z axis was up & down like a yo-yo. OTOH I do not set any axis compensation (I have mechanically adjusted them to be true). Under what circumstances would your code cause an error?

Dave
(#106)

Quote
dc42
David, perhaps you should report this issue to the developer of slic3r? As it is still a release candidate, there may be a good prospect of getting it fixed promptly.

I'm using an old version of Slic3r (1.0.0RC3). I'll try updating it to the latest version first, and see how that print the same part.

Hmmm - it appears that it is the latest - I've not updated it for months, so it must auto-update I guess.

Dave
(#106)

Edited 1 time(s). Last edit at 03/26/2014 11:27AM by dmould.

Dave, the code as it was would behave differently depending on whether or not you homed the Z axis before running G32. If you did, then only a tiny amount of bed compensation would be applied, probably not enough to be seen. If you didn't, then the firmware would consider the first probe point to be lower (depending on your G31 setting) than it really is and the other 3 to be at almost equal heights.

I too find it odd that I hadn't noticed anything was wrong, despite the fact that I generally don't home the Z axis before running G32. But my bed is mechanically quite level, and I mostly do small prints.

Edited 1 time(s). Last edit at 03/26/2014 11:06AM 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
Dave, the code as it was would behave differently depending on whether or not you homed the Z axis before running G32. If you did, then only a tiny amount of bed compensation would be applied, probably not enough to be seen. If you didn't, then the firmware would consider the first probe point to be lower (depending on your G31 setting) than it really is and the other 3 to be at almost equal heights.

OK, that explains it - I don't use G32 but do levelling manually and use G30.

I found the reason for the Slic3r slowdown in the Slic3r FAQs - it was to do with the "cooling" settings. I had auto-cooling enabled, and Slic3r slows the print speed if the layer completes faster than the preset time. Hence why filled layer moves were faster than infill layers - they would have completed faster and so Slic3r slowed them down to complete in the minimum time.

It would be a good feature if instead of slowing down the print moves, Slic3r printed the layer at full speed and then moved the head away from the print and waited for the minimum time. As it is, slowing down the print moves on (say) a narrow column just keeps the hotend in close proximity with the same small area of the print for longer, and exacerbates the problem rather than making it better.

Dave
(#106)

I've now released the new firmware to fix G32 auto bed compensation at [github.com]. Use the Raw button to download it. I apologise to anyone whose prints have suffered due to using G32 bed compensation with one of my firmware versions in which it was broken - although I have a feeling that before my modulated IR sensor kits started arriving, few people were using G32.

---

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

This thread is as good as any - DC42 may be the best person to shed light on it.

While doing a particular print the other day, I noticed an artifact on the print, so I created a test piece to look at what was happening (STL attached)

Looking at the photo, you will see that to the right of the chevron (left arrow shape) cutout there are several faint marks of the same shape as the chevron - similar to "ghost images" on a TV set suffering from signal reflections. (They are real - not a JPEG artifact!) It was difficult to get the light and angle to capture them with my phone camera while keeping everything as focussed as possible, so the camera has not picked them up too well - in fact they extend further to the right than is visible in the photo, getting fainter and wider apart. This wall was oriented along the Y axis for printing with 0.2mm layers.

My guess is that they are artifacts caused by acceleration being applied in speed steps rather than smoothly, but I have no idea how acceleration is applied, so could well be wrong. Against that theory is that there are no similar artifacts to the left of the cutout. I would have expected the acceleration to be applied the same for right-left moves as for left-right moves - and indeed for deceleration to cause the same effect so direction would not make any difference.

Also apparent are small pit marks, which I think are because the filament I used is a scrap piece of ABS that has been kept unsealed for months, and thus absorbed a bit of water which I understand creates such pock-marks on a print.

Dave
(#106)

Dave, that piece will take a while to print. Can you provide a smaller model that displays the same effect?

Which firmware are you using?

---

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 - My hunch is that it's caused by the printhead dropping when in the gap then lifting again as it hits the stuff already printed, and going into an oscillation ( EDIT possibly fed by the stopping and starting of extrusion too - the print head floats on the fresh extrusion when running up to the gap, stops extruding then restarts when it crosses the gap, however it's no longer floating and has dropped, perhaps temporarily increasing the pressure needed for new extrudate to get out of the nozzle, a short over extrusion once pressure has built up, then a drop back down etc), I imagine it's similar to hole artefacts noticed by markbee and dc42 in threads long buried (where printing downstream of a vertical hole gives horizontal streaks in the walls of the print).

It may well be worsened by acceleration/speed, but I think the cause is mechanical - you could try preloading the head on both sides (I used a roller front and back on the X rib to achieve this and am constraining the rotation of the head further on my rebuild), but you could add some weight to the head to see if it has an effect).

Ray

Edited 1 time(s). Last edit at 03/27/2014 05:12AM by rayhicks.

I think Ray might have a good theory - but it does not explain why there are not similar marks on both sides of the gap - I'm pretty sure the head moved the other direction on alternate layers. dc42 - I've attached the OpenScad file - just adjust the lengths to what you like. The part didn't take all that long to print at 70mm/s speed - there is no infill after the base has been laid down because the wall is so narrow. I was using your "t" firmware for this test, but I first noticed the effect using "u".

Dave
(#106)