I have no idea why, but the cause of the described behavior was the M84 E0 on bed.g. Drivers are assigned correctly on config.g and judging by all else, the board behaves as it should. However, running M84 E0 disables Z0 as a result. I tested this by running M84 and G28 in sequence on the console, same result as them run on bed.g happens. Maybe this is a firmware bug? Like I said, I have no idea. I can write a book but can't code for the life of me. But I'm glad it works now. @dc42, thank you for your time.

After the problem is solved, but thought I'd pass this on. "Normal" machine threads are cut at an angle of 60 degrees, so when you print, you've got a lot of overhanging perimeter. Also as the thread prints, each layer shape in the threaded area is exaggerated at the farthest overhang (look at a layer in the slicer). The result is a risky edge that often curls up (at least mine do). One answer is more cooling. Another is to lower the filament temperature as much as possible, because it improves cooling.

If I am3D printing both the male and female threads, I modify the thread profile to eliminate the 60degree bit. The easiest way (for me) in Fusion 360 is to make a male "tool" body to cut female threads, and a male "tool" body to cut the female threads and use those tools to subtract out the material I don't want. Tweaking the threads is the "big trick", easiest explained by an example of making a threaded hole. I make the tool by creating a cylinder that fills the hole that will be threaded this is a new body in F360 lingo. Then I scale that body to 66.666% along the axis (make the plug shorter). Then I use F360 to apply standard threads to this body. Then I scale it again in along the axis, this time by 150%. Now it's the length of the original plug and the threads have been stretched so their thread angle is close to 45 degrees, an easy overhang. Last step is to do an F360 "combine", but cutting, not joining. Also, don't delete the tool bodies. The female threads in the hole are done. Now take the tool and scale it again, this time in the X and Y dimension. The scale factor depends on the the diameter of the plug. I shoot for a reduction of about .2mm per side, so maybe 98% might be typical. This scaling makes the male threads slightly smaller so they'll fit better. Now do another f360 combine, but joining to a stub on the male part. Done. I think it takes longer to write how to do it than doing it.

Round 2 was a success!

lower.jpg

Or mostly a success. Definitely a usable part for initial track testing but the print does have some blemish areas.

I added Z hopping at 1mm so there was a ton of z motion going on but it did not affect the print time that much. The Z motor was a lot hotter. I may have to tune the retraction settings now as at some points it seemed to be depositing a tiny drop of material, z hopping to a couple mm away, and repeating for 30-50 times in a row. I am not getting any blobbing or stringing issues, so likely have some margin to reduce retractions.

The added z motion did accentuate the instability of really tall (500mm+) and slender support structures, as you could see them swaying back and forth a bit. Once the printhead was printing on them the motion was quickly damped, but it has a noticeable effect on surface print quality. I think the fast accelerations of the printer are causing problems when the center of mass of the printed plastic for an island is not over its center of support, so when I create these new CAD supports will try to either prevent that situation or try to give the added bracing some torsional stability. I found that adding 1 perimeter wall option to the support generation adds a lot of stability to the support islands, but it also greatly increases print time and support removal difficulty.

inner-supports.jpg

I think most browsers should play this video: https://www.instagram.com/p/CfKd1oqDCpV/

The part ran with a bunch of Cura generated supports around a bunch of 3 pass wide brace walls that were added to the CAD model in Creo. The uppermost horizontal walls were a bit wonky as a result of my added walls ending too soon and the Cura supports wobbling a bit. This wonkiness stopped when these islands were merged into the overall part perimeter, which was pretty stable due to the CAD added bracing.

hm-1.jpg

So these parts are all good enough for initial assembly, dyno and track testing, but there will definitely be a round 2 once that all happens. When I do this part again (and actually for some other parts too), the supports will be revised to something like this:

inner-rev3.jpg

Basically, after orienting the part I will take the edges that are above the build plate, drape them down to intersect the build plate, then thicken them to 3 print passes. This will eliminate any isolated islands on the print bed and it will also convert the part from long, spindly and unstable fingers and supports to a stable closed profile with few supports. The rest of the fairing is about 5mm thick, and done with 2 walls and 10% gyroid infill. The result is that the added walls are 'solid' where they merge into the part so can be trimmed off without breaking through to the infill. The added part volume seems to be a decent amount less than the support structure it is replacing, and because they are usually long smooth print moves can be done at a consistent realized 150mm/sec, so also print decently faster than constantly reversing support movement.

