Posts made by mikeabuilder

You could also read jobs.duration, sleep for a couple of seconds, then read it again to see it it has incremented.

Sad news. His contributions will not be forgotten.

Thanks @chrishamm. Reading your response made me realize that I not only mistyped "SBC" but also that I was backwards about it. My system is NOT running in SBC mode, it's stand-alone. So thanks for answering that version of the question.

I'm restating your "never supported NPT" comment to see if I understand the implications for a machine running in stand-alone mode:

• The stand-along RRF will not "know" the time until a client connects. This means all log entries will have a timestamp based on the machine's uptime (time since boot).

• If/When a client connects, if that client is DWC, then DWC will set RRF's date-time.

• If a client other than DWC connects, and it connects using rr_connect with the time option, then RRF will update with the time from the client.

This explains a lot of unexplained macro errors I've observed over the past three years. And I can see now that I'll need to rewrite all the macros to not use state.time for measuring duration. I'll convert them all over to using state.upTime rather than state.time.

I think I'll also look into making an Rpi pico that powers up with my system and that does the rr_conenct function.

I have a MB6HC with wired ethernet. I'm running RRF 3.5.1 in SCB mode, using PanelDu as the interface

I have a recurring problem where occasionally, my boards boots, connects to the network, but does not get it's clock set to the correct time. This causes me problems because I have macros that turn the heaters off 10 minutes after a print finishes, but when I don't get the date/time started properly, state.time is null

This happened to me today and here's a clip from my event log. You can see on line 8 that the board got an IP address, but no client login is recorded. In this case, the client login succeeded over 6 hours later. What happened when it succeeded is that I echoed state.time from the PanelDu console and got a null returned. Then I walked into the house, connected from my laptop and used DWC to look at the object model and saw IP was connected. By then (about 5 minutes later) the system had logged in and gotten a time.

So my question are:

1. Is this maybe a bug? I assume not because it would have been flagged by loads of people.
2. Is there a way for me to force the system to attempt a login? I can see putting something in daemon.g that would look for a null state.time, verify there's an IP address, then force a login. I don't want to do anything that might impact a running job.

2024-11-02 16:49:33 [warn] Warning: 12V under-voltage event (9.4V)
power up + 00:00:00 [info] Event logging started at level info
power up + 00:00:00 [info] Running: Duet 3 MB6HC v1.01: 3.5.1 (2024-04-19 14:30:55)
power up + 00:00:00 [info] G10 P0 X0 Y0
power up + 00:00:00 [info] G10 P0 Z-0.335
power up + 00:00:00 [info] G10 P0 R0 S0
power up + 00:00:00 [info] starting 0:/macros/prep_printer.g
power up + 00:00:00 [info] M291: - [no title] - Run prep_printer macro? Heats bed, homes axes, levels bed, creates comp mesh.
power up + 00:00:04 [warn] Ethernet running, IP address = 192.168.0.172
power up + 00:00:06 [info] M292: cancelled=false
power up + 00:00:06 [info] M291: - [no title] - Prep Step 1 of 3 - Heat the bed? May take 10-15 minutes
power up + 00:01:45 [info] M292: cancelled=false
power up + 00:01:45 [info] M291: - [no title] - Heating bed to 65C prior to next steps. This may take up to 15 minutes.
power up + 00:09:09 [info] M291: - [no title] - Bed heating completed.
power up + 00:09:09 [info] M291: - [no title] - Prep Step 2 of 3  - HOME ALL AXES?
power up + 00:18:50 [info] M292: cancelled=false
power up + 00:18:50 [info] M291: - [no title] - Homing all axes.
power up + 00:19:19 [info] M291: - [no title] - Homing completed.
power up + 00:19:19 [info] M291: - [no title] - Prep Step 3 of 3 - CREATE COMPENSATION MESH?
power up + 00:19:22 [info] M292: cancelled=false
power up + 00:19:22 [info] M291: - [no title] - Compensation mesh creation skipped per user request. 
power up + 00:19:24 [info] M292: cancelled=false
power up + 00:19:24 [info] Compensation mesh skipped per user request. 
power up + 00:19:24 [info] M291: - [no title] - Printer prep process exiting.
power up + 00:19:26 [info] M292: cancelled=false
power up + 00:19:40 [info] G10 P0 S210
power up + 00:21:34 [warn] Started printing file 0:/gcodes/Shell 1 - new.gcode
power up + 00:21:34 [info] G10 S210 P0
power up + 00:21:45 [info] G10 S210 P0
power up + 02:27:37 [warn] Finished printing file 0:/gcodes/Shell 1 - new.gcode, print time was 2h 6m
power up + 02:27:37 [warn] Error: in file macro line 15 column 53: meta command: expected numeric or enumeration value after '+'
power up + 03:07:37 [warn] Started printing file 0:/gcodes/Shell 1 - new.gcode
power up + 03:07:47 [info] G10 S210 P0
power up + 03:07:58 [info] G10 S210 P0
power up + 05:13:01 [warn] Finished printing file 0:/gcodes/Shell 1 - new.gcode, print time was 2h 5m
power up + 05:13:02 [warn] Error: in file macro line 15 column 53: meta command: expected numeric or enumeration value after '+'
power up + 05:15:31 [warn] Started printing file 0:/gcodes/Shell 1 - new.gcode
power up + 05:15:41 [info] G10 S210 P0
power up + 05:15:52 [info] G10 S210 P0
power up + 06:38:24 [warn] HTTP client 192.168.0.100 login succeeded (session key 3399339837)
2024-11-03 15:35:27 [info] time check
2024-11-03 15:35:34 [info] time check
2024-11-03 15:35:50 [info] 2024-11-03T15:35:50

