Best posts made by garyd9

After a few months playing with the Duet3 and SBC combination, I've decided to revert the duet3 back to standalone. The decision was made last night when my Raspberry Pi4 locked up. (It might have been a kernel panic. I don't know. The Pi was completely unresponsive until I disconnected power and reconnected to let it reboot.) This happened mid-print.

In the course of the last few months, I found that using the duet3 in SBC mode isn't limiting as I expected. While RRF 3.2.2 is slightly ahead of DSF in development, everything I needed worked properly or could be made to work with slight changes. Specifically, the PanelDue works fine when the Duet is in SBC mode, and any conditional g-code parsing issues I had with DSF were easily worked around. In other words, I found running with DSF to be stable and working.

However, there's no getting around the fact that the SBC is a multi-faceted additional point of failure. Not only can the Pi hardware can fail, but there's also the SPI ribbon cable, the additional power supply for the Pi, the OS running on the Pi, and the DSF software suite (This is in addition to all the things that can fail on a standalone Duet3 installation.)

At the current time, and for my particular installation, the only added value that the SBC offered to me was faster gcode upload speeds and an ethernet bridge. It also offered the ability to tinker that I never got around to taking advantage of. Even if I used a small touch screen with DWC on the SBC, I still think things would be more stable with the duet3 in standalone and the Pi running independently.

Perhaps one day RRF/DSFwill offer some advantage over standalone that will cause me to re-evaluate.

PLEASE get rid of this horrible "feature" in DWC2 that "helpfully" pops up a list of previously typed console commands every time I try to type a command. At least on a macbook running chrome, it takes over the focus of the keyboard and when I think I'm hitting ENTER on my newly entered command, I instead find that instead I sent "M1" or something else destructive.

I'm using the console. I'm using a duet board. I'm not an idiot. I don't need nor want some "helpful" crud messing me up while I'm trying to watch the printer and type commands.

If nothing else, please provide a switch to disable that mess.

@chrishamm

Many of us are (still) using Duet 2 boards and RRF2. We've been warned away from having too much interest in RRF3 "until it becomes stable."

Now that it's stable, and this being the official announcement thread, can you please provide a quick statement describing "What's New in RRF3 for Duet2 users"?

Perhaps a subtitle of "Reasons why upgrading might be worthwhile."

Thank you
Gary

In all fairness to @gnydick, things with RRF2 have kind of been dropped for a significant amount of time (relative to timelines in years past) in order to progress with RRF3 and Duet3.

For example, there's a known delta calibration bug in the last "released" version of RRF2 (2.03.) That bug was fixed within a month in an RC (2.04RC1) 3 months ago. Since then, there's been no visible activity for RRF2. The RC bug fix hasn't been released as 2.04, and there's been no other RC or beta.

Another example is DWC2. Until just a couple days ago, I thought development on it had completely stopped while it was in RC status. It seems it's finally been released outside of RC, but it feels like the changes between the last RC and now only are for RRF3. There are still outstanding bugs with it that are unfixed. (I'd really like to download a gcode file without having to wait 2-3 minutes before the download starts.)

All that being said, however, please keep in mind that RRF (and DWC) isn't a paid product. It's free and open source. The only thing being paid for is the hardware. Anyone is free to grab the source and fix bugs on their own. David doesn't get paid by us for firmware updates, and the fact that he keeps providing them for free is, to be honest, amazing. If he wants to use his time to work on RRF3 or just to play tiddlywinks - its his time - not mine (or yours.)

Would I like to see more progress for the things I personally want? Sure. I'd also like it if the next time David is in the US, he comes over to my house, gives me a free Duet3 board, installs it in my delta, AND ports my RRF2 config over to RRF3 with the new board. (Okay, that's being greedy; I'll install the board myself if David crimps the connectors for me. )