I found that cutting these style ribs off was pretty easy with an oscillating handheld cutters (dremel mm35). No melting and with the right blade shape (standard one included in package) it was easy to get near flush cuts. No nicked fingers, either!

This last print was 52hrs. The printer has been going almost continually since 5/16 with no more than a few hours between prints. I've gone through about 28kg of filament so far. The only failure was the filament stepper fan, which burned out. Turns out it was a 12V fan running at 24V. I may add some shielding between the chamber heater elements and the build plate, as on the previous failed print it did seem that the heater on one side caused some of the single wall tree supports that were directly opposite it to sag. Other than that, the printer has been mechanically sound, which is great.

@owend
Do you get a stall detection message flashing in the console?
When a stall occurs or if you force a stall, do you get a message in the console?

@joeko said in Duet3, wiring endstop to iox.in and also to iox.out ?:

or do you mean why between xxx.out and ground ?
if so than offer the wirring guide this (between xxx.in and ground) ...or am i wrong ?

Sorry I wasn't clear.

Why would you want to use an output for an input given the numerous inputs usually present on a Duet?

Frederick

Are you able to control the fan speed if you send M106 P1 S0.5 H-1 ?

@alijambo73 said in Duex5 E stop headers not working:

One other question, If any of the sensors do not detect filament it will pause printing even if it is only using 1 extruder. Is there a way to configure it so that only the sensor on the extruder being used will trigger the pause?

If you're using tool changes you can disable the sensor in your tpost and only enable it in tpre. That way only the active tool is monitored.

Thank you. Submitted the email.

@mac said in I could use some help:

X goes side to side, typically left to right, so, the x-endstop is on the left, versus high or low. Y typically goes forwards and backwards, with the stop typically being at the back, so back is how it's described. Z goes up and down, so that enstop is at the top or the bottom of the axis. Left, right, back, front, top, bottom, those are easier ways to describe and understand the position of endstops, I think.

Got it.

But consider this, every linear axis has two ends. The positions on the axis range from some minimum value to some maximum value. The endstop term "low" corresponds to the minimum end. The endstop term "high" corresponds to the maximum end.

These terms apply regardless of the orientation of the axis (left and right, forward and back, up and down).

They apply regardless of where the minimum and maximum ends of the axis are. If, for some strange reason, the left most X axis position was 500 and the right most X axis position was 0 the terms "low" and "high" still will be correct.

Wish me luck!

I hope all goes well.

Don't hesitate to ask for help.

Frederick

@gefidalgo I always favour fixing the root cause wherever possible, but I appreciate that having already built the machine, you might not want to go down this route. But I'll put it out there anyway.

I too use a large aluminium plate with removable glass surface and never had the problems that you have experienced. Admittedly it's somewhat smaller in X and Y than yours being 400mm x 400mm but it's twice as thick at 12mm. So I have a slightly higher volume of material but more importantly, the ratio between surface area and thickness for my bed is 3 times higher than yours. Also, my bed has 12mm of semi-rigid insulation on the underside which speed up the warm up time slightly but significantly lengthens the cool down time. So a thicker aluminium plate with insulation might help.

The other thing which might help is simply changing the mirror for float glass. You haven't said what thickness the mirror is but I use 6mm float glass and have never had any problems in the 6+ years that I've been using it. Even if I take it out of the chamber and let it cool fairly rapidly in ambient air which might be 60 degrees cooler than the plate. In fact, that's the main reason I use a removable glass build surface - so that I can swap plates and start printing again with the minimum delay. If you do try this, don't make the mistake of getting the glass toughened - that toughening process will distort it (as I found out).

@gabi68 Do you have the correct Z offset in your G31?

@tinchus To make sure the printer is homed. I also have this in start.g, so it shouldn't run in G32 during a print, but the G28 Z is in there, since the bed is heated up before running G32 and G29/mesh.g for a print. It also allows testing of the G32 without additional steps.

@deckingman said in Writing and Testing 'Stuff':

Or an IP camera

… with an emergency button, please 😊

@index4d said in Error: Attempting to extrude with no tool selected.:

