Duet setup - instructions in progress

[geneb]

I've actually never had the "blobby corner" problem that some people have run in to. I've got an hour plus of work to swap out the controllers and run a drop to the printer, but you can be sure I'll put my two cents in once Blue MAX is back on her feet.

I've got both boards updated and talking over the network now - even reformatting that original SD card didn't fix the issue, which is kind of strange - you'd think Windows would throw a fit over it as well...

g.

[mhackney]

I can't tell you how many bad "premium" SD cards I've had. All the cards that came with Smoothie were crap. One of the 4 Duet cards was crap. I buy them 6 at a time when Amazon has them on sale and mark the good ones.

+1 on the M572

[Eaglezsoar]

With all these setup tips we should have a centralized database of the firmware and all the tips for setting it up .
A firmware setup how to would be great. I have the cards but haven,t installed one yet or I would do it. If one isn't done before I can,
then I will do it later.

[mhackney]

There is a centralized listing of the codes at http://reprap.org/wiki/G-code and it is kept up to date for dc42.

I am working with Think3DPrint3D and David to write the firmware and setup guide. It's actually pretty easy if you start with one of the samples. Much easier than compiling and uploading Arduino firmware and dealing with the EEPROM nonsense!

[bot]

I gotta agree, the setup is easier once you understand the concept of how it's set up. Especially when changing setups and experimenting, not having to recompile and upload is nice.

And Gene, I agree on my max I never had blobbing. I think repetier has advance (not advanced, advance) to coordinate the extruder flow with nozzle movement speed. With duet and rrf, if you have low jerk settings with high acceleration or high speed, you'll see corner blobbing without activating the elasticity compensation. With a bowden setup, it's more to replace the "coast" feature of s3d to prevent oozing and stringing.

[geneb]

NOTE: the wiring harness that comes with the JohnSL/FSR kit from UltiBot needs to be modified. I left the end connected to the JohnSL board alone (the original connector). Here is how it attaches:

[img]http://mhackney.zenfolio.com/img/s2/v50 ... 7497-2.jpg[/img]

Note in the photo above (3 pin connector labeled P) that the red and black wires are reversed. Simply make up your new connector on the Duet side to match this photo.

RepRapFirmware config in the next post.

Ok, before I noticed this part, I powered up the machine (with the poor Duet hanging by the cables...only the end stops & motors are connected right now), and the FSR board seems to be operating with the red wire in the center (basically the stock cable). The red lights blink when I knock on the build platform. However, even with the indicated jumper installed, the firmware doesn't "see" the FSR hit when the nozzle strikes the bed during auto-cal.

The question I have is this - knowing that red & black are power, am I going to end up destroying the FSR board if I wire it as shown above because I'm essentially connecting the board with reversed polarity?

My config.g file is linked earlier so you can see how I've got the whole thing set up - I don't think I missed anything other than having to invert the motors for the three axes.

I should note that I'm using the original servo lead that came with the FSR board and the Duet end matches yours with the exception of the signal wire being white instead of gray as in your installation. The FSR board end is black-red-white with the board oriented the same as you show above.

tnx!

g.

[mhackney]

Gene, take a look at my blog, there is a complete post dedicated to setting up FSRs with Duet. But a couple of things here...

The JohnSL board rectifies the +/- but I prefer to "do it right" and match the output, from Duet in this case.

If you see the LEDs light on JohnSL, you should also see the red LED on Duet go OUT (make sure you have the JohnSL setup with the jumper for NC - see my blog).

[geneb]

Something is missing - the light on the Duet does go out when I tap on the bed, but jumper or no jumper, it still slams into the bed at full speed.

If I tell it the Z height is 350, it quickly moves from probe point to probe point without ever touching the bed.

Here's the current setting: M665 R135 L269 B140 H380 - at 380 it just slams the nozzle into the bed.

I just ran it again to check and while the nozzle is skittering across the bed, the probe LED on the Duet is going out. It's as if the firmware is completely ignoring the Z probe.

Originally the z probe (I think) was configured thus:
M558 P1 X0 Y0 Z0

After digging through your configuration file, I changed it to this:
M558 P4 X0 Y0 Z0 H3

No change in behavior, it still slams into the bed.

I dug into the M558 docs and found this: "The XYZ parameters in the M558 command define which axes the Z probe is used to home (0 = Z probe not used to home this axis, 1 = Z probe used). By default, RepRapFirmware uses the Z probe to home the X and Z axes." so I set Z thus:
M558 P4 X0 Y0 Z1 H3

