@deckingman said in Z-Probe Trigger Height - Adjust for different materials?:

@pprovost Yes you can do that. In fact if for whatever reason, you need to use a different trigger height per filament, then it makes sense to do it in the slicer along with the temperatures that you set for each filament.

Do you recommend G31 in the slicer start? Or leave G31 in config.g set to one of the values and then use G92 to make up the difference?

Am I really the only one experiencing this challenge? It make me think I may be doing something else wrong (e.g. temps).

Here's a question... is it a problem to call G31 with a different Z-trigger height from the slicer's "start up" gcode block?

I've also been thinking about using G92 to change the current Z position after homing. My thinking is to just offset the known current height (post home) with the delta between the two G31 calls in my original post.

I was also thinking about using M206 with one of the material types to express the offset delta.

If anyone else has ideas, I'd appreciate it. If it helps, I'm using S3D for my slicer.

Thanks!

Hey folks,

I've got something that has been bugging me for a while. I've got a CoreXY machine that is pretty well tuned (very clean benchy @ 100mm/sec in PLA).

I've noticed something that is frustrating me: I have to change my Z-probe trigger height for different materials.

For example, with ABS (235/105) I use this line:
G31 X37 Y0 Z0.85 P25

But for PLA (195/40), I use this line:
G31 X37 Y0 Z1.1 P25

If I leave it at 0.85, I get no bed adhesion. Push it closer by increasing to 1.1 or 1.15, and the bed adhesion is perfect (not too much, not too little).

I've taken to just editing my config.g file when I switch materials. I've got this comment just above my G31 line in config.g:
; ABS (2019-03-20) - Z0.85
; PLA (2019-03-20) - Z1.10

I thought about putting custom G31 commands in my slicer start profiles, but that just moves the manual maintenance somewhere else.

Would love to hear if this is something anyone else deals with.

Thanks!

@phaedrux said in Expanding file listings in settings and in the macros list.:

You're still on 1.19.2 based on that version report.

Download this zip file: Duet2Firmware-2.02a.zip https://github.com/dc42/RepRapFirmware/releases/download/2.02/Duet2Firmware-2.02a.zip

Extract it to a folder. Then use the DWC system tab to upload iap4e.bin and iap4s.bin, then upload Duet2CombinedFirmware.bin. It should prompt you to update the firmware. If not, you may need to rename the file to DuetWiFiFirmware.bin and upload it again.

That fixed it. Now I'm seeing this in Settings:

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.0 or 1.01
Firmware Version: 2.02(RTOS) (2018-12-24b1)
WiFi Server Version: 1.21
Web Interface Version: 1.22.6

Do I need to update the WiFI Server and Web Interface as well?

I just experienced this today.

Upgraded to Release 2.02 from 1.19. Per the instructions, I uploaded Duet2Firmware-2.02.zip via the control panel. I just unpacked the zip file and when it offered to upgrade, I said yes.

I am now experiencing the same infinite file loading problem as the OP, on all file listings (macros, system files, etc.) in the web interface.

Here are the versions currently reported by the web interface:

Firmware Name: RepRapFirmware for Duet WiFi
Firmware Electronics: Duet WiFi 1.0
Firmware Version: 1.19.2 (2017-09-01)
WiFi Server Version: 1.22
Web Interface Version: 1.22.6

I tried manually installed the 1.22 DuetWebControl.zip (rename old www folder and extract into a new one), but this had the same result.

@T3P3Tony:

The network connectivity from Cura is specific to Ultimaker printers so you need to save the file and then upload it using DWC.

Actually, there is a Cura plugin that connects to Octoprint, so there is a way. I just haven't had time to hack into the code and figure it out for the Duet yet. If someone else wants to give it a shot, the Octoprint plugin is on gcode.

@T3P3Tony:

Sorry I missed that you had tried 1.17d

Ok not sure how it works properly in 1.17 because from the files you posted you have your config set to relative extruder moves (M83) bit your gcode is sliced with absolute extruder moves (see the e numbers increasing).

Try changing to M82 in your config, or at the beginning of the gcode print file.

Thanks, I'll take a look at that.

Hey folks,

I'm a little baffled by what is going on, so I'm hoping you guys (dc42?) can help me.

The printer is a scratch-built CoreXY based on the C/D-bot designs. It has a DuetWifi controller, E3D titan and v6 hotend, and runs on 12V.

In a nutshell, with v1.17 everything was working great, but with any of the later 1.17 releases (e.g. a, b, c, d), I'm getting some very strange behavior. Going back to v1.17 always resolves the problem.

Rather than try to explain what is happening in words, I made a video showing v1.17 and v1.17a with the same config.g, printing the same model, with the same filament, etc. The only thing I changed was the firmware version. While not included in this video, I've also run this same exact test with 1.17d and it is the same as 1.17a.

https://youtu.be/kJTdyUmy5HM

In the second "scene", it looks like in the curved corners of the skirt it slows way down and extrudes way too much filament. If you listen, you can hear the extruder grinding a bit as it is trying to push filament into the puddle building up in the corner. Please take a look and let me know if you see anything I've done wrong or any other tests I can try to help find the root cause.

Again, I want to say that I did not change the config file between prints, nor did I change the model file. Here are the two files used in the video:

• config.g - https://gist.github.com/PProvost/c7de1ac32124dc23d4b970f6f16c81bd

• model gcode - https://gist.github.com/PProvost/19ea826548b6b8773814e57e88b79818

Thanks!

I should probably post this in the 1.17a thread, but figure this one is probably getting more attention right now…

I've got a CoreXY machine with a DuetWifi. I was running firmware 1.17 on it and everything was great. I decided to upgrade to 1.17d and things got weird…

With the same config.g and the same gcode file (a simple 20x20x5 cuboid), 1.17 prints it normally. However, with 1.17d, it suddenly is acting as if the G1 speed (FXXX) is being slowed way down. It moves very VERY slowly, particularly on rounded corners like the skirt around the cube.

Assuming I must have messed something up somewhere, I decided to go back to 1.17. With the same config.g and the same gcode file, it again printed perfectly fine.

"Hmmm... that's strange", I thought.

Wondering if this was specific to 1.17d, I decided to try 1.17a. I got the same odd feedrate behavior. One more time, keeping the same config.g and model gcode file, I went back to 1.17 again, and it started working normally.

It almost looks like the F parameter on G1 is being changed somehow, but I have no idea how to troubleshoot what is really going on. I looked through the commits for 1.17a and did see a change to how the G1 feedrate is being set in gcodes2.cpp (it is now multiplied by the new "secondsToMinutes" constant), but since I can't seem to find anyone else talking about this issue, I have to believe it is something else.

Here's the line of code I'm referring to:
https://github.com/dc42/RepRapFirmware/blob/660e9c7d1ca95df5e31693734c018172f2bae7d8/src/GCodes/GCodes2.cpp#L117

Thoughts? I'm happy to post config files, videos, etc. if it will help. At this point I'm going to stick with 1.17 until I can figure out what the heck is going on.

Thanks!

PS. The model gcode was generated by Cura 2.3.1 if that matters.