But pls make a suggestion if I should describe my plan for a tool switch.

… Which lets me ask whether your tool switching works, at least 'somehow'. I don't have the faintest idea what mechanism you use to alternate between T0 and T1. In my case, I use tfree to move a tool out of the way and tpost to activate it. You use tpre instead, but at least the M116 gCodes should be in tpost. As far as I can see, you happily mixed up commands to release one tool with others to prepare the other one: it's better to keep them separate. Did you read and follow the - well written - guidelines?

After you got your gCodes sorted into the proper macros, it's time to test them, one at a time. If you call such a macro from the command line with

M98 P"myFancyMacro.g"

, you receive messages on syntactical errors. In addition, you can focus on your coupling mechanism - I think you call this with

M98 P"/macros/Coupler - Lock"

Did you test this one?

BTW, there's yet another way to test a macro: comment-out all lines you don't need in the first place, e.g. some moves and all heater commands. By this, you can add functionality step by step, which makes it easy to spot problems.

Some variance in the vibration peaks don't matter much due to the damping factor of the IS algorithms. You should measure your second head too to make sure that two X belts have about the same tension as well.

@tristanryerparke then there's something wrong. What version are you running?

@cthulhulabs My DeWalt is configured as a spindle and is automated via a relay. So I can use M3 to start it and M5 to stop it. (Already modified my Vectric postprocessor for this)
I added M3 and M5 commands into the surfacing loop at line 89 and line 148 of the macro.

T1 ; selects the spindle Tool 1

M3 S17500 ; starts tool

@droftarts yes, I am aware we have it for deltas.
I think an expansion to match Marlin would be a good addition

@signpostman

I haven't read this entire thread so I don't know what you mean by "Is there any other way to connect my ClearPath Servos to the Duet 3 main board?"

If you have specific questions, you should probably start a new thread with those questions and I'd be happy to help.

@mac Yes, of course I watched the video! That's what I was commenting on.

the home point for this Xvico was the FRONT, LEFT, Corner

Sorry, but I'd say the nozzle in the image below is over the back right corner, viewed from the front of the machine (ie reading the text on the bed the correct way up, left to right). If you've set the endstops up as maximum endstops (ie bed maximum position is set when homed, like X200 Y200), then fine, but if they're set up as minimum endstops, the machine coordinates are rotated 180 degrees. Just for clarity: the X axis is (usually) the one that has the nozzle on it (goes left/right), the Y axis is the bed (goes forward/backward).

35576a7e-51a9-41ba-a226-9b62ef8e4ffd-image.png

I copied the M569 commands from the config.g you posted a few days ago. I probably should have said to check the 'S' parameter in them (that's the axis direction)! It's the D3 that silences the motors. It should not have made the motors move, or done anything to the fan. I thought the squealing was motor coil whine, not the fan! Because it stopped when you moved an axis. If it helps, add it to the M569 commands in config.g. Maybe post your current config.g in this thread, too.

Why is homing the x-axis telling the z-axis to go up and then down?

Because homex.g tells it to. Usually it's best to lift the nozzle before homing, just in case it has stopped on the bed, or stopped during printing, so it stops the nozzle being dragged along the bed. Lifting it 5mm is normal, and it usually drops it again after the X (and Y does the same thing) has been homed.

Ian

@oliof I think it's an operator / config.g writer error.

I mean: wiring wise, what's there to screw up? The box I printed had 1 and 2 next to the holes where the cables go. The cables are keyed, as are the receptors on the board. I don't think I screwed that up (but it's possible).

The problem is me. I've just never done any coding. Duet's documentation is good, but it seems to ignore the amount of coding must do to make the board AND the printer actually do anything.

I say that not with malice, but out of my frustration. And my high blood pressure, which is killing me today.

Mark

@arnold_r_clark well said, even though I'm coming into this thread a few years later. I actually paid someone on Youtube to do some videos about Klipper when it was first coming out. But it was hard for them to make a video back then, and klipper was in it's infancy.

Anyways, if you read this, I appreciate your honesty and intelligence.

Mac / Mark / Corlissmedia (2.0).

@phaedrux Yes, I think I've read quite a few of them at this point.

I sent you a video link. If you've got 40 seconds, I hope you'll watch it.

Mac