As for being an "acceptable software development practice", you're living in the past. Modern s/w dev practice is to throw as many new features as possible at users, see what sticks, and only fix the bugs that are causing a loss of revenue. (I'm not saying it's GOOD practice, only that it's become the normal practice in recent decades.) I'm extremely grateful that David doesn't follow that pattern.

@garyd9 said in Cura, firmware retraction and M207:

The only problem here is that the duet's M207 expects the F and T parameters to be specified in mm/min while the cura values are in mm/sec. So, the above gcode actually sends something like "M207 S1.5 R0 F60 T20" instead of "M207 S1.5 R0 F3600 T1200" Obviously, retracting at 60mm/minute is a bit too slow.

Can anyone offer any suggestion on how I can get around this? I remember reading once about the ability to create custom gcode's using macros, but I can't seem to find that reference anymore to see if those macros will accept parameters, allow math to be performed on them, and then have the resulting values passed to normal gcodes.

The macro's won't accept parameters. Along with conditional g-code variables, that's on the RRF todo list.

I guess the inconsistency of M207 parameters being in mm/min, but being retained/reported in mm/sec is intentional.

In the meantime, here's what I've come up with to work around the problem. This should be put in the "start gcode" in cura's machine settings:

;Store the cura values in pseudo-variables (workspace coordinates for a workspace that is never used by me):
G10 L2 P2 X{retraction_amount} Y{retraction_speed} Z{retraction_prime_speed}
M98 P"/macros/SetM207" 

Then create a macro called "SetM207" that contains the following:

;use conditional gcode to do the math needed to translate the values into M207 acceptable parameters
M207 S{move.axes[0].workplaceOffsets[1]} R0 F{move.axes[1].workplaceOffsets[1] * 60} T{move.axes[2].workplaceOffsets[1] * 60} Z0

I originally tried to put the M207 line above into the start gcode (instead of using a macro) but doing so resulted in Cura not translating the {retraction_amount} stuff. I'm not sure why.

If needed, the "extra prime amount" could also be stored in a workspace axis offset ( G10 L2 P3 X{retraction_extra_prime_amount}) and then set by replacing "R0" in the macro above with "R{move.axes[0].workplaceOffsets[2]}

Note that I have the Z parameter to M207 set to 0 always. One thing that can't be helped with the current version of cura is z-hop. Cura doesn't seem to consider z-hop to be something firmware retraction is responsible for, so it still emits z-hop commands to the gcode even when firmware retraction is enabled. (I suppose this might be a good thing because Cura gives more control over when z-hop is used instead of just always hopping with any retraction.) Anyway, it works fine if you left cura do the hopping and the Duet to do the retracting.

@Phaedrux his teeth are on edge...

@jrsphoto First guess is that you're too far away from the build plate. If you're using a BLTouch to level, you probably need to reconfigure the trigger distance.

If using RRF3, can't you do it yourself in your bed.g using M291 and object model variables? (I don't know if the manual adjustment / screw turns info is available in the object model.)

@sirus20x6

As @Phaedrux mentioned, that pattern appears to be backlash...

To explain a bit more: If you watch the printer while it's doing the mesh thing, you'll see it moves all along the X axis (left/right) in one direction, then moves back in Y (front/back) and then all along the X axis (left/right) again (but in the opposite direction.) Compare that motion to the image you posted, and you'll notice that all the left to right motions are at one height on the image and all the right to left motions are at a different height. That suggests that the nozzle is at different height depending on the left or right motion... The cause for that in a delta is usually that something isn't moving quite correctly on one of the towers. It might be a belt, a carriage, etc.

Search this forum for "delta backlash" and you might find some useful suggestions. Here's one thread (that I have bookmarked for some reason) to get started: https://forum.duet3d.com/topic/5175/duet-level-bed-and-g29-32

@dc42 said in Why use a Raspberry Pi with a Duet 3?:

If this is important, I think the real answer is to implement a call from RRF to the Pi to get the list of files in a folder, so that RRF can implement M20. I don't think it should be hard. If M36 was implemented in the same way then it would also be possible to start print jobs from PanelDue.

