Jump to content

jens3

Member
  • Posts

    155
  • Joined

  • Last visited

Everything posted by jens3

  1. Thanks for your reply. Do you have any suggestions on how to fix the configuration error / profile error without wiping the entire installation ?
  2. First, let me say that I am running the 'master' branch of cura (4.20.8) so my question is necessarily a bit vague. I have run into an issue where deleting a print profile causes a 'configuration error' next time Cura is started. Additional error information points to corrupt profiles (the ones I deleted). I get an option to wipe everything - printers, profiles, the works. That is just plain stupid and is not an acceptable option. Digging around, I find that this is a common problem but I have not found an explanation of why this happens nor how to fix it. There have been vague references to deleting the mentioned (in the error message) profiles in the configuration but no mention of exactly where I find the profiles. Yes, I can go to 'help' and open up the configuration files but where do I go from there. There is no 'profiles' subdirectory. Further, at least under Linux/Ubuntu there are actually two places where configuration files are located and they seem to contain the same stuff. The info is at Home/.config/cura as well as Home/.local/share/Cura. In previous instances of messing with the configuration, I had to be careful I always did the same changes to both locations. So here are my questions: What is the point of having the configuration in two places? Do I really need to change both instances or is one a backup of the other and is automatically updated? If so, which one is the authoritative version? Which of the subdirectories contains the actual profiles? There are a lot of very similar files in the various subdirectories and none of them are labeled the same way the actual profiles were labeled. How can I link the file names in the configuration area(s) to the actual names of the files I deleted via Cura? Bonus question: I have three printers configured. They are all accessed via network however when I do configure a new printer, none of these printers shows up on a listing. If I tell Cura the actual IP number of the new printer I always get back an error saying the printer is not communicating (or similar). The very first printer somehow reports as a 'connected printer' and the other two show as 'preset printers'. Cura talks fine with all three - the first one via octoprint, the other two via the network. HOWEVER .... while the connected printer has it's own profiles, every profile I generate for one of the other printers shows up in the profiles of all the other 'preset' printers. I can even set up a brand new printer, make a custom profile for it and that same profile shows up in the profile list for all the other 'preset' printers. What is going on? What is the difference between a connected and a preset printer? Why would a profile that was set up for one particular printer show up in a completely different printer profile listing? It makes no sense to me! If it makes a difference, the two 'preset' printers are both set up as 'custom' printers. I would very much appreciate either an explanation or a link to some article explaining things. While the corruption issue is the most pressing (even though Cura works fine if I ignore the error message), I would really like to understand things rather than trying to operate something that makes no sense to me.
  3. Anybody know why the above mentioned version, downloaded from github from smartavionics/cura will not run? After some digging I found that the AppImage file is missing libxcb-xinput-dev. Once that is installed, Cura starts up normally. I am simply posting this in case other people run into this issue.
  4. Dohhhhh ... there appear to be two configuration directories that are identical. Both of them seem to be required for some reason or other. I copied home/.local/share/cura/master to the new installation. Apparently one has to duplicate the 'master' subdirectory in home/.config/cura as well. I am still working on this but yeah, that 'appears' to be the problem .... and 'help>show configuration folder' only mentions home/.local.share/cura/master Why ??? What could be the reason for requiring the same configuration subdirectory in two separate locations ???? I vaguely recall running into this many many moons ago ..... and I am still shaking my head .... I can confirm that if I copy the 'master' configuration folder to home/.config/cura then everything works as it should .... <sigh>
  5. I am trying to move my Cura installation and am having several issues. The most important one is that the new installation doesn't recognize the configuration folder that I copied from the Pi4 Cura install. I am probably missing something very basic but I have been messing with this for a couple of hours and I just can't get things to work. The new installation is on an X86 based laptop running Ubuntu 22.04. I am using the 'master' branch of Cura since I was unable to get the smartavionics Cura 4.20.5 to run on the laptop (another issue to be dealt with later). What I did was to copy the 'master' subdirectory from /home/pi/.local/share/cura to /home/.local/share/cura/ on the new x86 based machine. I verified that I had the right configuration folders via the 'help>show configuration folder' utility. The pi config folder is at /home/pi/.config/cura/master, the x86 config folder is at /Home/.local/share/cura/master. After transferring the config file to the new machine, when I start Cura on the new machine, I am thrown into the first time install/configuration/setup system. What am I missing / doing wrong? Is there a separate file or folder that contains the printer details ?
  6. I have what appears to be a working solution. It does need to be tweaked still but the overall concept works. The user does not need to worry about anything special to modify the g code, the purge works properly with the tool warmed up. This works for a Duet controller but note that the line after 'T-1' only works with version 3.3 or higher. It may or may not work for a duet2 Details as follows: Duet start.g: ; This file is called before any print job file is started T-1 ;(probably not needed) if !move.axes[0].homed || !move.axes[1].homed|| !move.axes[2].homed ; If the printer hasn't been homed, home it G28 ; home the printer before Cura has a chance to mess it up with loading a tool Duet tpost0.g: ; tpost0.g ; called after firmware thinks Tool 0 is selected ; Note: tool offsets are applied at this point! ; Note that commands preempted with G53 will NOT apply the tool offset. M116 P0 ; Wait for set temperatures to be reached M302 P0 ; Prevent Cold Extrudes, just in case temp setpoints are at 0 M83 ; use relative extrusion G0 E10 F300 ; purge G4 T10 ; wait G90 ; Ensure the machine is in absolute mode before issuing movements. G53 G1 X-3 Y339 F6000 ; Move to the pickup position with tool-0. M98 P"/macros/tool_lock.g" ; Lock the tool G1 R2 Z0 ; Restore prior Z position before tool change was initiated. ; Note: tool tip position is automatically saved to slot 2 upon the start of a tool change. ; Restore Z first so we don't crash the tool on retraction. G1 R0 Y0 ; Retract tool by restoring Y position next now accounting for new tool offset. ; Restoring Y next ensures the tool is fully removed from parking post. G1 R0 X0 ; Restore X position now accounting for new tool offset. M106 R2 ; restore print cooling fan speed Note that there are several tool changer commands in there that are specific to my setup. All tpost(n).g files are basically the same with only the tool changing and the tool position changing. Cura post processing, search and replace search string: T[0-9]\n replacement string is empty Regular expression check box checked Note: this only works for tools T0 thru T9. If more tools are defined then you need to change this. Cura startg: G10 P{initial_extruder_nr} S{material_print_temperature} R{material_print_temperature} T-1 M190 S{material_bed_temperature} ;Start heating bed and wait to bed reach temp before proceeding G1 Z15.0 F6000 ;Move the platform down 15mm Note: the T-1 deselects the initial tool that Cura insists on selecting (probably no longer needed) Cura tool start.g, same for all tools: G10 P{extruder_nr} S{material_print_temperature} R{material_print_temperature} T{extruder_nr}; Note: the ";" at the end of the last line is critical! What is happening is that all instances of T(n) (only those on their own line, not those as part of another command) are located and a G10 plus a T(n); command is added. Later on, in the post processing search and replace, the original T(n) command is deleted. The T(n); command only remains because of the semicolon so if that is missing no tools will ever get selected. I think that covers all points. I hope somebody can make use of this ... it certainly caused me lots of grief to sort this out. 0
  7. BTW, I also tried to issue a T{whatever the variable is} in the start script after a home. I was hoping that just like the temperature lines that Cura would recognize this. Alas, it still issued the T0, then it did the G28 from the start script followed by T0 (ie it properly replaced the variable as expected) The command was T{initial_extruder_nr} as per your page here : http://files.fieldofview.com/cura/Replacement_Patterns.html
  8. Well that is a bummer .... having to manually edit the gcode that Cura generates would be a major pain in the behind. A work around of course is to always home te printer before executing the gcode file and a secondary work around would be to not turn off idle hold in the end gcode so that home is never lost as long as power is on. Ok, thanks for responding !!!
  9. Not quite ... when I did the fix for the temperatures, the T0 command stayed. This is my start gcode: ;G28 ;Home M104 S{material_print_temperature} ;Start heating extruder M190 S{material_bed_temperature} ;Start heating bed and wait to bed reach temp before proceeding M109 S{material_print_temperature} ;Wait for extruder to reach temp before proceeding G1 Z15.0 F6000 ;Move the platform down 15mm and this is what Cura generates: ;Generated with Cura_SteamEngine mb-master-20210619 T0 M82 ;absolute extrusion mode ;G28 ;Home M104 S200 ;Start heating extruder M190 S60 ;Start heating bed and wait to bed reach temp before proceeding M109 S200 ;Wait for extruder to reach temp before proceeding G1 Z15.0 F6000 ;Move the platform down 15mm ;Prime the extruder ;G92 E0 ;G1 F200 E3 ;G92 E0 M83 ;relative extrusion mode G1 F1500 E-0.4 ;LAYER_COUNT:99 In other words, the T0 command stayed
  10. Additional info: I am using a Jubilee tool changing printer, When it receives the T0, it loads tool 0. I can place a 'T-1' as the first line in the user start gcode section but there is a considerable amount of action to first load a tool and then unload it and it seems like a lot of action for no reason.
  11. Latest version of Cura but probably an issue for a long time. When Cura generates a gcode file, it looks at the start gcode file that the user sets up. If it doesn't find certain things, it adds it's own set of start gcodes in front of the user requested start g codes. In my case there were four lines added by Cura: T0 M104 Sxxx M190 Sxxx M109 Sxxx Searching on the internet, I have been able to prevent Cura from adding the 'M' codes but I have not found a way to eliminate Cura calling a tool (T0). Unfortunately, this screws up my printer that throws an error when you try to home with a tool selected. In my case I need to do the homing and the main gcode file selects the tool and the temperatures. Is there a way to prevent Cura from deciding that a tool needs to be selected ? I am hoping for something similar to what I found for deleting the other three g codes.
  12. jens55 27 Jun 2020, 18:26 I am experimenting with dual material printing. I find that I have a lot of oozing during extruder switching due to a significant temperature difference between standby and active mode. I had anticipated to compensate for this by using the Cura feature "nozzle switch extra prime amount". After waaaay too much screwing around, I seem to have determined that this feature is only available if you use a prime tower (no mention of this in the little help text and the feature is not grayed out when no prime tower is selected). Is there a magic incantation that makes the extra prime amount feature available without having to enable the prime tower? Using a prime tower wastes a lot of material and also causes excessive switching of extruders (every second layer) which causes things to slow down drastically.
  13. Cura has an entry for heat up and cool down times for each extruder. I am still messing with those and they seem to be inconsistent to my way of thinking about these parameters but they might work for you. In my way of thinking, the heat up parameters in degrees/sec is exactly what you want but I suspect that Cura's implementation of this is not complete or is not working correctly or I misunderstand it's intent. In my way of thinking Cura says 'I will need the next extruder soon and based on how fast it heats up, I need to do so at x time'. The idea being that the new extruder is at temperature when it is needed.
  14. When I do a two colour print in cura and switch to a different extruder, cura powers up the newly chosen nozzle and waits until it has reached operating temperature before it continues. Cura does not however start dropping the temperature of the now unused nozzle to it's standby temperature until the new extruder is at temperature. It seems that the command to drop the current temperature is executed after the command to bring the new extruder up to temperature. The result is that the now inactive but still at temperature nozzle gets dragged over the model and contaminates the print. Is there a trick to get Cura to allow cooldown of one nozzle while the second one heats up ? Of course it would be ideal if Cura could heat up one nozzle, cool down the other nozzle at the same time and wait until both nozzles have reached there commanded temperatures.
  15. I am trying to sort out dual filament printing. For reasons that are a mystery to me, no matter what I do and what settings are, the printer will always prime the first extruder even though no material will be printed for several layers. The sequence will be as follows: Extruder 2 is heated to operating temperature, Extruder 1 is heated to standby temperature. The printer then prints brims (if configured) for the model (in this case overridden to extruder2), prints the brim of the prime tower even though it is specifically not configured. (this also prints with extruder 2). After that, the bottom of the model is printed (with extruder 2). So far, everything is as expected (other than that the brim for the tower was specifically left unchecked). Next, Cura heats up extruder 1 (nothing is supposed to be printed with extruder 1 for a while) and proceeds to print a line around the outside of both brims. Then, it fills the prime tower bottom with extruder 1. All of this extruder one stuff produces contamination of the print that is actually meant to print 😞 In addition, extruder 1 starts to heat up at the very beginning of the bottom layer of the model which results in a fully heated extruder 1 which drools all over the material that was printed with extruder 2. Also of note, I have tried adjusting the heat up and cool down settings for the extruders but that seems to not affect the first layer at all and subsequent layers either start heating at the beginning of the previous layer or at the end of the current layer. I was trying to start the heatup just prior to the layer finishing so the next extruder is heated up just in time for when it is needed but not before (in which case it drools on the previous layer) So, am I missing something here or is the dual extrusion 'smarts' not fully developed in Cura 4.4.1 yet ?
  16. In the past, the setting search box was not too helpful when searching for a word that wasn't the first and I got into the habit of not using the search function. Mind you, in this case I would likely have searched for 'support' and I should have found it. Senility is setting in 😞 Enabled the option and voila ... it's implemented rather odd in that it doesn't do a brim around the individual support lines but the net outcome of better adhesion is the same.
  17. CRAP !!!! I spent forever (well maybe an hour) searching for that option but just couldn't find it! I did look in the settings visibility too, honest 😞 Thank you VERY much. I am making an eye doctor appointment on Monday !
  18. Is there any way to generate a brim for support lines ? When you get very low support percentage the individual lines tend to lift and it would be nice if there was a way to increase the adhesion to the build plate.
  19. Printed with 30 mm/sec all around. Just to clarify, the sequence is : Print inner wall on previous layer increase layer print 'defective' infill line on current layer print a bunch of perfect infill lines print one infill line intersecting the defective line that just barely touches the wall layer (once it gets printed) Print outer wall print inner wall repeat. With the new settings, the 'defective' line now juuuust touches the wall in one out of 3 layers Only the infill line immediately next to the defective infill line shows a reduced overlap (maybe 10%), all other infill lines show the requested 100% overlap between infill and wall. Running the file on a simulator show the end points of the infill lines to be between the inner and outer wall, just as would be expected. There is a definite lag on the defective inlill line for the filament to flow but there is also a noticeable (but not as big) lag on the infill/wall joint next to the dud joint.
  20. Outer wall speed is 20, inner wall speed is 40, infill speed is 10
  21. Turns out it is indeed the first move after the wall but reducing the speed by a factor of 3 did not change the outcome by a bit.
  22. The speeds have already been drastically reduced to avoid just that possibility. I have reduced the infill speed to 10 mm/sec and will do a test print.
  23. ... as requested CFFFP_duet roof molding sample.3mf
  24. combing is off. Would you like me to post the entire file?
  25. The gcode that does layers 4 and 5 .... layer4and5.gcode
×
×
  • Create New...