Change at Z bug - Githubissues

TheOneTrueRazor commented 3 years ago

Application Version

4.11.0

Platform

Mac

Printer

Custom FFF Printer

Reproduction steps

I am using a MonoPrice Voxel.
I have been playing with the ChangeAtZ 5.2.1(Experimental) in the Post Processing Scripts. I was trying to print a test temperature tree.
I set my temperatures to change at specific layers and then sliced my object.
I sent the print file to the printer.
I tried again with a simpler test object and tried to go from 180 to 190 and the same thing happened. I tried the temperature change on one print at layer 18, and then again at 2mm, hoping that maybe it was a layer issue.

Actual results

When the printer hits the target layer the heat for the extruder appears to turn off completely. I started my print at 225 and at my first layer was going to drop to 220, instead the extruder was at 150 before I caught it and stopped it.

Expected results

Extruder temperature should have changed to what I set it to.

Checklist of files to include

[ ] Log file
[ ] Project file

Additional information & file uploads

CFFFP_calicat w temp change at feet.gcode.zip

crabtruckington commented 3 years ago

I'd also like to report ChangeAtZ not working in 4.11.0, it seemed to work in 4.10.0. Attached are two gcode files, the first one (BB1_calicat.gcode) was done in 4.10.0, the second (BB1_calicat_200_percent_size.gcode) was done in 4.11.0

There should be the following changes:

BB1_calicat.gcode: Bed Temp to 65C at layer 5 Bed Temp to 60C at layer 10

BB1_calicat_200_percent_size: Extruder temp to 205C at layer 3 Bed Temp to 65C at layer 5 Bed Temp to 60C at layer 10

I do see the attempted extruder temp change at layer 3, but it did not actually take, the extruder stayed at 210. The bed temp changes at layer 5 and 10 are missing completely in the second file, but are present in the first.

BB1_calicat.zip

GregValiant commented 3 years ago

There are a lot of oddities in the gcode file. It appears to have been set up as a dual extruder printer? There is an M7 command that appears to be a coolant command specific to CNC machines. M104 S180 T0 ;Set extruder #1 to 180 M104 S0 T1 ;Turn off extruder #2 M107 ;Turn on cooling mist G90 G28 M132 X Y Z A B ;Load axes offsets from EEPROM. This appears to be a MakerBot specific command and the Monoprice definitions seem to indicate that they use RepRap firmware.

What Gcode flavor is Cura set to? What firmware is loaded in the printer? How many extruders do you have?

TheOneTrueRazor commented 3 years ago

Hello @GregValiant I assume you are replying to me and not @crabtruckington.

The MonoPrice Voxel is basically a rebranded FlashForge Adventurer III, and has a single extruder.

I used this link to set up my printer; https://andybradford.dev/2020/01/12/using-the-monoprice-voxel-with-ultimaker-cura/

And used this link to learn how to wirelessly transfer my files to the printer; https://andybradford.dev/2020/08/26/an-app-to-transfer-files-to-the-flashforge-adventurer-or-monoprice-voxel/

If I run a print without adding any Post Processing Scripts the printer will print. If there are errors in the Start and End G-Code boxes I would most definitely like to correct them. I'm still a little new at this but I definitely know I don't have a cooling mist installed. LOL

Please let me know what other information I can provide to help you help me. Thanks!

GregValiant commented 3 years ago

Hi @TheOneTrueRazor yes that was a response to your post. I have way more questions than answers. The list of Marlin gcode commands is at MarlinFW.org and you have some commands that aren't listed as being supported but at the AndyBradford site he shows the printer using Marlin. At the RepRap Wiki There are some commands that you have but others (like the M7) don't look like they do anything. Without knowing how MonoPrice / Flashforge set up the firmware it's pretty tough to figure out what's going on as well as configuring Cura for what appears to be proprietary firmware. MonoPrice (and to a greater degree DaVinci) seem to want to keep their customers firmly in hand. One way is to keep you using only their slicer as it is the only slicer that knows how to put the ".g" file together to print. Experimentation may free you from that. Commands like "G161" might or might not work if changed to the more mainstream G28. Printer definition files contain information for Cura to use to set defaults and max/min limits for the settings. My Ender 3 Pro definition starts by loading the generic FDMprinter definition that you used. My definition then loads the Creality Base Definition file which adds to or over-rides some things from the FDMPrinter file. Finally the Ender_3Pro definition file loads and has more additions and over-rides. The # 1 most important thing is the Gcode Flavor and it sure looks like MonoPrice went with their own. One thing I know for sure about 3D printing is that "Everything affects Everything". It amazes me how complicated something simple like "moving a little nozzle around while it squirts hot plastic"_ can be.

Ghostkeeper commented 3 years ago

The g-code that the Change At Z script added was merely this, at the end of layer 16:

;[CAZD:
M104 S190.0 T0
;:CAZD]

If your printer interprets that as "cool down all the way to zero", maybe that's a problem with the printer, rather than a problem in the resulting g-code :wink: But I expect your printer will be fine with this. It's about as standard as it gets. Could it be that it's having a problem with the .0 part?

The start g-code does have a line that cools the second extruder down to 0:

M104 S0 T1

So it seems that Cura thinks your printer has two extruders. Depending on whether your printer understands the T parameter, this could be a problem. Maybe it'd cool down to 0 at the start of the print. This has nothing to do with the Change At Z post-processing script though, only with your printer settings. Aside from that, there are only heating commands to S180, this ChangeAtZ to S190 and the cooling down at the very end of the print. I don't see a problem in this g-code.

Could you maybe provide a project file, so that this issue may be reproduced? You only uploaded g-code which doesn't allow seeing what may be causing the resulting g-code. We'll also need to know what in the g-code is wrong according to your printer, before we can fix this.

TheOneTrueRazor commented 2 years ago

Hello @Ghostkeeper, I've been out of pocket the last week. I realized I didn't have a project file so I recreated one and the slice using the same printer setup. Complete Work File.zip

Ghostkeeper commented 2 years ago

Thanks! That'll help to fix the issue once we know what to change. However we also don't know what is really wrong with Cura's output at the moment.

You mention that the nozzle cools down to 0. However we can't find any command in your g-code that does this, aside from at the end of the print. So without having your printer, we don't know what we would need to change in Cura's output. The g-code output looks like it's behaving as we expect it to. The printer doesn't. So to fix this, we also need to know what would need to be different in the g-code to make your printer behave correctly.

I made one guess already. Could you try editing your g-code file to remove the .0 from the M104 command? So turning M104 S190.0 T0 into M104 S190 T0. It shouldn't matter, but perhaps that is what your printer is struggling with.

no-response[bot] commented 2 years ago

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.