@vbtalent2 - You are correct in thinking there are a lot of variables you can control and knowing where to begin can be challenging. With PrusaSlicer, using the Beginner, Normal, and Expert modes can help. If you turn on Expert mode, all of the controls are shown, and they are color coded (Green for beginner, Yellow for normal, and Red for expert) so you can see what available and know which are usually important.

For making temperature towers, Prusa Slicer lets you insert your own gcode in sliced files in various places. In the Printers tab, under Custom G-code, there is a place where you can put some gcode that will be inserted every time a layer change happens. In this space you can add code that follows the Prusa coding conventions (https://help.prusa3d.com/article/macros_1775) and will change parameters for you. Here's an example I made for a Pressure Advance tower. It looks at a Prusa variable called layer_num and when it hits different values it inserts an M572 command to change the PA value. You can easily put a different gcode in to change the nozzle value (or just about anything else).

{if layer_num == 0}
;PA_tweaks - START
M572 D0 S.028   ; Adjust pressure advance
;PA_tweaks- END

       {elsif layer_num == 25}  
;PA_tweaks- START
M572 D0 S0.03   ; Adjust pressure advance
;PA_tweaks- END

       {elsif layer_num == 50} 
;PA_tweaks- START
M572 D0 S0.035 ; Adjust Pressure advance
;PA_tweaks- END

       {elsif layer_num == 75} 
;PA_tweaks- START
M572 D0 S0.040 ; Adjust Pressure advance 
;PA_tweaks- END

       {elsif layer_num == 100} 
;PA_tweaks- START
M572 D0 S0.044 ; Adjust Pressure advance 
;PA_tweaks- END

       {elsif layer_num == 125}
;PA_tweaks- START
M572 D0 S0.048  ; Adjust Pressure advance 
;PA_tweaks- END

{endif}

Great progress. You are nearly to the realm of fine tuning. I have a few specific suggestion, but they do not address all your questions. Specifically, I still have a similar blob on layer changes and I'll be watching fro someone to suggest something that helps me too.

First Layer - In the initial photos, it looks pretty good. The top surface looks flat completely filled. The last photos of the more details part do look pretty bad. My first impression is that there may be a combination of too close to the bed (I know, your fixed that!), too much extrusion, and not sticking well to the glass plate. You may also have the hot end temperature too high. In my experience, I usually run the hot end just a few degrees above the low temperature rating of the filament.

Second layer - In picture 5, the second layer looks like it has ridging between the lines. This means excess plastic is being pushed around by the nozzle. If the layers below don;t have excess plastic (and they look good in this picture), I would suspect your extrusion rate is too high. You can reduce it in the web interface while printing, change the extruder steps per mm in your config.g, or (probably) make a setting change in your slicer. If you consistently change it in the printer interface or in the slicer, and with different reels of filament, you should probably adjust the steps per mm in config.g. I think it's best to tweak the extrudion % while looking at the second or third layer and not the first layer because the first layer can be affected by the z-offset. Once the higher layers look great, use baby steps to adjust the offset so the first layer looks great too.

Picture 6 - This looks to me like a classic example of a need for PA adjustment. PA (Pressure Advance) reduces the extrusion rate before the end of a line to compensate for oozing caused by pressure built up between the extruder motor and the hot end. You can adjust this live as your print builds up using M572 (see https://docs.duet3d.com/en/User_manual/Reference/Gcodes) . You can also probably do some clever stuff in the slicer to have it change the PA every 20 layers so you don't need to sit and watch it.

Blobbies and observations on the last photo. - There is some darkened filament stuck to the side of the part. In my experience, this is plastic that's been clinging to the nozzle and burning, then finally getting pulled off. The causes is often stringing that gets picked up when the nozzle runs past it, or anything else sticking up - like those blobs at the layer change, or the ridges from too much extrusion. And one you get some plastic built up on the nozzle, it becomes a stick place to grab more. I also notice that the blue boot looks like it might be dragging on the plastic surface and this could be sweeping up more crud to melt on the nozzle. I'd get that boot pushed on better (you might need to make the hole around the nozzle bigger). And I'd also look at the nozzle after every print and clean off any excess plastic you see while it's still hot. And also take the boot off occasionally and clean off the bottom of the hot end. I like these brushes because they are cheap and there's a box full ( https://www.amazon.com/Pack-Brass-Brush-Tooth-Brushes/dp/B07FN6K9J9). I keep some long and trim the bristles on some shorter with scissors. I like brass better than stainless because it's less likely to mar the hot end or nozzle. And don't let plastic build up on the brush or you'll be brushing on as much as you're brushing off.

Lastly - sorry this is so long. I like to use PrusaSlicer to get an idea for values of settings. I'll download the prusa config for a MK3.5 printer and see what it would use for all the settings. If mine are way off from that, I try to find a good reason, or test the Prusa value.

This looks like a great idea. I've always had trouble trying to find the right jerk setting.

To me, this looks like the nozzle is too far from the bed. I say this because the individual filament lines look rounded on their tops. If they are rounded on their tops, they are probably also rounded on the side that is touching your glass plate. That can lead to bit and pieces coming off the build plate to make blobs. On my printer, I try to make the top surface of the first layer flat and smooth. The part of the nozzle where the plastic comes out is most likely flat next to the hole. I like to think of that little flat space as an iron that is flattening out the filament on top and providing some pressure to push it against the build plate.

This is where baby stepping should be used. you start the print as you have it, then use baby steps to move the nozzle closer while observing whether the result on the build plate is looking better (in this case smoother). If the nozzle gets too close, then the end of the nozzle will be "plowing" through the plastic already put down and you'll get rough ridges, not the smooth ones you see in your pictures. Then baby step away from the plate until it looks better. .

Not a solution to this issue, but a recommendation. If you home X and Y are the same code copied from the homex.g and homey.g, I think a better solution is to use an M98 and call homeX .g and home.g directly. If you do this, then some time in the future decide to make a change to homeX or homey, you'll only need to change the code in one place. I learned this one the hard way.

Mike

There are a lot of things you can easily do with macros you write and with "standard" macros.

For example, In the Filaments folder you will find a sub-folder for each filament type. And in that folder, there is a file called config.g. This file (aka macro) is run when the filament is changed using DWC. You could put code in this file for your TPU filament to disable your filament sensor. You could have code in your other filament directories to turn on the filament sensor. This page is good to read: https://docs.duet3d.com/en/User_manual/Reference/DWC_filaments

You could also add a LED to a Duet board output and have it turn on or off with the filament sensor. Or you could have a message displayed when the filament sensor is turned off or on to alert the user. That's an M291 command.

Writing macros is not too difficult, and is even fun for some of us. Read up on the capabilities of macros here: https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands

Next steps... The big categories (I think) are:

Basic accuracy - if you print a cube, say 25mm on a side, and measure it with calipers, is it the right size? Do the corners look sharp? Are there bumps or wiggles? Does things change if the printing speed is increased? Is the top surface pretty flat, or does it have lumps and ridges?

Ringing - (seen most often at higher speeds). If you have stretch in your belts, or something can wiggle, you can get defects in your prints. The Duet board can compensate for some of these. You'll need to get an accelerometer chip and run some tests.

Adapting for shrinkage - When your parts cool, they'll shrink a bit. Print something long that you can measure after printing with calipers. Once you find the error (as a percentage), you can add compensation for that in your filament files.

I think you've got this part nailed. Now be sure that your zoffset in config.g matches your outer ring and move on to the next challenge.

Those newer pictures look pretty good, but I would judge the spacing to still be a little big bigger than desired. Here's why - the tops of each line of filament look a little rounded and there is a groove between each line. I try for a smoother surface. If you get too close you'll see excess plastic being plowed along, making rough ridges - though these can also be from over extrusion.

But this can also be affected by the shape of the nozzle. When you look at the opening in the nozzle, some look flat with a hole in the center, and some have almost no flat space. Those with the flat space tend to make flatter top surfaces (just my observation from my experience - someone else might share some good advice about which nozzle shapes are better for different things).

I agree with the comments from @infiniteloop. 0.1mm is a challenging first layer height. For a new printer, .25 or .3 is a good place to start. Once things are working well then start moving closer. I use a .2mm first layer on almost all prints, even if all my other layers are .1 or eve .05mm. Also, find a slicer you like. I ended up with PrusaSlicer, but mostly because the makerspace I belong to uses it.

A method I use for adjusting the babysteps is to make a square shape about 50mm on a side and one layer thick (.2mm). Adjust the setting in the slicer so that you get a few perimeters, then the rest is filled using straight lines. This will give you a shape that takes a few minutes to print and that will also move along so you can feel the part that's printed after you adjust the baby steps. You can see the effects of a change pretty quickly. And after it's printed, you can peel it off and inspect it closer to see if the adjacent lines are sticking to each other (good) or not (too high off the bed or too little plastic).

If you decide to try out PrusaSlicer, here are some tips:

• When you install, PrusaSlicer, it'll ask you to pick which Prusa Printers (or others) that you have. Your printer may be in the list. But I recommend including one of the Prusa Printers (I'd pick a Mk3S). With this, you can see the settings that Prusa likes for their printers, which can be helpful as you grow your skills.

• In the upper-right part of the window, turn on "Expert mode". You have a CoreXY printer with a Duet board - you are (or will be) an "expert. Plus, "expert mode" only shows you all the adjustments you can make and each is color coded for beginner, normal, and expert.

• Hover your mouse over any setting to get a little description of what it does.

• Create a custom printer in the printers tab. For Duet boards, G-code flavor should be RepRapFirmware. There are sections in Printers to describe your extruder and the physical limits of the printer. In the machine limits section, you can also make adjustments to the max speed, acceleration, etc (though I recommend setting these to "Use for time estimate" and then making all adjustments in config.g).

• Definitely spend some time looking at the sliced version of your parts when making changes in the slicer settings, and also comparing those to odd artifacts in the real printed parts. Over time, it'll help you make connections between settings and results.

I also think it looks like the nozzle is too far from the bed. If you are not aware of the "baby steps" button in DWC and PanelDu, check them out. You can play around all day with pieces of paper and still want to do some fine tuning while your first layer is printing and this is what the baby steps are for.

I'll also jump up on my anti-paper soapbox for a minute - paper thickness is not an engineering measurement tool. Once you shove it under a too-close nozzle a few times or get a little oozing plastic on it, it's not the same thickness and you need to start guessing if you're feeling a clear space to a roughed up space. Much better to invest in a cheap set of long feeler gauges (like this: https://www.amazon.com/Stainless-Feeler-Imperial-Measuring-0-02-1-00/dp/B08GLN7K1R ). On my printer I adjust so that the .2mm slips under the nozzle and the .25mm does not. Then it's baby steps.

And best to do all this with both the hot end and the bed heated up.

On the printer I built, I've had several instances of the temperature sensor making intermittent contact. In every case the problem was a broken wire in the bundle that moves with the print head. I thought I was safe using a cable chain, but even with it's gentle bending I had wires break, and it was caused by cheapo insulation on the wires that got brittle and cracked over time and that broke the copper strands inside. This is another possibility of the connectors are not at fault.

I now only use silicone insulated wires that are super-flexible because they have very fine wire strands. One example from Amazon: https://www.amazon.com/BNTECHGO-Flexible-Silicone-Resistant-Electronic/dp/B06Y5L4T86

In RRF (RepRapFirmwre), an M118 posts a message somewhere (PanelDue, log file, DuewWebControl, etc). It has a parameter "S" which is the message being sent. Your error message implies that there is no S parameter in your gcode file. You can easily find this if you open your gcode file in any text editor and search for "M118". You'll see what parameters are included and can also add an S and your message (in "quotes"), then try printing again.

But the best thing is to set up your slicer for RRF firmware, most likely in the printer definition.

@DonStauffer - the way I think of it is that when the X and Y axes are homes, they are defining a position of the "machine" coordinate system, and I set the M208 X and Y values to numbers that make that "Machine system" make sense.

On my machine, I marked a small dot on my build plate that I wanted to be the corner of the build area and I also wanted this to be x=0 and Y=0. I adjusted the X and Y in M208 so that after homing, if I sent the machine to 0, the nozzle would be above the dot I made. On my machine X homes at the left of the machine and Y homes at the front. And those positions are off teh build plate, so my M208 X and Y values are both negative.

After that, when I tell the machine to go to an X,Y location, it moves the nozzle there.

You can set an offset on your probe using G31 (https://docs.duet3d.com/en/User_manual/Reference/Gcodes). This is the distance (X and Y) between the nozzle and the Zprobe. After that is set, when you tell the machine to probe at a location, it will apply those offsets to the move so that the probe is at that location. And depending on the physical machine limits, you may not (most likely will not) be able to probe every edge of the bed. You need to take that into account when you set up you mesh probe limits.

@CarlBosson - stop.g is indeed a file that is run whenever a print id finished. Kudos for looking at it. Since it is empty, it cannot be running your extruder.

I don;t see anything in the end gcode you posted that looks like it would empty your extruder. A minor suggestion would be to move the M104 line after the two G1 moves wot that there is not chance your hot end cools off before you do those two small retractions.

Your slicer might be putting some retraction commands of it's own at the end of the print, it would be good if you could post the last lines of the slicers gcode output (after the last moves).

The slicer could be retracing, or possibly there is a T-1 that is deselecting the tool. If there is a T-1, then RRF will look for a file called tfree0.g and run that (it's part of the tool change process). If you have a tfree0.g have a look in it to see if it's retracting your filament.

Lastly, and now that I think of it, it seems maybe most likely... if your printer is set to use absolute coordinates for extrusion, then your G1 E-1 command would try to retract all the filament used in your print, plus 1 additional mm. The G91 command in RRF does not set the extruder to relative positioning. For that, you need M83, and M83 is a bit tricky because if it runs from a print job, you need to know if your printer machine setting (in Cura) sets extrucion to absolute or relative mode and if it is in absolute mode, you need to set it back after your moves using M82. An easier thing would be to put the custom end gcode in the stop.g file. If M83 is run from there, RRF will do the housekeeping and set it back to the mode it was in when stop.g finishes.

Adding on to @cosmowave's comments.

First, I don't see a G12 command listed in the RRF (RepRapFirmware) gcode documentation - https://docs.duet3d.com/en/User_manual/Reference/Gcodes. It may be supported by Marlin, but not RRF. You probably need to write a macro to create a stroke pattern, and designate a location where you'll draw this on your print bed. You could even name this macro "G12.g" if you wanted.

Once you have your macroThere are two ways to run something at the start of a print:

1. There is a file called start.g in the sys directory (where config.g is located). This file is called every time a you start a print, before the print's gcode file is executed. You can put in any commands you want. You can call your macro using an M98. The upside of calling your wipe macro from here is that it will always run. The downside is that the start.g is not aware of anything that is in your print file (notably, the nozzle temperature). This can be a problem if you run at different temperatures for different prints.

2. Your slicer probably has a place for custom gcode that is placed at the front of your print file (I use PrusaSlicr and it does), and you can add your wipe steps here - including calling that macro using an M98command. The upside is that you can do stuff like wait for the nozzle to heat up to the temperature called for in the slicer. The downside is that you need to be sure that code is in your slicer.

Here's the gcode I put into my slicer's custom gcode to draw a Prusa-like prime line.

T0 ; select Tool 0

; make the "prusa front end glob"

G1 X0 Y-3 F3000 ; go outside print area near the origin
G1 Z0.2 F720    ; lower the nozzle to .2mm

G1 X60 E9 F1000 ; intro line
 ;move to X = 60mm in the X direction, extruding 9mm of filament
G1 X100 E12.5 F1000 ; intro line move to X = 100, extruding 12.5mm of filament

Note that I draw the line "outside the print area". On my printer, I set the minimum Y coordinate to -4 in config.g, but the slicer only allows me to place parts to 0 in the Y direction. This way, I don't accidentally draw that purge line under a part.

Second note: if you decide to do your wipe outside the soft limits of your print bed, you'll need to read up on temporarily removing the soft limits so you can drive your printer to that location (being careful not to crash, because you just took off the safety), then be sure to turn those limits back on after you finish your stripe. My recommendation is to say within the soft limits.

Also read up on some of the programming things you can do in gcode here:https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands

Also, check out the M291 command that lets you put messages on the screen from your macro file. Very useful as you start writing macros.

One thing to note if you are using M564 as @gtrider suggests.

I assume you'd be moving back withing limits before sending the M564 H1 S1 command to re-establish limits. It's a good practice to send an M400 command before that M564 H1 S1. If you don't, it's possible that the machine will still be traveling, but not yet in-bounds when the M564is processed and the fw will think there is a bounds violation. all further moves will get a warming and be ignored. I learned this on the hard way.