Posts made by ChrisP

Yeh, using the Atmel-ICE with Atmel Studio to program the .elf from Eclipse was super simple, it just seemed a bit overkill and I wondered if I was missing something. I can set breakpoints in Eclipse but they're not handled properly and while execution is halted and can be resumed, as you say variables can't be read.
Nevermind, it's useful as is anyway. I shall get on to getting it hooked up to the Duet and hope I don't need to do too much debugging

My Sammy-C21 and Atmel-ICE arrived today and after some fiddling I've managed to get the latest version of the Duet3Expansion firmware built and flashed using OpenOCD through Eclipse. However, I'm curious to know if others who are using the Atmel-ICE are using it with Eclipse and whether they've managed to get it working properly as a debugger with breakpoints etc?
I'm pretty sure it's flashed fine as I have the rapid flashing light indicating no CAN connection (I need to go and dig out some RJ11 to hook it up to the Duet3 to be sure), but having the ability to debug properly would be nice.

I've just had an issue where on starting a print I noticed that nothing was being extruded. While the correct tool was selected, the active temperature was 0. I discovered that it was because the config.g script wasn't being executed for the filament after the T command, similarly M703 did nothing either. It seems that the filament name was truncated in filaments.csv to 31 characters (presumably 32 with a null terminator?) so while the filament was stored with the originally specified full length name, the system couldn't find it after. While I appreciate 31 may be enough for most users, it would be appreciated if the limit could be increased. Either way, I feel this is a bug as it's possible to specify a name longer than parts of the system can handle.

I've been playing around with the pause & resume macros and filament setups to try to improve mid-print filament swaps and filament run-out conditions.
Having read a previous post (here), I tried adding a T-1 to the end of pause.g and and a T R1 to the beginning of the resume.g.

While the pause goes okay, on resuming (having not done anything else like changing filaments etc.), the T R1 doesn't seem to re-select the tool and while the head moves hack to position, I get the old "no tool selected" and nothing else moves. Am I missing something silly, or is it a bug? I'm using a D3/SBC with DSF 3.1.1.

; pause.g
M83				; relative extruder movements
G1 E-3 F2500			; retract 3 mm
G91				; relative moves
G1 Z10 F5000			; raise nozzle 10 mm
G90				; absolute moves
G1 X0 Y120 F5000		; move head out of the way of the print
G10 R0				; set tool standby temperature to 0
T-1				; deselect the tool

; resume.g
T R1				; re-select the tool that was active prior to the pause
M703				; make sure config is correct & loaded
M116 P{state.currentTool}	; wait for the tool to reach active temperature
G1 R1 Z2			; move to 2 mm above resume point
G1 R1				; lower nozzle to resume point
M83				; relative extruder movements
G1 E3 F2500			; undo the retraction

While its less of an issue, G1 R# commands don't seem to behave exactly as documented in the wiki either. G1 R1 Z2 does just move Z down to 2 mm above its pre-pause position, but G1 R1 moves X, Y and Z, whereas the documentation states that "Axes not mentioned are not moved" - is there an exception if no axes are mentioned? I think this must have originally come from an example somewhere and it just worked.... but should it?

@dc42 Ah, yes! I looked at those when you tweeted about them a while back but they weren't available with the Duet bootloader at the time. Now they do, I've just ordered on to have a play with

It is possible to do this - I've done it (ish). But you quickly run out of sensor channels (I'm currently looking at ~20 heaters/sensors oveall). Using expansion boards is possible, but you need quite a few to cover all the inputs.

A good while ago, @T3P3Tony suggested using a MCP3208 to make an SPI daughterboard similar to the PT100/thermocouple ones. I bought some but haven't yet had the change to build the board. @AJ-Quick has already done work to use these for current loop sensors (https://forum.duet3d.com/topic/15508/m308-and-current-loop-temperature-sensors) but again, the lack of time means I haven't had a chance to play.

I see large format/scale systems becoming more popular so it'd be great to see a CAN expansion board with just 16+ pairs of outputs and thermistor inputs at some point.

@oozeBot I may be misunderstanding something here, but is your overall aim to be able to use the UI to be able to select a filament from a list of available ones and then have the temperatures etc. set based on the material chosen? If so, this is already possible using the filaments individual config.g.
That said, this doesn't work for loading as config.g isn't parsed pre-loading and isn't typically useful for un-loading as usually you'd want a lower temperature... in which case the the load and unload temperatures can be put in load.g and unload.g.
For a unified macro, then yeh, you'd just need to match filament names against the OM. In which case, I think the only current restriction is whether the filament name field is populated pre-execution of the load.g script.

