ATOM 3D Printer Group 造訪社團 » 線材相關話題

用透明的物料,去洗到沒顏色,就可以了~~不用浪費錢

謝謝

求分享 XD

有沒有stl 分享

印薄一點當燈罩好像也不錯！

跪求STL檔.要印給老爸

看來看去 比較喜歡這個黑色的凹體字 ~
不曉得糖果紅印出來會長怎樣 ~

縮小改字版：8公分直徑、翩翩體

大神.....這些照片給我放以後的網站當樣本吧.......

感謝丁大～ ^_^

我印出來每一排都會有一條線，不像大家印的表面那麼滑順，跟我用層高0.4有關嗎？

能不能分享stl檔 , scad要跑好久喔

I think it's normal.
Perhaps only 0.1mm difference from each side, and it's smaller than auto-level tolerance..

Well Charlie, you could be correct. I decided to let the print continue as is because it seems to be going OK. I don't recall seeing this issue before, but then I also have not printed anything of this shape before either. Makes me wonder if this situation is unique to my printer of if others have encountered it also.

Try board roughness from 0 to 0.3 mm, and see what happens.

That's a new one for me. Is that an item on the LCD screen?

No. Do it from KISSlicer.

Oh. Well I don't use that slicer. I use Craftware and I don't think it has any option like that.

OK - I did a little research and discovered the following:

1. Kisslicer's Bed Roughness adds the given value to first layer height and increases extruder flow to compensate for the larger extrusion.

2. Craftware has a whole section of parameters for controlling the first layer. The pic below is what my settings currently are.

My standard layer height is 0.200 mm so it's not clear I should increase First layer height any more than it's current 0.350 mm. But maybe I should increase Extruder Adjust to something like 180%.

I think Z adjust = bed roughness.

Yes, I agree. But I use the Z-Adjust function of the LCD menu.

I would call this symptom not precise/correct enough measurement on Auto Level running.
There are some variable could trigger this result.
Usually I would monitor Auto Level many times to make sure it's result reproduced or difference a lot. (from pro nterface to check G29 array result, record them & compare.)
Actually some little check/ fix on all moving mechinical related to the effector, Z min endstop, signal cable length, even ptfe tube seperation might made different stability quality.

The part took just under 12 hours to print, but it did finish OK. There is a second part of about the same size that goes with it and I hope to post results in another day or so.

Since it did finish OK I guess i should not be so obsessive/compulsive a bout a slight problem with the first layer. I will try varying my Z-Lift value a little to see if that helps the situation at all, but I'm not likely to do anything more complex than that. I understand the things Clarence pointed out, but the results I'm getting suggest my printer is basically OK and does not need any detailed tweaking.

The Zebra Plate seems to be the reason for this issue. I took the plate and the finished part off the printer to separate the 2, and I really paid no attention to the orientation of the plate when I put it back on the printer. But when I started printi ng the next part I noticed that the thin area had moved to a different direction completely. So this tells me that the Zebra Plate may not be exactly flat, or there may be some un-evenness in the way the plate sits on the glass print bed.

it's foldable, so it's not perfect flat, it's also the reason why clips required. I have some mark to keep it place at the same direction.

Hey Birk Binnard ,

You're not alone. Experienced that one for a long time. Solutions for me: Running Auto-Level at 10% Speed (instead of 50%) really gives you much! It costs more time but is amazing.
And: Auto level 2-3 times and check if the printer has different results, especially more than +/-0.1mm.

In my case, doin auto level with 10% solved that problem for me :)

Joschka - what a great idea - thanks. I would never have thought of that. Will give it a try when my current print finishes (sometime tomorrow.)

Sure thing.
I was wondering if you might have experienced the same:
When the printer moves, executing his gcode command, and you turn the knob for any menu thing - does the menu react? Or does it first react when he "finished" that g-code line / move?
This is what was wondering me. As in my case, he doesn't react until he finished the line, resulting in wrong choices in the menu etc.
But on top of that - I got the feeling that his "reaction time" is around 2-3 seconds. This can also be seen while he does auto level - in my case he moves to "Z -20" and hits the bed with the nozzle. it >should< show now what value Z has on this point - but sometimes it doesnt, he just moves to the next point. When doing Auto Level on 10%, he shows it.

On top of that: Imagine the printer moving to Z -20 on Auto-Level. Doin this with 100/50% speed, he "crushes" into the bed too much because of his reaction time. 0.11mm too much for example. Next spot hits the endstop RIGHT on the spot with the reaction time - 0.00mm too much. Next one reacts in between, 0.05mm too much.
Hope you understand where I'm getting here. As far as I know, the Atom Printer runs an 8 Bit processor - which is actually not so ideal for a Delta printer. Dunno if a 32bit system would help with that reaction time.
Just my thoughts and my experience - hope someone can clarify this :)

The only time I do anything with the LCD panel while the printer is printing is to Pause a print, then Auto-Home, then Stop Print. This happens when I see there is something going wrong with the print or when I want to stop it for some other reason. So I can't really address the issue you raised.

From a programming viewpoint I can see how the firmware might disable all interrupts during the execution of a GCode command. This would be a logical thing to do since a single-thread processor can only do one thing at a time, and since the firmware has to take into account things like acceleration and momentum it could easily lose track of what was going on if it had to switch to another activity while the printhead was in motion.

I've often thought it would be a good idea for 3D printers to have motion control sensors that tell the machine where the printhead actually is, how fast it is really moving, etc. That way there could be correction commands given in the event of a stepper motor missing some steps, or some sort of interference with the printhead itself.

I agree that an 8-bit CPU seems a bit weak for this kind of use. Frankly I didn't think there were any 8-bit CPU's still out there. My first computer had an 8-bit CPU (Intel 8080, subsequently swapped for a Zylog Z-80), but that was more than a hundred years ago!

I guess that, in the case of a 3D printer, the CPU doesn't have to compute any faster than the printer itself can absorb commands. And this is limited by physical things like stepper motor size, the amount of moving mass, etc.

https://atom3dp.hackpad.com/Faster-deltabot-kossel......

Did you try the 1/16 microstepp setting? It should help a lot about the performance.
http://reprap.org/wiki/Step_rates

Very interesting. But I am neither brave enough nor smart enough to try changing motherboards.

COOL!

請問 是用哪塊板子接這八顆馬達的啊 ?

看起來 arduino uno + 擴充板？

這牌子的料.好印,顏色漂亮....3MM 殘念!

是啊...