I just would like to add my positive vote for this. It would give much more flexibility in setting up duet 3 boards.

While it's possible to run both HDMI and USB cables to a small screen, the simple fact is that the wiring for the PanelDue is much smaller. There's also the fact that the PanelDue UI is a mature, well designed, simple small screen touch interface that's proven.

Conditional gcode (at least with DSF) is very sensitive to the difference between spaces and tabs for conditional blocks of code. For that reason, if the DWC gcode editor is going to autoindent on new lines, it needs to either differentiate between space and tab characters, or it needs to automatically replace 'tab' characters with spaces.

For example, assume I type the following in the gcode editor. All characters are as typed, with special keys using angled braces (ie: <backspace>, <tab>, <return>):

while true<return>
<tab>echo "test 1"<return>
echo "test 2"<return>

What happens above is that after the line that echo's "test 1", the gcode editor is helpfully auto-indenting the next line. However, it's NOT using a tab character to indent, and instead inserting 4 spaces. The resulting gcode LOOKS okay and with proper indenting, but it's NOT because the echo of "test 1" is preceded by a single tab character and the echo of "test 2" is preceded by 4 space characters.

This results in some very odd things happening when running conditional gcode that appears to be perfect (and debugging it isn't fun.)

Suggestion: Either the gcode editor should copy the characters used to indent the previous line, OR it should re-write TAB characters to sequences of spaces (which is probably easier than re-writing sequences of spaces to tabs.) Or, perhaps it should use it's syntax highlighting to change the background color of TAB characters to make it obvious that something is different...

@sirus20x6
I'm glad that things worked out. For the benefit of others who might search and find this thread, can you please describe what screws you found that were loose (on a carriage? wheels?) and perhaps upload a picture of the area with the loose screws?

While the next person might not have exactly the same issue, it can give them an idea what to look for.

@Phaedrux said in delta auto calibration rams into roof of printer:

Try removing the second M558 H30 entirely and change the first H30 to H5.

er.. no. That's a safety thing to prevent the nozzle from crashing into the build plate when the H parameter of M665 isn't set properly. Instead of having the nozzle move down at the travel speed to z0 + 5mm (and potentially smashing into the build plate), it leaves a larger 30mm gap before running the G30's.

@Hergonoway said in Smart Effector including toolboard-capabilities?:

• why did you choose this ball stud placement? Wouldn't it been easier to "just" offset the ball studs from the smart effector set horizontally to reach the desired clearance?

I've been playing around with the model to see what it might take to get it to fit well on a smart effector. The 64mm spacing that @mrac1 is using does work, but I don't know if that's the "best" solution.

Also, there's more to arm spacing than just the gap between two parallels arms: there's also the gap between the "centers of articulation" (as described here: https://reprap.org/wiki/Delta_geometry#Effector_stability and referenced there as "b".) From that page, there's a theoretical relationship between effector stability, the arm spacing, and "b".

For reference, @dc42's smart effector has an arm spacing of 55mm, and a "b" of 12mm. Using the formula provided on that linked page (Tilt Effector Stability = (Arm space)²/b), the smart effector has a "TES" of ~252.08.

Assuming that theoretical work is accurate (or close to accurate), the effector from mrac1 has a much lower stability of ~134.94. (64^2 / 30.354)

From that, I started playing around in Fusion360 modeling arm spacing, and set thing up so that the "b" value is computed automatically based on the arm spacing in order to maintain a "TES" value of 252.08. (I just force the "b" value to be "( arm space )² / 252.08 mm.") Then I linked mrac1's excellent extruder model on top of the resulting sketch and kept adjusting the arm space until the arms (and arm movement) was completely clear of the lines connecting all 6 ball joints. (My choice of clearance was somewhat arbitrary. Some delta builds would need more space, and others would need less.)

Here's what it looks like with an arm spacing of 74mm. In this case, "b" is 21.72mm.

Note that this is pushing it really close. Here's a snippet showing 80mm (with "b" of 25.39):

So, at 80mm arm spacing, there's more wiggle room, but on some delta geometries where the print area is actually larger than the triangle formed by the X/Y/Z verticals (and therefore carriages), even this might not be enough. (I think some SeeMeCNC machines are like that.)

I also put the "CR" version of the Orbiter on my sketch to see how that would fit. Specifically, I used the "CR" version of the oribiter. This specific version has a more centered filament path compared to all other available/published versions. (The "v1.5" that's available for sale would stick out an additional ~9mm.) I rotated the model for what I perceived to be the best fit (with 80mm arm spacing):

One important difference when comparing the orbiter and mrac1 extruder pictures above is that they are shown with different stepper models (when they actually use the same one.) According to LDO specs, the stepper should have a total thickness of 17.5mm. The model with the mrac1 pictures has a 20mm thick stepper and the orbiter model as a 17.0mm thick stepper.

Another important difference that isn't shown at all in these pictures is the vertical height of the stepper. (Due to delta arms and angles, this is important for determining clearance.) The mrac1 extruder has the stepper centered 39mm above the effector. The orbiter extruder has the stepper is centered 18mm, PLUS the height of any adapter, above the effector. (It might also be possible to modify the orbiter model to not need any adapter.)

Hopefully all this typing and snipping is useful to someone.

Take care
Gary

Also, please go into the console for DWC and type the following two commands and copy the results here into the forum. This will tell us if there might be some initial config issue that would be messing up the initial calibration:

M665

M666

(Why use the console and copy the results instead of using values from config files? I have found that getting the "live" data from M665/M666 is more reliable than copying values from config.g and/or config-override.g. The console commands return the values that are actually being used instead of values that are configured to be used.)

@mrac1

I've been playing with the plastic parts for your extruder and last night I tried a test fit of everything. One issue I noticed was that with the extruder mounted on the effector, I wasn't able to attach the smart effector's 2x3 microfit connector. The extruder's plastic was in the way of the little latch on the connector. (Below are images of the area I'm referring to.)

While I can easily make adjustments to the model to make this work, I'm wondering if you encountered the same issue and if so, how you might have handled it.

As a side note for @dc42, on the next iteration of the smart effector, would it be possible to rearrange things so that the inner three mounting holes have a good amount of clearance away from other parts that might interfere with mounting? (This might be easier to accomplish on a combined smart effector/toolboard with larger arm spacing.)

@mrac1 said in Smart Effector including toolboard-capabilities?:

@garyd9 said in Smart Effector including toolboard-capabilities?:

Buying a BMG thumbscrew was a waste for an extruder this tiny

Yes, a M3 screw is provided here

I ended up finding an M3x35 that can work with the spring. It's probably not needed, but it makes me feel better.
After initial setup, I calibrated the feedrate on my setup to 698.4 steps/mm, and left jerk/accel/current at the values you suggested above. (That little LDO motor is impressive.)

One other change I made with your model was the shorten the bottom of the filament guide and motor mount by 2mm (and then reshape the bottom of the filament guide to fit around the heatsink nut.) Then, because all the exact dimensions are there in fusion360, I made a little tool that lets me cut a piece of PTFE to the perfect length to go up into the extruder (from inside the E3D heatsink.)

I ended up using a 74mm arm spacing. I could have gone as short as 65-70, but 74 made the smart effector adapter easier.

I printed a quick XYZ calibration cube, and it looks better than the Zesty Nimble ever did in terms of consistent extrusion, and no ringing/ghosting. That was sliced with old retraction settings (1.5mm@60mm/sec with a retract prime speed of 20mm/sec.) I also still have pressure advance at 0.04.

I'll need to sit down and recalibrate retraction, pressure advance, etc.

In the meantime, here's a couple more pictures. The first is your extruder mounted and working....

...and the other is a quick short of three XYZ calibration cubes. From left to right, they show your extruder, a titan extruder (with pancake NEMA17) hanging from a (not smart) effector, and finally a Zesty Nimble v1.2. The nimble shows inconsistent extrusion (that actually looks good compared to the nimble v2), and the titan shows obvious ringing. All three show bad retraction settings on the starts/stops.

Thank you again!

@FB24k2

Sure thing. I'm not sure how complete the fusion360 export is, but the plastic parts to print are in the main component.

For just the extruder, you need "idler lever", "motor mount", "front bearing idler bracket" and "filament guide."

If you use my modifications to the parts, the motor mount requires 0.5mm thick M3 washers to be between it and the smart effector (one for each screw.) (The original model from mrac1 had spacing built in.)

Assuming Fusion360 parameters are intact in the archive file, "BearingHoleDiameter" can be made slightly larger than 8.1mm. I found this was needed when I printed in ABS, as the bearing holes were too small (and forcing the bearings in would damage the ABS.) I used 8.3mm for ABS and the resulting post-print holes were ~7.9mm (which gave a nice snug fit for the 8mm OD bearings.)

"BrassInsertDia" and "BrassInsertIndent" slightly change the 2 holes on the bottom of the motor mount where the brass inserts should go. The intention was to allow me to better line up the inserts. It didn't work out very well.

The remaining parameters relate to the "effector adapter" piece. ArmSpacing is self explanatory. DesiredTES relates to the "TES" parameter I discussed earlier in this thread. MagBallMounting parameters should probably be left as-is. One is how big of a hole for the magball thread, and the other is how much flat space is needed to secure the magball.

The "PTFE Size Guide" is intended to be printed and placed on your smart effector (assuming the enter heatsink/hotend is assembled and attached.) Then put a piece of 4mm OD PTFE tubing through the smart effector into the heat sink as far as it'll go. Thread the size guide on top of that, all the way against the smart effector. Cut the PTFE tube flush with the top of the size guide, and it should be within 0.5mm of perfect.

Finally, please forgive the absolute mess I made of the fusion360 project. I'm hardly fluent with it, and sometimes I just kind of shove things together and hope they work.

Here's a link to the fusion360 shared from my google drive: https://drive.google.com/file/d/1d7YBo-knfZ-HGiYp8PYGQUGXExMkRIlC/view?usp=sharing

@nurbie said in Smart Effector usable w/o carriage set-up?:

Is the Smart Effector usable for Z touch-offs/calibration moves at the nozzle without the carriage inputs?

Absolutely.

The Smart Effector is designed to be used on a delta with 55mm arm spacing and magball arms. If you decide to use magball arms, and are okay with 55mm spacing, you can create your own carriages, as long as they also have 55mm arm spacing.

As well, if you need a different spacing, you can create some kind of adapter for supporting the smart effector that has a different arm spacing, as long as the spacing on the effector adapter matches your carriages. (I'm currently using a smart effector adapted to 84mm arm spacing.)

However, being that you mentioned the Rostock, I'd suggest taking a look at this product: https://713maker.com/en/rostock/duet-smart-effector-adaptor

My understanding is that the above linked adapter can be used to match a Smart Effector to most SeemeCNC delta printers.

I don't know if it's the proper size for your Rostock MaxV3, but I have found that company to be very responsive to questions made from their "contact us" page, and I'm certain that they'd be happy to help you.

@yonkiman said in Print Times - Layer & Filament Not Working:

I actually noticed the same thing, but with Simplify3D. It used to work, and I don't think I changed any relevant settings in S3D, but layer and filament have stopped working, somewhere between firmwares 1.2x and 2.x.

If you're using S3D 4.0.0, upgrade to 4.0.1. There's a bug in the earlier version that can append a few megabytes of null characters to the end of the gcode.

See this post for more info: https://forum.duet3d.com/topic/5572/it-s-out-reprapfirmware-2-0-and-1-21-1-released/80