*SLAM*

I did some digging and thought that this G31 X0 Y0 Z-0.05 P500 might be the issue since your configuration doesn't list the P value. Nope. There or not, still slams into the bed.

Also, there's no mention in your write up about why your configuration includes X, Y and Z parameters, but the default configuration doesn't include them. -> M665 R133.87 L269.0 B120 H341.92 X0.194 Y0.72 Z0.00

Is the root cause of my problem this comment?
;*** The homed height is deliberately set too high in the following - you will adjust it during calibration.

Does the firmware not know to bloody well stop when the z probe is triggered?

I've also verified that the Z probe is working - G31 reports 0 when nothing is touching the bed and values between 62 and 1000 while my wife was kind enough to stand there and tap on the bed. (Blue MAX is perched atop a filing cabinet.)

I don't know what else to check.

g.

[mhackney]

The X Y and Z are the tower offsets so if all your towers are perfect then you don't need them. Mine aren't. I don't know whey the default would not have that since it is a very common configuration.

M558 P4 X0 Y0 Z0 H2 F100

Will slow the probing speed down but also provide enough force to trigger the FSRs.

Finally, you do have to get H in M665 in the ballpark - within 5 to 10mm - or the firmware has no way of knowing when to quit. The behavior you should expect to see is this:

the printer homes (if you have H28 in bed.g)

The nozzle lowers to some small distance above X=Y=0. It DOES NOT probe the first descent to X=Y=0. If you are slamming into the bed at that point, you need to lower your H. The default config.g and bed.g have comments about this and to be conservative setting things up. Yes, the comment

Is the root cause of my problem this comment?
;*** The homed height is deliberately set too high in the following - you will adjust it during calibration.

is most likely the issue. No, the firmware DOES NOT know where to stop on the first probe point. That's the purpose of the H parameter. Home and then lower the nozzle until it is 5mm above the bed. Read the Z (height) and use that for H.

Once the nozzle is hovering at X=Y=0 it dashes out to the first probe point (usually on the periphery) and probes at the speed in M558.

[geneb]

This just gets weirder.

I'm trying to set the correct, exact z-height.

G28 to reset, Z reads 365.00.
I then use the web interface to get the nozzle a paper thickness off the bed. Z now reads 14.10.

I then do a G92 X0 Y0 Z0 to zero all three axes. Z on the web interface now reads 0.00.

I then do a G28. Z now reads 365.00 after bouncing off the switches. If I send G0 Z0, it will slam into the bed.

This is wrong. Under Repetier, this process will give me an accurate Z height. The Duet is using the configured value of 370, regardless of what it actually is. Bug or mis-feature.

Setting the max Z height to 350.9 (365.00 - 14.10) should keep it from slamming.... and it does, as the nozzle stops about 5mm above the bed.

I've got it probing finally, so thank you!

It should NOT be this difficult. There's huge holes in the documentation.

g.

[mhackney]

Did you read David's blog posts on commissioning a mini kossel with duet? That's mostly how I learned.

My understanding on G92 is that it is reset when you issue a G28.

[bot]

Here are two great resources:

http://reprap.org/wiki/Configuring_RepR ... an_printer (This covers all the basics)

http://reprap.org/wiki/Configuring_and_ ... apFirmware (This covers the extra delta stuff)

[geneb]

I asked Dan about the behavior - the problem is that since it doesn't behave like Rep does, there's no real way that i know of to obtain an accurate max Z height.

I've also asked him about the initial slamming problem if you follow the comment in the config file and over state your Z height.

Bot - I'd found those a short while ago. I need to get my thermistor settings squared away and I'll try a print.

Oh, btw mhackney - for a v1, the Y position (125) in your bed.g file makes the motors skip once the arms go past vertical - I tweaked the value to 105 and it works without problems. i've also increased the bed probe speed to 300 and it's doing ok.

g.

[geneb]

Is the work done by the auto calibrate process cleared with a G28?

tnx.

g.

[bot]

I don't think so. You can check by sending m665 and m666 and comparing to previous/set settings.

[mhackney]

My V1 is not stock so I can't comment on the bed.g. I'm using the trick laser arms.

G28 does not clear a previous calibration or M665 or M666.

Who's Dan?

[geneb]

