b-morgan
-
Posts
20 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by b-morgan
-
-
This appears to be the original PauseAtHeight.py which is known to have problems. A newer version is posted earlier in this thread.
With this version, we need to see a few lines before the ;TYPE:CUSTOM to see what the E value was before the pause. Do you have any documentation on what firmware (and version) is in this printer?
Since there is no retraction, theoretically you could remove the M83 and the M82 lines. No standby temperature was specified so the value of zero is used. Probably not a good choice as it lets the nozzle cool too much.
-
The prime tower with dual extruders allocates separate X,Y dimensions for each extruder (concentric squares) but on layers that only use one extruder, the square for the other extruder is not printed. When the second extruder is introduced, there is nothing underneath so the filament is extruded into empty space (i.e. printed in mid-air).
I believe the way this should work is that for layers that only use one extruder, the prime tower should have both squares printed with that extruder. When a layer uses both extruders, each extruder should print its allocated square in the prime tower.
-
Here's an updated version with only one M0 pause and heaters turned on after the user resumes. I added another input option for resume bed temperature, default of 0 will use the previous value (same as resume nozzle temperature).
I bumped the version number so put this file in the previously posted location and delete the old version.
-
I believe M0 turns off the heater on some printers and if so, then the code needs a bit more work.
-
1 hour ago, marty_gibson70 said:
Will this M0 you mention be a problem?
It would be almost impossible to write this script so that it worked with every printer out there. Experience has shown that the M0 command defined by Marlin is not always implemented in every printer's firmware. This script is provided in source form so if M0 doesn't work in your printer's firmware, feel free to edit the source. You can substitute a G4 S600 for a 10 minute pause instead (adjust the S value to suit).
-
I have attached a newer file in a .zip this time. This file needs to be placed in (assuming the default installation location):
C:\Program Files\Ultimaker Cura 4.0\plugins\PostProcessingPlugin\scripts
You will see all the other scripts if you are in the right place.
I have also attached (in a .zip) the Gcode file for a 3DBenchy generated on my system using Cura 4.0, Tevo Terantula, with pauses at layer 10, layer 20, and height 3.3mm (approximately layer 30). There are lots of parameters to be set with this version of the script and the defaults should do something sensible but you will have to experiment.
Edit: Deleted attached files as they were obsolete. Keep reading for newer version. These instructions are still valid.
-
1
-
-
56 minutes ago, marty_gibson70 said:
Did we get a working result?
A fix to no extrusion issue after resume printing?
Thanks
The version I posted on June 21, 2018 worked for me at the time. Cura has had multiple updates since then. I'd suggest that you try it and report your results along with enough details about your environment (i.e. printer, firmware, Cura version, etc.) that someone might be able to help.
-
On 6/21/2018 at 6:04 AM, Cosomo said:
First the M0 command were not working.
Then I decide to substitute de M0 command by a G4 P6000 to, at least, have some time.
This week the UM3 has received a new firmware and then the M0 command has started to work but... now the problem is that the tempertature decreases while M0 command is alive awaiting. Even if I put the two temperatures in the script dialog equal to the working temperature the fact is that goes down during the pause.
Yes, of course, prior to restart the printing temperature reaches the working temp, but the next layer does not bond well with the previous one, so after some layers that pause layer breaks.
As I said before, I don't have a UM3 printer so the problems you are having are regrettable, but not something I can fix. The Marlin documentation doesn't say anything about temperatures but the RepRap documentation says all heaters and motors are turned off so M0 is probably not appropriate for this script. G4 is the only other command I can find. Can you break out of it with the LCD?
In any case, I've got a newer version that fixes an issue of incorrectly setting absolute extruder unconditionally after a pause. The script now checks for absolute or relative extruder and restores the correct mode. There is also a G4 pause time you can specify after the script is resumed to allow for cleaning the nozzle after extruding the specified amount of filament. This may help your restart issue with the next layer.
Edit: File removed because it is obsolete. Keep reading for a newer version
-
On 6/8/2018 at 10:02 AM, smartavionics said:
Maybe their logic is the following: as some beds take a lot longer to heat than hot ends, the ordering is OK as it minimises the amount of time that the filament is static in a hot nozzle while waiting for the bed to heat.
This might make sense if there were just the two commands, M109 followed by M190. Since there are three commands...
-
2 hours ago, berndjm said:
Ah, ok, you're using the AppImages. I was a bit missleading that you wrote
?
Just of curiosity: is the Ubuntu installation you mentioned on the same pc as your LinuxMint installation?
If it is, the problem couldn't be the grafic card. There must be some missing opengl related files in your Mint installation which - for whatever reason are present - in the Ubuntu installation ...
Yes, the Ubuntu installation is on the same PC as the LinuxMint installation, just a different disk. Both installations were "default" installations. They found the graphics card on their own and installed whatever drivers, etc. that the "default" called for.
I'm not to worried about it. The LinuxMint install was primarily so I could install Folding @ Home and keep the graphics card occupied. I'd also use it for doing some Linux experiments from time to time. I have my 3D printer connected to a Raspberry Pi 3B running OctoPrint so that gives me another place to play with Linux. All my serious slicing is done on my Windows 10 desktop.
-
7 hours ago, b-morgan said:
There is, however, a flaw in the current implementation in that it assumes that the gcode is in absolute XYZ mode (G90) and E absolute (M82). I'll have to see if I can fix that.
I believe I have fixed the script to handle absolute or relative modes (relative E has been minimally tested, relative XYZ code not tested at all). You will have to rename the file to remove the .log extension as that was the only way I could get it to upload here.
-
@Cosomo When you say "tried this plugin" did you mean the one I posted?
This post processing script (its really not a plugin by Ultimaker's definition) has an "Extrude Amount" which, according to its tooltip, is supposed to be used to compensate for the retraction caused by the M0 command. I have no idea what value to use as I don't have an Ultimaker printer ? but you can start large and work your way down to the correct amount (at the expense of some wasted filament).
-
40 minutes ago, berndjm said:
May some missing opengl related components (e.g. python-opengl ...)
But to be honest, since they have Cura for linux as an AppImage I save myself the annoyance of outdated or uninstalled versions of any required software components.
Just start the AppImage and be happy ;-))
As a "bonus" you can have all the version parallel together without any fear about overwriting something ...
(just for the records: LinuxMint Cinnamon 18.3))
I'm not sure what I did "wrong" but my LinuxMint Mate 18.3 gets that error message when I run the AppImage.
I attempted to update my nVidia drivers with a download from nvidia.com but all that did was mess up my Folding @ Home. I also have a Ubuntu install (on a different disk) and the AppImage ran just fine on that.
The /home/[YOUR_USERNAME]/.local/share/cura/3.3/scripts directory was empty so I'm confused about that. Is that directory "appended" to what is stored in the AppImage?
EDIT: To answer my own question... Yes, the contents of that directory are appended to the scripts automagically included in the AppImage.
-
1 hour ago, berndjm said:
On linux the script should work located in
/home/[YOUR_USERNAME]/.local/share/cura/3.3/scripts
I'm glad somebody knows what they are doing in Linux ?
I have a Linux machine and tried to install Cura but it said "Could not probe OpenGL" ? and I'm not sure how to fix that except that the graphics card (nVidia GeForce 960) should support it (LinuxMint MATE 18.3)
-
You are correct, the Z1 and Z15 moves are generated by the post processing script. I'm too old to remember code I modified or wrote a few months ago ? There is, however, a flaw in the current implementation in that it assumes that the gcode is in absolute XYZ mode (G90) and E absolute (M82). I'll have to see if I can fix that.
Do you know if the gcode with the pause script active is absolute or relative?
The Z1 should be Z(current_z+1) and the Z15 should only appear if the model is still printing layers below 15 (mm if G21 is active). In addition to adding gcode, the script also inserts comments which reveal some of the values the code is working with. The reason for the Z15 is that if the purpose of the pause is to change the filament, there should be some space below the nozzle to work.
The script should go in C:\Program Files\Ultimaker Cura 3.3\plugins\PostProcessingPlugin\scripts (if you used the defaults when you installed Cura). Note that if you just remove the .log from the filename, my script has a unique name.
On my machine, I did find a script in the above directory for every script listed in the Add a script dropdown.
-
I'd be willing to bet those initial Z height changes are coming from the start gcode for your printer. If so, then they are executed before there's anything on the print bed.
The current Pause at Height post processing script, however, isn't very smart and it see's those changes in Z and will insert its gcode into the middle of your printer's start gcode.
I have solved this problem by modifying the script, see below:
On 3/31/2018 at 8:13 PM, b-morgan said:The problem with the PauseAtHeight.py distributed with Ultimaker Cura is that it is off by a few layers from where you expect it to be. I've attached a modified version that corrects that problem and adds a choice between height (in mm) or layer number.
You will have to rename the file to remove the .log extension as that was the only way I could get it to upload here.
(moderator: feel free to rename the file as you approve this post).
-
On 6/21/2017 at 2:56 AM, ahoeben said:
CuraEngine checks if the start gcode contains commands to heat up the hotend and bed before the print is started. If the start gcode does not have command to do that, CuraEngine adds the three lines (M190, M104, M109) before your start gcode just to make sure that the hotend is not cold before starting the actual print.
If you don't want Cura to add these lines, make sure your start gcode contains lines which have {material_print_temperature} and {material_bed_temperature} in them respectively.
The order of these three lines is incorrect. An M104 (heat hotend, no wait) followed immediately with an M109 (heat hotend, wait) is exactly the same as the M109 alone (i.e. the M104 is essentially a no-op). If however, the M104 was first followed by the M190 (heat bed and wait) and then the M109, then that combination would cause both heaters to be working at the same time.
-
The problem with the PauseAtHeight.py distributed with Ultimaker Cura is that it is off by a few layers from where you expect it to be. I've attached a modified version that corrects that problem and adds a choice between height (in mm) or layer number.
You will have to rename the file to remove the .log extension as that was the only way I could get it to upload here.
(moderator: feel free to rename the file as you approve this post).
-
I'm trying to use the GCode post processing plugin "Pause at height" and either I'm too stupid to figure it out or it isn't working. I have a 25mm tall test print and I select "Pause at height" which opens with 5.0mm as the default height. I close that window and select Save to file and open the GCode file in a text editor. I see at the top ";POSTPROCESSED" but when I look at the ;LAYER before Z5, at Z5, and after Z5 there are no GCode commands added to the file.
If I perform the same experiment with "Tweak at Z", it works as expected and there are GCode commands added to the file (to change the selected parameter).
Am I doing something wrong? If so, what? If it works for you, please let me know what steps you took.
Prime Tower uses separate X,Y dimensions for each extruder
in UltiMaker Cura
Posted · Edited by b-morgan
I am at a complete loss when it comes to reporting bugs in Cura. There is never any acknowledgement from Ultimaker and, of course, many versions of Cura released without a fix.
I guess that means this is NOT the place to report bugs, but I can't find anything that says where bugs should be reported.