Interesting idea, but what information would you expect there to be that isn't already? I currently have a hacky work-around where similar material types call generic PLA or ABS or PC etc. load/unload macros, but are you effectively suggesting something along the lines of having a single macro with some sort of conditional if/elif/switch statement to set the relevant temperature and speeds? That would certainly be a cleaner solution!

I've just noticed that the OM does hold info on the currently loaded material in move>extruders>filament which presumably means this could be used for unloading at least. It'd be interesting to know when this field get populated during the loading process. If its before the load macro is run then I guess it can be used for loading too.

While I know this topic is a few months old now, I'm not sure whether it was decided that the proposed solutions were sufficient to be included in the next FW release. It's still a feature I'd love to see updated to enable slicer-based enabling of the feature.

@dc42 said in Cancel individual objects on the build plate:

@ChrisP said in Cancel individual objects on the build plate:

It might also be useful to have M486 report what the current object is that's printing...

Good idea! It's already available in the object model.

EDIT: except that it might not always be entirely accurate, because the moves in the print queue lag the object tracking.

Presumably though, the error will only be during travel moves and the first loop of an object then? So it would only be an issue if you happened to get unlucky at the point you queried or if the layer times for objects were particularly small...?

What would eventually be nice to see is an Objects tab under the Status tab in DWC where the bed area is plotted using the the limit info from config, then bounding boxes of the objects are plotted over that with a list of all the known objects on the bed and the current one highlighted.... dreams of the future

@dc42 From DWC...

It might also be useful to have M486 report what the current object is that's printing...

@dc42 Yes, I ran M486 from the console tab in DWC. I will try again now just to double check...

@dc42 said in M200 Volumetric extrusion bug:

@ChrisP said in M200 Volumetric extrusion bug:

Is this also true for G90/G91?

Yes.

I see no reason to have a way to set volumetric extrusion set not not globally. Whether volumetric extrusion is in use or not is a property of the GCode file being printed. You may have some GCode files that use volumetric extrusion, and other that don't. OTOH, the diameter of each filament is a property of the extruder.

I think a solution to your issue might be to implement M200 S1 as you suggest, then you can use it in your slicer start GCode.

I think this would work well.
One thought I had - I think I'm right in saying that as M200 is currently only enabled per input, that a macro which is called from the main gcode file that has some E values will be treated as an extrusion length rather than a volume. Presumably with this proposed modification to the behaviour, the two options would be for the user to either provide volumetric E values or disable volumetric extrusion at the beginning of the macro and re-enable at the end?
However, then there would need to be some way for the user to remember whether or not volumetric mode was enabled at the beginning of the macro. When variables are available for meta commands this will be easy. In the mean - time would the best way to be to use a fake axis or fake heater set point as variable storage?

@dc42 said in Cancel individual objects on the build plate:

I've now modified the M486 command so that when it is used without parameters, it lists the objects that RRF knows about. There are new builds of RRF with this functionality at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

Thanks, this works well! One very very minor thing is that it seems to put an extra space at the beginning of each line from line 2 onwards...

Perhaps one for @chrishamm ....
I had previously reported here that a pause caused by the filament sensor resulted in the printer just halting this was with D3+SBC setup. On trying again in standalone, the pause works as expected and can be resumed. Therefore a DCS issue?

@RyanP said in Three printers, poor consistency, questions:

Its quite clear that it is 2 lines and a space repeated. So I will check into what you have described. The pain is, there is no infill space below this. Its between 4 and 8 solid layers making the bottom of an box. So the common answer I always get is increase the number of top layers. They are technically all top layers...or all bottom laters. I have been able to mask it by decreasing my top skin speed to a much slower speed. But that is not the fix I am looking for.

Yeh, if you can't get an even, gap-less layer on the first layer(s), then adding more isn't going to help. Fixing the root of the problem will likely involve a little though, effort & time, but you'll thank yourself for it later.
If you re-print that part and watch not which direction the head is travelling relative to the gaps/overlap, its actually possible to figure out which axis has the issue. Sometimes is easier to figure out by printing a small test part (just a few layers) that has an internal hole as the perimeters will look slightly elliptical oftem with small flats. The axis that runs perpendicular to the flat is the one with the problem.If there are flats in both directions then both axis have an issue.