He's a firmware dev I've been talking to - I think he did Sailfish and some Marlin work. I'm used to everyone knowing who everyone else is.

Tried printing and the nozzle is too close to the glass to extrude any material. I wonder if beer would help.

g.

[bot]

Just as long as you only pour the beer on the print bed, and not the duet.

[mhackney]

It sounds like you need to adjust for the trigger deflection inherent with FSRs. That is at the bottom of config.g - the G31 command. My blog post has detailed instructions on how to set it, here it is:

The G31 line in the config.g file can offset this. I have a very rigid bed and mounting system and find I need -0.05 mm compensation using the Z parameter for Z probe height.

G31 X0 Y0 Z-.05 P500 ; Set the zprobe height and threshold (put your own values here)

In the dc42 firmware, David has built-in some very flexible probe height offset with the G30 H parameter. Basically, this allows you to correct for any offset differences at the probing points. Here's how you go about doing that:
Above each probe point (from the bed.g file) lower the nozzle using the paper grip test.
Send a G92 Z0.
Raise the nozzle 5mm.
Send G30 S-1 and write that down.
Read the trigger height (if you did the above from the web interface, read it there, otherwise read from the PanelDue console).
Repat 3 - 5 several times and average the results. I like to do 3 probes.
Repeat 1 - 6 for each probe point from the bed.g file.
Edit the G31 Z parameter in config.g to the trigger height you measured at the bed center: X = Y = 0.
In bed.g set the H parameter for for each of the probe points like this:
H = (trigger height measured at the point) - (trigger height at the bed center)

You can perform this sequence at the single point at X=Y=0 to get the height offset for G31. If your bed flexes more between the FSR mount points or instance, you can go the full monty and adjust the height offset at each probe point to compensate for differing trigger heights at each point.

[geneb]

Turns out it was actually S3D. I threw a cube sliced in Kisslicer at it and it wasn't rubbing the glass. Granted, the extruder was /trying/ to turn really fast - I've never heard machine gun noises out of an extruder.

When the job started printing the first layer's infill, the extruder knob was rotating faster that I could turn it by hand and I KNOW that's not right.

My configuration sets the steps/mm via M92 E92.5, which is what it's set at for the RAMBo. Even extruding with one click on the Extruder Control @ 10mm/sec makes it chatter a bit. Is the Duet running at 32 microsteps? (but if that was the case, setting the axis steps to 80 steps/mm wouldn't be working...) The M93 command isn't supported by RRF, so I can't tell if it's actually taking the M92 command.

I guess the good news is, by me falling down the stairs face first, nobody else will have to.

g.

[mhackney]

S3D

You do have to change your slicing settings. RRF requires explicit settings where as Repetier is loose goosey. The net issue shows up with extrusion - the old relative vs absolute issue.

Ive attached my latest KISS files for KISSlicer v1.5 Beta 2.20. Unzip and place in same folder with the KISS application. If you have setups in your existing configs, save them and merge them manually after you understand what's required to support RRF. Look at Printer->Firmware and Gcode->Prefix

Archive.zip

(4.68 KiB) Downloaded 425 times

[mhackney]

Here are some helpful macro files. Just add these to the root folder (peer to /sys) on the CF card (unzip first of course) in a folder called macros.

macros.zip

(4.34 KiB) Downloaded 362 times

The two macros starting with "_^" and "_v" move the nozzle up or down .02mm. This is great for tweaking the first layer of a print. To use, simply Pause the printer (Web or PanelDue) and then select the appropriate macro. If you need to move more than a single increment, wait for the first increment and then you can click the button multiple times to move say .06mm. You'll understand why you have to wait for a split second when you run it the first time.

AutoCalibrate.g is a short cut for G32 so I have it on a menu

E motors off.g simply cuts power to the extruder motors

Extrude 3mm.g and Extract 3mm.g do what their names say

Macros are very useful so take a look at these and develop (and share) your own.

[geneb]

Thanks for the files! I'll have to get my version of KS updated, I'm on 1.4.5.10.

I take it the Duet requires Relative instead of Absolute?

tnx!

g.

[IMBoring25]

With the proper g-code configuration it will take either. When I last experimented with it, however, the filament usage and completion estimate calculations in the web interface had a few more "features" (i.e., bugs) on absolute extrusion coordinates.

[mhackney]

You can use either but you just need to be explicit. I use Relative because I've developed a lot of post processing scripts to do special things and they work with Relative extrusion.