Posts made by CHP

@bot 1.23.2 Is the firmware version

It looks like the PanelDue shows Heaters instead of Tools. I have 4 tools configured, using the default heaters everything is shown correctly but now I have assigned H7 to the 3rd tool (because the cable was too short) and it's all messed up now:

This is not a wish, just my experiments using the stallGuard feature of the TMC2660s. Since ist was mentioned several times I wanted to try it out myself.

tl;dr It works but probably too finicky to tune correctly.

One has to get three dependent values right: stallGuard threshold, motor current and movement speed.
On the first picture I have a normal X move on my BigBox (cartesian), stallGuard threshold is at 3 and current at 500mA. The orange move is undisturbed as one can see the initial acceleration is nearly tripping the stallGuard (getting down to 0) followed by some ringing. In the blue graph I stopped the carriage with my hand, you can see the line going down slowly because of the springiness of my hand, after that the motor is stalling heavily even moving backwards at times but the stallGuard didn't trip.

On the second picture I tried it with the Z axis (100 full steps per mm), set the current to 200mA because the lead screws give too much torque. I changed the tripped zero values to -100 to make them visible in the graph. In the last part the nozzle hits the bed and trips the stallGuard but the stepper never stalled.

So premature my conclusion is, making this work reliably is hard, you can't use any signal filtering because then you are several steps "behind".
If someone wants to experiment with this further you can use my stallGuard branch https://github.com/ChristophPech/RepRapFirmware/tree/stallGuard Currently one can use the stallGuard as virtual endstops, also record the values for further analysis. If someone needs a precompiled binary I can build one, I'd even add a possibility to set the stallGuard threshold values.

I never tried ABS but for PLA and PETG I am using 90°C bed temperature otherwise it doesn't stick well without printing the first layer slower and squish it down.

I dislike squishing the first layer because it gives the print elephant feet also without serious slowdown stuff gets ripped off.

But at 90-100°C (surface temp on the bigbox is ~10° lower than the thermistor reports) the filament sticks well to the bed even at higher speeds and also if the nozzle is way to far from the bed. I could move the nozzle several mm above the bed, the first layer would still stick.

@GrodanB

So the 90 degree is not in Y but in Z then…?
It's an axle which can rotate in X but also offsets the sensor 50mm to the right. It moves it nearer to the hotend since I have no hotend installed in the left slot of my carriage.

Is there a way of getting the firmware to display the height map that is in use?
For that I made this simualtion branch so I can test it on a PC. But you need Visual Studio 2015 (free express version) to run it:
https://github.com/ChristophPech/RepRapFirmware/tree/sim

I ran two of your examples through it at 2mm resolution. The easiest way to visualize is opening it in Excel and insert the 3D-Surface chart of the whole table with default settings.