Regarding the VFR, I followed a calibration guide on here. But it simply talks about the extruder skipping. But what I noticed over the weekend when calibrating my Ender 5 Plus, is the bowden tube moves at a certain point, much sooner than when the extruder skips. So I will be paying attention to that bowden tube movement and use that as a guide that the pressure is getting high to back up the filament.

@Phaedrux's comments about Bowden clips matches what I've heard from others. One thing that also often missed with any Bowden setup is to put the retaining clip on but then to give the tube another shove in while the collar is held up. It's often surprising how much further you can push it in... note that it can make it a bit of a pig to push the collar down if you want to remove the tube as it'll have practically no travel.

I'm absolutely not a fan of the skipping extruder method, particularly if you have a decent dual drive geared extruder like a BondTech as you'll probably grind filament before you notice skipping. Tuning for max VFR is not a thing I often do on desktop-scale printers as I aim for absolute precision than speed at that scale. However, the way I've found to be most consistent is to actually just print a series of test parts. Draw up a cuboid that has some decent length edges, but is fairly short so it doesn't take long, say 50x50x5 mm. The key thing is to make sure the lengths are long enough to make sure your Bowden tube isn't still taking up slack.

Slice it in vase mode with no top, bottom or infill and print one at a sensible, steady speed and temperature. I use 40 mm/s or so for a standard 0.4 nozzle using 1.2 x nozzle size or greater for extrusion width and 0.15 or 0.20 mm layers... so ~3 mm^3/s. For your 1 mm nozzle volcano setup I'd probably start with 0.3 mm layers, 1.2 mm extrusion width and 30 mm/s speed (~11 mm^3/s). Print it and measure the wall thickness - if it's not whatever you set your extrusion width was set to then you'll want to sort that first.

Repeat printing this with increasing speeds until you the wall thickness drops below what you'd consider an acceptable deviation. To reduce the number of prints, you could try a simple binary search methodology. Don't forget though that the faster you print, the faster you'll need to get energy into the filament so at some point you'll have to decide whether you want to find the max VFR for your standard temperature or whether you're wanting to explore increasing temperatures to push the VRF up. Based on what you've said so far, I'd probably save increasing temps for another day once you have some nicely tuned profiles.

Stringing with PETg - I'd put money on the material not being dry.

Cool.
I'm curious as to what you're trying to achieve with that. Is it just out of interest & experimenting? Otherwise, is there a reason not to use M116 to wait for the heaters?

FWIW, for that particular example you can omit the else too

Can you get a clearer image of that top layer? I can't decide if the gaps I see there have one or two (back and forth) lines of extrusion. If it's the latter, then you almost certainly have a mechanical backlash issue on an axis. I don't have any of those printers, but I have a few friends who do and they all has issues with slack belts and all had loose idlers on the x-axis. One also had a loose pulley on the motor shaft. I've also seen this effect reported by people who use steel reinforced belts. Any of this can of these cause backlash which manifests itself as a pattern of a double line then gap in top layers.

I don't use z-probes because I only ever use flat (on the scale of 3D printing) beds. I manually 3-point level the bed to the x/y plane and at the same time I set the z zero position... then I forget about it for a few months. As @Phaedrux said though, you should still be able to probe quite accurately with a BLTouch.
For the first time I had a mechanical endstop wear out last month - one day the trigger point was anywhere in a 200um range. I switched to an optical endstop as a replacement and can only say that I wish the other had died sooner.

If you're unloading filament and seeing long wisps of fine material its 100% because the material is too hot when you're removing. Everyone has their own methods, the cold pull method will work every time, but that's time and effort and I'm lazy. My unload / material change scripts for PLA is to simply heat (or cool) to 100 deg.c and retract fast, then when I load I prime about 10 mm and that's enough for a clean change. For reference, that setup uses a standard E3D v6, BondTech BMG and ~350mm Bowden.

I also agree that your max volumetric flow rates seem pretty high. This can also be seen in your image where you're only seeing over-extrusion near the edges (assuming your acceleration settings aren't crazy). As the head is slowing down towards the end of the path and accelerating again the feedrate will be lower so the extrusion catches up.
How did you go about calibrating the VFR? If you're using a Bowden setup and don't extrude enough length when doing this calibration its easy to get max VFRs that are unrealistically high as the Bowden takes up the slack.