Posts made by engikeneer

@yoshimitsuspeed

I'm not quite sure I follow the excel you show as you seem to have a 4th order polynomial and an exponential plot, but no 2nd order polynomial (quadratic) which is what NLE actually uses.

However, one thing that is clear is that you need ~1.56x more extrusion at your max speed than min speed you tested (100/64). First question: is that really true?

Second, what NLE command do you actually have, and have you specified an L parameter? NLE is limited to a maximum factor of 1+L, and L defaults to 0.2. If you haven't specified one, you won't be getting anywhere near the amount of NLE you need at higher speeds (1.2 is a lot less than 1.56). My guess is this is why you are having issues with your e-steps as anything above ~7mm/s would not get enough NLE based on your excel.

Link to the docs for ref, but I guess you've already been there!
https://docs.duet3d.com/User_manual/Reference/Gcodes#m592-configure-nonlinear-extrusion

@wesc do you actually need the backlash compensation in Z?

Typically the weight of the bed will always keep the gearbox loaded on one flank even when you reverse directions. You'd only go across the backlash if you are using z accelerations approaching 10000 mm/s^2 (I.e. 1g) where you are outrunning gravity. Granted a bit of friction might make that number smaller in practice, but I doubt you'd be anywhere near those limits if your motor has to run through a 10:1 ratio.

It's different on X/Y axes where you don't have gravity always pulling in one direction. I know I've seen many printers with 'anti backlash' nuts on the z lead screws, but they just don't make sense to me from a physics point of view!

@Skyhawk757 do you mean that your switch is open in the bottom half of the axis, and closed in the top half? (Or vice versa)

In that case, I think you can do what you want, but will need to redefine your endstops in your conditional between active high and active low, as well as the direction in which to travel for the homing move. Use a standard homing move, then G92 Z___ to set the z height to whatever the switchover height is.

The endstops look for the state, not a state change, so if you set them as active high, and the switch is already open, then it will think it has hit the 'endstop' and so stop and mark the axis homed which is not what you want in this case.

As @infiniteloop says, this methodology is a little non-standard and does carry some risks, but I think you should be able to work it.

If you have specific questions on the implementation, then probably best to post what you've got. I'll admit my knowledge of conditional gcode is a little lacking, but I'm sure someone else would be able to help.

@Tinchus that delay is not required to use the BLTouch. However, the reason it is there is because you are also calling the alarm reset command before homing. This will reset any internal error on the BLTouch (i.e. when it flashes) but it takes a short time (100ms) to clear, hence the delay. Your homing will fail if you try probing wile the BLTouch is in an error state.

I don't use that in my config, but means that occasionally I have to manually reset any error on the BLTouch which admittedly can be a pain!

@fcwilt first, I'd take a couple of measurements and make sure they are consistent. Be cautious over the scale of the graph - it autoscales so one taller peak will make everything else look smaller!
Next, play with the different shapers in the tool. Some cover much wider frequency ranges than others you you can hit several peaks in one. Only trouble with wider coverage is it filters out more of the acceleration, so it will be a little slower printing. I use one of the wider ones with no issues mind!
Work out a few plausible ones, apply them and record a new measurement for each. Compare them and see which ones work best.
Finally, test prints. There's a few input shaping test prints around. You can vary the shaper or frequency applied every 10mm or so and use it for your final selection.
Bare in mind, input shaping is a useful tool for combating printer resonances and ringing, but it is not a magic sauce that fixes everything!

@bernardomattiucci I think you need to read up on heat creep in filament as it sounds like that is your issue.

Basically, over time heat creeps up the filament in the extruder. When the filament gets warm, it expands a little. If it expands too much, or even worse melts in the heatbreak, it can cause friction in the heatbreak and so cause a blockage.

In normal printing, you are constantly pushing fresh filament through, so no big issue. When you retract, you pull warm/hot filament back up and so it gets worse. Lots of retraction and travel means lots of time not extruding fresh plastic so it builds up more heat and is more likely to cause a blockage. Cheaper filaments may be more susceptible to this, or are just weaker hence the powerful hemera just strips it when things start getting stuck.

I would check your cooling setup on the hemera. Are you using their standard fan? Is there enough room for airflow around the heatsink? Have you set the motor to the correct current? Is the hotend assembled correctly, with suitable thermal paste, clearance to the heaterblock etc. Have you got a silicone sock over the heaterblock?

@damaged_goods sounds to me like replacing the pin wasn't successful in fixing the BLTouch, so it's probably time to buy a replacement. There's not much you can do on the Duet side if the probe itself is broken!

@Inlinebrother you can try it, but if you're getting tilting of the head which varies around the bed, then that effectively means your probe z offset changes with position, so no amount of re-probing will help... really you'd need to focus on the mechanical issue or move the probe closer.

Having said that, multiple probe attempts is always a good thing as it should make the results more repeatable, and helps avoid any odd spurious false probes getting through.

I guess if you're able to print fine without mesh compensation enabled, then that's also a good thing! It's only really there to compensate for bent beds or saggy gantries after all

@Inlinebrother yes that is the best way to do it. Set your probe offset relative to one nozzle (say the left one), then set a tool offset for the other (right nozzle). That's how I do it on my chimera. (Edit: you may then have to set the nozzle offset to zero in the slicer depending on how you set that up, else it will double account)

Also note that any tilting in your carriage as it moves around will be magnified by the offset, so minimising the offset is important when designing your print head. Difficult task with two nozzles though!

Also worth checking if the weight of your wiring causes the print head to tilt in one area. Again, with two nozzles you've got twice as much stuff in that bundle, and it will throw off the mesh compensation.

If you're still struggling, it may be worth trying manual probing (probe type P0) and comparing that against your bltouch mesh? It takes time to do, but could be a useful debug to see any differences that point to something in your setup.

