changedsoul
-
Posts
74 -
Joined
-
Last visited
Content Type
Forums
Events
3D Prints
Posts posted by changedsoul
-
-
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.
-
22 hours ago, burtoogle said:
I am also using a Bondtech (BMG) and it is configured with acceleration 3000 mm/s^2, jerk 20 mm/s and 830 steps/mm. I am using firmware retraction at 50 mm/s and prime at 30 mm/s.
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?
-
1 hour ago, obewan said:
Unless you have changed it in config.h, marlin sets the max extruder feedrate to 25mm/s
#define DEFAULT_MAX_FEEDRATE { 300, 300, 5, 25 }
I don’t have my config in front of me, but I believe I changed my extruder to 300 also.
1 hour ago, burtoogle said:Hello @changedsoul. Thanks for the file. I can't see anything obviously wrong with the retractions but you appear to have enabled the new nozzle wipe feature which is intended to keep the nozzle clean.
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.
-
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?
-
4 minutes ago, burtoogle said:
Hello @changedsoul, on the Linux side, Cura stores state in ~/.local/share/cura/VERSION and ~/.config/cura/VERSION.
BTW, I created git repos in both of those directories which I occasionally use to snapshot my profiles, etc. Then if Cura goes berserk and trashes everything I can recover my previous state easily.
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?
-
21 hours ago, nallath said:
What standard? Left handed coordinate systems? Right handed coordinate systems? There is no one standard that defines this 😉
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 :
QuoteLeft handed coordinate systems? Right handed coordinate systems?
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 😁
-
23 hours ago, cp2004 said:
For your last suggestion, I think there is an option for that in the preferences, not enabled by default.
For your complaint, I'm not sure what you mean by the arrow in the negative direction. Mine points in the positive. Do you have any special config?
Thanks for spotting that mouse zoom option. Love it.
-
2 hours ago, cp2004 said:
I think the arrow is that way because when you move things around the bed it does it from the centre as opposed to your printer origin. The number in the box when you move are 0,0,0 by default in the centre when the model is loaded, then if you look at that whilst you move it is right. Agree that it is confusing as the x-axis and z-axis are different.
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.
-
Quote
Ah, I just realised, those gaps are because you have coasting enabled. The're not really gaps as such.
No coasting is not enabled. Didnt even have it turned as visible in the options. But what is strange, after going to a pre set of values using the (extra fast) setting, that resolved the issue it seems. Now even when I go back to my saved values, its slicing ok. Like something was stuck.
-
Well I just picked one of the pre set print settings of .3mm (extra fast) and the problem went away. So I must have had some setting messing it up.
-
Yes, I is intended to be a cover for something. I was going to print it translucent and have the text appear thru the inside. First time I ever tried to print something that I wanted a single wall and also some solid.
Im getting the same thing every time but it different locations.
My printer is configured for a .6mm nozzle. I tried changing the Line width to .5 and the Wall thickness to .5. I honestly don't know which one to change, one or the other or both. I just changed both and still get the gaps.
I noticed when I increased the layer height through the gap shrunk, but it was still there.
Could you maybe share a saved project with the settings you used so I cans see what I am missing?
-
Hey there smartavionics.
Thanks for providing a download to a patched version of cure to allow single wall printing. I just came across this issue myself and landed be here at this very long forum post.
Question for you, Do you know if this gap here in the corner (circled with a ?) is part of your patch, or another setting? I tried a bunch or settings and could not get this to disappear.
I attached the model if you wanted to see if it further put your patch to the test.
-
First I would like to start of by saying thank you to who ever and all who updated the UI in cura. Currently the beta is a dream to work with as far as manipulating the model and rotating the workspace. 3.x was so sluggish and such a horrible performer trying to zoom in and rotate the workspace, especially when you have sliced data on the screen. So excellent work to who ever fixed that HUGE problem.
Now the suggestion?
I noticed the parameters section is not in a drop down menu of sorts. It would be nice to be able to expand that further down the page if possible, and have it remember the settings. Having a small window with a long list of scrolling sort of sucks.
Also, when monitoring, the layer number slider would seem better positioned to the left of the print parameters and not to the far right of the screen.
Also the new file menus seem to be of a particular font and size where they all seem to run together and its a bit hard to easily see their separation.
Also, the ability to zoom into the workspace where the current mouse position is, similar to other cad software.
And the complaint!
The Axis identifiers that appear when you click a model "should" mimic the printer coordinates. Meaning as it is now, the Y-Axis identifier is backwards. The arrow points in the negative direction and when you move in the Y-axis, the position relative to the table zero, is positive. To clarify, when the model moves to the front or near side of the table, the Y-Axis position should be displayed negative of zero (currently it displays positive), and when you move the model to the rear or far end of the table, the Y-Axis should display positive from zero (currently it displays negative).
This has been going on since the dawn of time it seem, why cant this be corrected? Its not correct...yes it functions and we can print, but its not correct. (My OCD kicking in).
Thats all. Again. Awesome job on improving that UI performance.
-
Same thing happened.
I moved the z up a ways slowly and noticed it swaying as the threaded rod spun.
Pretty sure this is my issue.....and if it’s not, it’s “a” issue and needs to be fixed.
Hopfully it clears this mess up.
-
nothing obvious has changed.
The fan turned on after just a few layers and was on for the entire print.
I printed two of these, one with no cooling fan for the entire part, and one with cooling fan for the entire part.
Both resulted in a mess right after the part began to angle in smaller.
If its an electronics thing and time, I am going to print two items on the table with the same settings. If it’s a time and heat or electronics failure, the poor print should show itself earlier in the print. I don’t know what else to try.
-
Yes I am using Cura.
I haven’t looked at the layer view in software. I’ll do that and see if something stands out.
I didnt see anythig.
Looks the same at the top as it does at the bottoms.
Something is changing near the top.
Could it be heat getting trapped in inner parts as the duct begins to close making it hotter than normal?
grasping here.
-
It’s not an ultimaker. Its a coreXY style where the table moves up and down.
Its pla, yes.
Z axis screws are clean, and there is no filament binding going on. I was going to say it looks like under extrusion to, but I am not sure why, if that’s it, why it’s happening.
I thought maybe the fillament was clogging and the extruder was having trouble pushing, but I looked at the fillament and it’s got no signs of slippage.
Since i I printed the same model twice, would it be electronic in nature?
somethjng taking that long to heat up and begin causing issues?
Is this even possible?
-
Can someone help me with this?
i tried printing this twice, once with out a cooling fan, once with a cooling fan.
Tried incteasing the temp, tried decreasing the temp.
What ever I try within the limits of my knowledge results in the same thing.
Matter a certain height the print just turns horrible.
It starts out great.
I am using 50deg bed, and 210 deg nozzle.
How the image is ok, taken with my iPhone
Support Blocker Has No Effect
in UltiMaker Cura
Posted
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.