changedsoul

4.6.1 Support blocker still not working. Support would seem to be a critical part of 3d printing. Why does it seem cura doesnt want to improve it? Seems all the effort is going into experimental options while support blocker is never getting out of experimental.

Hello, I noticed the G-Code reader plugin displays incorrect lines or no lines at all when the gcode imported is using relative extrusion. Can this be easily fixed. I cannot locate the plugin to look at it myself. I am using an AppImage under Linux.

I do not know what you said, could you respond in english.

I noticed on 4.5 the Z-XY Positions for Z Seam Position are never made visible. I always get a message when I go to settings saying they are hidden because if Z Seam Alignment setting, yet no matter what I select, it is never made visible. Has this been made broken in these later releases, or maybe moved and the settings left stale? The issue still persists in version 4.6 as well.

I was using firmware retraction as well. The code I posted was using non firmware because I was going back and forth seeing if it would output retract moves during a move line. It appears both methods produce the exact same output. I tested a firmware and non firmware retract program and it seems the firmware (G10/G11) is actually slower than specifying the actual movement. I read that firmware retracts are supposed to be faster, but what I am observing is the opposite. While I like the idea of being able to adjust retract settings without re-slicing, I think I have to abandon that. I also noticed my extruder doesnt have a smooth movement at high speeds. It sounded like binding gears and such, so I removed the planetary reduction add on and it was still present. Trying to feed it 100mm in length and a speed of 65mm/s causes it to stall. Dropping it to around 60 will keep moving, but its probably close to stalling so I dropped it down to 50mm/s to be safe. While its moving though, I can hear a very uneven sound coming from the motor. So I can only speculate its a crummy driver (which is possible), or my arduino cant keep the pulses going to it steady while doing other tasks (which is probably also possible). Maybe its time I drop the arduino all together. So I am thinking the G10 may be slower because instead of just executing a line telling the extruder to move so much, its got to go into another subroutine possibly causing more overhead than a standard move? I dont know, I just guessing here.

Perhaps. I believe my extruder acceleration is set at 4000. I guess I need to experiment more. Maybe I can set my retract for like 65mm and then play with some settings and see if I can get it to do it in a second at 65mm/s give it take the ramp up and down speeds. I guess I can just crank the tops speeds and acceleration for the extruder up up and away and see what comes of it. Its a geared Bondtech extruder. Anyone by chance know it’s max speed before it looses steps?

I don’t have my config in front of me, but I believe I changed my extruder to 300 also. Yes, I was playing with settings trying to see if I can get it to keep moving while it was retracting. So so is there a way to do what I am asking? i have to retract 3mm to stop oozing. That 3mm kills my top surface when it pauses on the surface to retract. A nice linear move while it’s retracting I suspect would solve it, but I am just speculating.

Here is the boat. You can see every time there is a retract, its all alone on its own line. and the longer the bowden tube, the longer it needs retracting, and the longer it sits over the part while its retracting. Is there a solution to this, maybe a setting for a work around? And I know the code says I am retracting at 65mm/s, but I can visually see the printer stop while retracting for a good 1-1.5 seconds. This very well by my firmware and arduino brains causing it as a 2.5mm retraction at 65mm/s should be virtually instant, but its not. Thats why I am hoping there is a solution. CFFFP_3DBenchy.gcode

I need a bit of help. I have enabled retraction which seems to help very well for stringing and blobs. The problem I am having is "it seems" while watching it print, that it pauses over the last printed area while its retracting, leaving a scar / melted spot on the surface. While this seems to not be an issue if you have a direct drive as the retract time is so small its hardly noticeable, but with a bowden tube, that extra second and half or so makes all the difference. I have tried upping my retract speeds to upwards of 100mm/s, but to be honest I dont see much change in time between 30mm/s and 100mm/s. I am using Marlin firmware, and this speed issue may just be a limitation of the arduino. What I am hoping may solve my problem, or perhaps someone else can offer a other solution, is if its possible to issue the retract during a rapid movement to the next location. That way it wont pause over the printed area you just got done with. Is there a setting that enables this? Currently the code output always has a retract on its own line and thus the pause while the extruder retracts. It seems to me that even if I could retract faster, it might be even better to just retract while its going to the next location. Is this possible?

What would be the equivalent directories under windows? I notice there are a few places, AppData/Local and AppData/Roaming. Roaming seems to be the bulk of it, but I can not seem to get my print settings to carry over. I tried placing the the AppData/Local into the .config/cura with no luck. I also seem to have a cura folder under .cache, so I have three, one is .cache, .config, and .share.

Has anyone tried this? I dual boot between windows and linux. I hate having to boot into windows to make a print when I am currently working in linux. I copied my cura folder AppData in windows into the .local/share/cura just to see if it would pick up the settings. It seems some settings came over while others did not. Settings like which print settings I have hidden or shown did not carry over. It seems my custom print profiles got picked up. Im wondering what locations cura uses when loading so i can link them in linux to the windows locations so "I hope" I can just boot back and forth and have all my settings shared between boots. It seems cura uses more than just the location in Appdata. Has anyone tried this with success without corrupting something?

That is a good point, which one are they using really? The table uses right, and the model uses left, so which one is it? By standard, I mean the one taught in every textbook for Cartesian coordinate, what every ( as far I a know) Horizontal mill uses as its coordinate system. And for the most glaring obvious reason to fix it, because you mentioned it : The right handed coordinate system has the answer "right" in it....its the "right" one, as apposed to the left, which is the "wrong" one 😁

Thanks for spotting that mouse zoom option. Love it.

I have to say I strongly disagree. It doesn't matter where your printer origin is or the center of the bed is. Y+ should be UP and Y- should be down. Just like a Mill, just like a graph. Thats the standard. Cura has the X and the Z correct. X+ to the right, Z+ towards the top. Y+ "should" be UP (towards the back of the table) Just like a standard XY graph, with X axis to you right, and Y axis going up. Even if I move my printer bed origin to the center of the table, the Y-axis is still backwards. Im telling you, the coders have screwed something up. I just dont know why nobody else seems to see the problem. Maybe they know about it, but its so heavily depended on how it is that it would be a major haul to change it? I don't know. Either way, its wrong. Y+ should be up. To say otherwise, we might as well just make X+ to the left, and Z+ towards the table.

I wish I knew. Its possible I guess I have something jacked up. Don't know how I could though. I setup my print as a custom printer and set my nozzle and bed size and that is it. Check out the pic. The table has the Axis orientation correct, with Y+ going front to back, but if you look at the model, the Y-Axis has the plus going backwards. Even when you move the object, the location in the Y-Axis from origin is also backwards. When I move it towards the front of the table (closer to you), its reading a positive shift when is should be a negative. I brought this up a long time ago too. If its a setting I have and can change that would be fantastic.