Sorry in advance for what has developed into a long post.... hopefully someone will find it useful or it can be used to improve the object cancellation function.

@bot I'd be interested to hear how you get on with this if you you try with Simplify. While the results (below) are infinitely cleaner than those from PrusaSlicer (my post above) as the object label comes after the retract, I have since discovered other issues - generally minor & none that prevented the print coming out as expected. In this image, as before, Object2 was cancelled first, then later Object1 was cancelled. The others were left to go to completion.

So here are the other issues I found...

1. Simplify still puts some travel moves relating to the previous object at the start of the current object, so if that previous object has been cancelled, unnecessary travel occurs. In the example gcode below there are 5 lines (line #46-50) of travel at the start of Object4 that relate to Object2 (which was cancelled), then the 6th line (#51) is the correct travel to the the start of Object4. See the orange and purple segments in plot below that shows the unnecessary travel.
   On checking later I discovered that these 5 moves were generated because the "Avoid crossing outline for travel movements" option is enabled. So Simplify isn't being sensible here as its treating these as part of the travel to Object4 rather than the travel required to exit the perimeter of the Object2.
   I don't think there a practical way for RRF to overcome this if "Avoid crossing outline for travel movements", but as the retract happens prior to the travel the only side effect is wasted time due to the unnecessary travel.

2. Relating to the previous point, I'm seeing that despite there being a F9000 on the first of those travel moves (line #46 & the long part of orange line on the plot) at the beginning of Object4 (from X38.929,Y45.252 to X80.765,Y66.837), the head moves incredibly slowly - indeed, DWC shows that the feedrate is 10mm/s... ie. the F600 from the z-hop on the previous line.
   I then observe the remaining travel commands (lines #47-51 & the small parts of the orange line and the purple line on the plot) in that short sequence go at the full F9000. Its clear to see as it happens at every layer (and similarly on other cancelled objects). I've been looking at this for a while now and unfortunately I'm wondering whether there might be a bug in RRF where the feedrate isn't being updated in the correct place - @dc42? Or maybe there's something I'm not seeing here? Either way line #46 seems to move at F600, not F9000. I can print again and video if needed?

3. I typically begin all my prints with a skirt. In Simplify3D, when there are multiple processes the skirt for all processes is generated by just one of them - the the bottom image. Since we're using separate processes to distinguish objects, for that one first object that generates the skirt the min & max XY positions that RRF calculates are incorrect as it will be using the bounding box of the skirt instead. After a quick check, the same is true for brims. I therefore wonder if it's feasible to make RRF look for the ; feature skirt comment and de-select whatever object RRF thinks is current? I think that would solve this issue.

; process Object1
; feature inner perimeter
; tool H0.150 W0.430
--snip--
G1 X39.198 Y52.512 E0.0078
G1 X38.924 Y52.350 E0.0085
G1 X38.794 Y52.260 E0.0042
G1 X38.525 Y52.030 E0.0095
G1 X38.340 Y51.840 E0.0071
G1 X38.142 Y51.597 E0.0084
G1 X37.798 Y51.060 E0.0171
G1 X37.626 Y50.715 E0.0103
G1 X37.479 Y50.360 E0.0103
G1 X37.407 Y50.144 E0.0061
G1 X37.312 Y49.859 F1080
G1 X37.190 Y49.371 F1080
G1 X37.103 Y48.914
G1 X37.038 Y48.416
G1 X37.001 Y47.909
G1 X37.001 Y47.888
; feature infill
; tool H0.150 W0.452
G1 X38.236 Y47.816 F9000
G1 X41.993 Y47.816 E0.1058 F2160
G1 X42.293 Y47.816 F2160
G1 X40.293 Y47.816 E-2.7778 F2160
G1 E-1.2222 F3000
G1 Z2.899 F600
G1 X38.338 Y46.274 F9000
G1 Z2.599 F600
G1 E4.0000 F3000
G1 X39.779 Y43.780 E0.0811 F2160
G1 X39.929 Y43.520 F2160
G1 X38.929 Y45.252 E-2.7778 F2160
G1 E-1.2222 F3000

; process Object2
; feature inner perimeter
; tool H0.150 W0.430
--snip (cancelled object)--

; process Object4
; feature inner perimeter
; tool H0.150 W0.430
G1 Z2.899 F600
G1 X80.765 Y66.837 F9000
G1 X80.733 Y66.820
G1 X80.336 Y66.675
G1 X80.007 Y66.610
G1 X79.675 Y66.595
G1 X79.081 Y51.759
G1 Z2.599 F600
G1 E4.0000 F3000
G1 X78.944 Y51.686 E0.0042 F1620
G1 X78.775 Y51.570 E0.0055
G1 X78.541 Y51.366 E0.0083
G1 X78.355 Y51.156 E0.0075
G1 X78.203 Y50.953 E0.0068
G1 X78.060 Y50.724 E0.0072
G1 X77.960 Y50.536 E0.0057
G1 X77.787 Y50.159 E0.0111
G1 X77.710 Y49.957 E0.0058
G1 X77.603 Y49.622 E0.0094
G1 X77.524 Y49.322 E0.0083

Having been messing with this today... it seems to work well and I think it's going to be really useful!

In playing, I've noticed an interesting issue with gcode generated using PrusaSilcer so I thought I'd mention it in case it trips anyone else up. I have checked Simplify3D and it doesn't have the issue. Anyway...

There seems to be a bug in the current version of PrusaSlicer (2.2.0) in that it puts the object labels in the wrong place. In some cases it's not an issue, but if you also use nozzle wipe and cancel an object things can get messy. Logically, a wipe & retract should be associated the end of a loop and a prime with the beginning of the next. However, if you slice 3 objects (for example) in PrusaSlicer here's a snip of what it produces:

• finishes the last loop on object 1 for the current layer
• --
• labels the end of object 1 and the start of object 2
• performs the wipe then retract for object 1
• does the travel to object 2
• primes for object 2
• starts the first loop for object 2
• finishes the last loop on object 2 for the current layer
• --
• labels the end of object 2 and the start of object 3
• performs the wipe then retract for object 2
• does the travel to object 3
• primes for object 3
• starts the first loop for object 3
• finishes the last loop on object 3 for the current layer
• --
• etc...

So the issue is that if you cancel an object, the wipe and retract positions get messed up and you end up with a birds nest above the cancelled object (or elsewhere depending on order). Here's an example output of what happens in this situation - in this case the top right object was cancelled first, then later the bottom left. To be clear that the mess here isn't a problem with the printer or RRF, it's because the slicer got its object labels in the wrong place.

When I printed PEEK at 400+degrees, the only thing I changed on my stock E3D v6 setup was to swap the thermistor for a thermocouple. These days, I'd also use a copper heat block & nozzle. Other than that, I just use the same cooling as I did for everything else.

Your bigger problem will be getting enough heat into the process - a super hot bed and ideally a heated chamber. At the very least you'll need to put it all in a box to stop draughts.

Don't try printing PEEK just for fun though. It's expensive material and it by far the hardest material to print and get right that I've ever come across... particularly CF PEEK. There was nothing fun about it.

@wcj97
M505 is listed as a valid code in the wiki, so I'm guessing the answer is yes.

As an alternative, how about using a second, "virtual" bed?

If you have a spare heater output, define a second heated bed that uses the real second sensor, but leave nothing connected to the heater output. Use the original sensor with the real heated bed and set both to heat, but use M116 to wait until both beds are at your target temperature. That way, the bed shouldn't go over temperature in any area, but it will require both sensors to be at your target temperature before the print begins. Personally, I see this as the simplest solution to your problem.

@Danal said in RepRapFirmware 3.01-RC7 available:

@ChrisP said in RepRapFirmware 3.01-RC7 available:

@Danal said in RepRapFirmware 3.01-RC7 available:

For me, running a D3+Pi, this takes <25 seconds. For example, if I power cycle while everything is up and running, from the moment I hit power on to the moment the thermostatic fans kick in is less than 25. In fact, it is closer to 20.

How long does this take on your system?

So for me with a D3 and Pi4 it takes just over 24 seconds each time, which I appreciate isn't an age, but it's still not ideal.

Yeah, this is very much a judgement call on where to spend resources. A stand-alone board gets from power on to fans on in about 8 seconds, (not counting the little blip right at boot). So, collapsing out somewhere under 20 seconds, as vs some number of development hours (that I think are larger, not smaller, when I think about all the edge cases)... very much a judgement call.

Oh yeh, I 100% agree that there are bigger/more important issues and features to implement and fix first. However, I run a system where this delay is borderline unacceptable and in standalone on a D2, D3 or even the older boards, the fans start pretty much instantaneously. I'll admit I haven't time it (though I'm very tempted now.haha) but my gut feeling is that it 2 seconds or less.

Anyway, as I said initially, I'd like it to be added as a feature request if possible, because I can't imagine that one should be that hard to implement, but yeh the focus should be on other more important features first.

@Danal said in Duet3 toolboard etc.:

@bearer said in Duet3 toolboard etc.:

CAN cables twisted pair is extremely recommended,

And almost completely irrelevant for a CAN cable less than one meter long.

Can confirm that this is the case for long cables too - I'm running an old crappy telephone cable that's definitely not in twisted pairs (beacuse that's what was quickly available at the time) thats ~3 m long to an expansion board and it's fine

I agree with @Danal with respect to why M999 should case a rest of some sort on the SBC. While running RC6 I frequently had to restart DCS because the system became unresponsive and this solved it, and I did this by SSHing into the Pi to do this. This is okay while I'm sitting next to the printer with a laptop testing stuff, but long-term this isn't an acceptable way of recovering control (the alternative being a power cycle) not only because most users aren't going to now how to do this or even care about learning how to do this, but because even "power users" aren't always going to the tools immediately to hand to do this. So it makes sense that M999 / Emergency Stop on DWC should be able to recover control quickly and efficiently.

As for whether this should be in the form of resetting DCS or a full restart of the SBC, personally, I'm not keen on the idea of having to reset the whole SBC. My guess is that typically it'll only need to be DCS that needs a restart and if the SBC really needs a whole reboot then the system probably has bigger issues that need addressing.

@Phaedrux said in Filament load ...:

@ChrisP said in Filament load ...:

Or you can manually edit filaments.csv in the sys folder.

That's the other way I was thinking of but couldn't brain.

While this is an option, I think it's the harder of the two as you have to get the filament name just right. I also forgot to say that this way will clearly require a reset after too to re-parse the filaments file.

M8 S30 should also be M84 S30 too, FWIW.

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