Finally, I'm assuming that you've already checked you've got the probe offsets correct?

@aticorpj is it only for the X driver or all drivers?
I would carefully check your motor cables and connectors especially. I had one of mine melt and fail quite spectacularly after many years of use. Once a connector contact or crimp gets dodgy, the resistance goes up and it heats up, then things deform and the cycle gets worse until it fails.

If it is all drivers, it may be a short circuit somewhere. I'd be carefully checking for anything that gets warm to the touch when you power the machine on

Around the house, the most useful item I've printed was a chopping board holder designed to snuggly fit each of our different boards and stop them falling over in the cupboard. Now half my firends and family also have a set!

Outside, I have an old Reliant Scimitar as a project car which had a lot of non-standard parts on it and has needed several 3d printed items. I started with simple gauges on the dashboard, but have now got a few bits in the engine bay including the intercooler mounts and the throttle mount on the engine (both out of some high temp filament). Next big item will be a full intake manifold which I'd probably then fibreglass wrap for extra strength, toughness and sealing. I've been quite impressed with how the 3d printed bits have held up with the abuse the car gets when I take it on track!

@dc42 yeah thats exactly what I did (was following your blog post actually which was helpful!)
After doing 64 of them, making sure each of the pairs were soldered at the same length, with a reasonable twist left and didn't bunch up in an awkward place in the tool support, I got pretty good, but had burnt my fingers more times than i can count. At a typical labour rate, those cables would have cost more that all the Duet boards on the printer with how long I spent on them!
Having said that, the printer is much neater and better setup with the CAN boards. Being able to pull a complete tool off the printer by only pulling out 2 plugs and a couple of screws has been very handy at times. I certainly wouldn't go back to non-CAN in the future, but I would spend a fair amount of time (and money) to try and avoid the solder sleeves if it was building a new printer again.

@T3P3Tony I run a (mostly) standard e3d toolchanger with a Duet3 Mini and 4 toolboards off a distribution board (plus the 'tool' who runs it ), so probably fit the current setup quite well.

I've raised it before, so I'm glad to hear you're looking at the wiring-up side. The hardest part of setting up my toolboards was having to solder sleeve tiny ZH pigtails onto the CAN lines, then having to do it all again after I started having some random issues I attributed to a dodgy joint I couldn't find so replaced all of them. I get the need for a tiny connector on the toolboards, but the definitely not the distribution board end. Larger connectors like the main boards would mean most people could just crimp that end. Maybe it might make sense then to even provide long lengths of cables with ZH connectors on just one end for people to cut and crump to size?

Back to the main question... I'm not sure I could/would extend my machine past 4 tools. Maybe an extra board for some ancillaries like a wiper or the toolhead, but I would probably just wire that from the RJ connector on the distribution board and feed it power from one of the other boards. Or more lively rjn it straight from the mainboard if I had enough IO left.

@jens55 for the PETG one, have you dried your filament? It can absorb a lot of water which will give rough bits that then affect the next layer etc, plus curling, poor adhesion and other print defects.

ABS one might be cooling depending on where your fan points?

Edit: I'd also look at where your seam is. Seems like a lot of them are starting on an overhang which is not great...

@axiom you don't. The shapers cover a frequency range, so if you pick one that covers a wider range and set it to be in the middle of the two frequencies, it should help both. You can't input shape different axes with different frequencies

In the second image you posted, you can see frequency range the ZVD shaper is filtering as a green dashed line. Play with the others in the plugin and see what works.

@axiom

M593 P"zvd" F49.4

Becomes

M593 P"zvdd" F49.4

Or

M593 P"ei2" F49.4

Or whatever else. Its really that simple. As DC42 says, you may want to tweak the centre frequency (F parameter) so that it better covers both of your peaks.

Basically those other shapers have a wider frequency range than ZVD. You'll see that using the shaper tool when you switch between them!

@Chriss what you want is to use G53 in front of yiur G1 commands in your toolchange files. That means it considers the G1 command to be in machine coordinates, not tool coordinates, so doesnt apply the offsets.

More generally have you read up on the E3D toolchanger and motion system? You could probably get 90% of the eay there with your comissioning by just cribbing their config files and setup guides. No point reinventing the wheel! There are probably similar materials also available for the Jubilee and other toolchanger printers if you look too.

https://github.com/e3donline/RepRapFirmware-SD

https://e3d-online.zendesk.com/hc/en-us/sections/6186313376413-ToolChanger-Motion-System

@breadandbudder check you have assembled the hotend correctly with a decent clearance between the heater block and the heatsink. 9 times out of 10 when I've seen V6's that can't hit temperature it's because the heater block is clamped up tight against the heatsink.

If you're not sure, you can post an image of your hotend here.

Also agree that I'd only really trust the proper branded heater cartridges. I've played with cheaper ones in the past and they are generally smaller and less round so don't clamp as well in the block. I had one fall out during a print once, though will never be sure if that was poor quality part or poor quality assembler...
30w should be plenty for what you need, but a 40w would also be fine. Much above 50w on a v6 can get very hot if you get thermal runaway so I would avoid those unless you are using copper blocks etc to reach real high temperatures (400C plus)

@Ralms so basically, when you called G30 from console, Z was already homed, so the problematic G1 line to move an unhomed axis in your deployprobe.g wasn't an issue? But when calling homez.g with just a G30 in it, the z axis is marked as unhomed before deployprobe.g is called and hence you got the error. Your problematic command was to move z anyway so x and y don't come into it.

My point is that I think the behaviour you're seeing there is fully expected and 100% explainable

@Ralms note that when you call a homing file it first flags the axis as unhomed. My guess is when you did it from command line you had already homed the z axis?