https://drive.google.com/file/d/0B-DBgmDdShYnQWlFS2V3SDJpS0U/view?usp=sharing
https://drive.google.com/file/d/0B-DBgmDdShYnUnp0X1NFdVFWN1U/view?usp=sharing
(filename dates are references to the comment's times)

@GrodanB
If your right tool is at zero then the sensor is relative to that:
G31 T1 P500 X-63.2 Y7.0 Z2.53

From your picture it looks like the IR LED is bend (but I'm not sure, it could be just the odd angle of the photo)

By "adjusting the angle of the IR sensor board" I meant through the 2 screws at the top which are connected to the carriage. If you look at the plastic under the screws there might be some depressions from the screws in which case you can't change the angle anymore so the part needs to be reprinted.

@GrodanB
(I have the Clever3D bed too, but not the black one, the metallic one)
I made this horrible IR-sensor mount: https://drive.google.com/file/d/0B-DBgmDdShYnSkRBVXBBMklWanc/view?usp=sharing
It's good for testing the influence of the angle but only a temporary measure before I switch to IDEX. You can easily misalign it by touching it the wrong way, also it only fits the pro-hybrid carriage with volcano.

Additionally my bed.g script turns off the lights before measuring and turns them back on after, but I'm almost sure that doesn't matter.

@GrodanB

Why can't I set the probe placement relative to each tool separately?
Because it has nothing to do with the tool offsets. Think of the IR-sensor as if it it's own tool.

Also your measured bed-matrix looks very inconsistent. I had the same problem on my BigBox in the past, the reason was that the angle of the IR-sensor was not parallel to the bed. I couldn't even change the angle because the screws of the sensor mount have made some groves.

The "correct" bed-matrix on the BigBox should look mostly flat with a slight bulge upwards in the center (this is due to the sag of the smooth rods)

And we can even do better by using bicubic interpolation:

Since Z is often the slowest axis, smoothing it out will mean smoother movement for the other axes.

But there still remain two last issues: unprobed points with a 0 csv are being clamped to zero, this can easily be fixed

Second: points outside the probing area remain constant. These should be extrapolated, maybe something like linear regression.

Thoughts?

But there is still more. Zeroing out the last two columns gives me this:

The interpolation overflows into the first column of the next line. Fixing it:

The final result of the whole mesh: looks quite good.

I found an error in one of the interpolation functions and fixed it (pull request pending)

The result looks much better:

Ok, so I loaded GrodanB's heightmap.csv and then sampled the whole bed ( HeightMap::GetInterpolatedHeightError() ) with a 4mm (and 2mm) resolution and visualised the result with excel.

The first one is rather off, the area clearly wrong. Debugging it showed that GridDefinition::recipSpacing is still at its default value (for a 20mm grid) after loading the .csv.

After fixing that it is much better, but still some hard jumps at the borders, so I'll debug the border-interpolation next.

My fixes as well as the (very shoddy) simulator I use can be found here: https://github.com/ChristophPech/RepRapFirmware

There is definitely something wrong with the mesh-bed-compensation. The first thing I wondered about were the spurious pauses while printing At first I thought it is the non-extruding-move while changing perimeter.

I investigated further and found out the "stops" are at specific positions even if I move the head manually through the paneldue. When the "stops" occur the bed moves in Z-direction a significant amount (0.5mm) although it should change only gradually according to the heightmap.csv.

I then tried to find the spots where these "stops/jumps" occur and they were always at some 5mm border, for example between 184.9mm and 185mm or 74.9mm and 75mm.

To me it seems there is some rounding error which can happen more easily when using inverse multiplication instead of division, taking a first glance at HeightMap::GetInterpolatedHeightError() I couldn't spot any issue although the HeightMap::InterpolateXY looks a bit overcomplicated in favour of just clamping the values.
I guess I'll just run some tests and debug these functions hoping that these are not some compiler or CPU specific rounding errors. …

Wantai 42BYGHM809L20P4.5-17-X2
M906 X1275 Y1275 Z800 E1000 I30
Supply: 24V

They are humming noticably compared to the A4988 I used before, but it's not too bad.

I have a direct-drive Titan extruder. I'll try a higher value.
Does that mean the duet will stop movement when switching from an extruding move to a non-extruding move?

I tested it with a 0.8 nozzle and pressure advance coefficient of S0.05
Getting the nozzle to stop oozing would require a retraction of at least 3-4mm so preassure advance can't really solve the problem.

I am experiencing the same problem. I'm new to duet, I installed mine last Sunday and after setting up everything my first print was the "Yet Another Duet WiFi Mount" for the e3d BigBox.
I was very astonished about how smooth the movements are but in every circular movement there was a significant pause.
This leads to big globs. I am using a volcano hotend with big nozzles and PETG which is a combination in which getting the oozing under control is very hard (I tested pressure control only once, I have not dialed it in yet)

Looking at the g-code I think you are right, it is the perimeter switch:

G1 X65.300 Y67.544 E0.0789
G1 X66.573 Y66.203 E0.0797
G1 X67.890 Y64.889 E0.0802
; inner perimeter
G1 X67.491 Y64.474 F6000
G1 X70.170 Y61.999 E0.1572 F1395
G1 X73.037 Y59.606 E0.1610
G1 X73.307 Y59.386 E0.0150

This is done by S3D, going from the outer to the inner perimeter using a small non-extruding movement perpendicular to the previous path. Marlin just "thumps" over these bits but it looks like Duet is coming to a near or full stop.
My jerk setting on Marlin was 8mm/s and on Duet 10mm/s.