ATOM 3D Printer Group 造訪社團 » 韌體相關話題

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.

what did you improve in it ?

這個版本沒有 M666, 對吧？

非官方2.0.4通用包..
預設1.x可用
configuration.h的// # define ATOM2 前面的//拿掉就可以2.0用

Is side fan blowing when it's 16x/200 ?
Is bottom wind shielding available?
Where did you get the thermistor?
Is it NTC 100K?
B 3950?
Or even have a model number like MF58

請問"暫停列印再繼續列印"的一段source code 在那一個檔案?

Yang Momo 神，請問你是 Base on v2.0 改的嗎?

ultralcd.cpp

請問這修改適用ATOM 1&1.x代的機器嗎??

超神

強.........

其實我比較想用強一點的版子，寫個新的韌體

請問ㄧ下，這個暫停接續功能，是可以暫停多久? 溫度還是一直保持嗎？

http://www.ustream.tv/recorded/80426308
這是1/16 DRV8825
(MS1 MS2jumper拔掉.. M92 X80 Y80 Z80 E100）

Bug.

Yes - I thought it might be something like that.. An easy fix for sure. But for me 2.04 has the same problem as 2.03 - it does not remember the Z-offset values. So I will go back to 2.02 (again.)

Looks like clogged nozzle?Some toothpicks worked really good for me.

It was a clogged nozzle. Fixed it with the 0.400 mm drill and a small unfolded paperclip. US toothpicks are too thick. I wonder if there is an actual tool made for cleaning out 0.400 mm hot end nozzles. Seems like there should be.

And I wonder what causes the nozzle get clogged in the first place. Seems to me when it gets hot any PLA inside would get forced out by new filament entering the nozzle.

z tower?
did you restore failesafe?

yes

i pressed "restore failsafe " => "store memory"

What about back to 2.0.2 or previous version? Is the problem still the same?

actually it would be prefect if Atom company would offer complete guide to assist with the upload VIA Arduino

this is the link to my FFF file using simplify 3D software https://www.dropbox.com/....../Atom%202.0.3.fff......

if anyone can assist me to check what's wrong with it - i did try CURA just now and everything works greate with it - the Z axis is preforming good

https://atom3dp.squarespace.com/power-on-testing....../

hi Idan your link is dead :( can you share it again ?

在處理G0,G1那邊加入判斷式，先取座標絕對值，再按同心圓的方式分出幾個速度修正比重，然後將gcode 裡的速度值作出修正，然後傳入queue 裡就好了。

但記得原始速度要保留作為加權基礎，不然會出事。

雷射毛邊長度？

但是現在困擾的是在外圈時各馬達速度不一樣，要看與連桿的幾何比例來調配，不然就脫桿了

脈衝雷射模組似乎有M5關閉後的時間差，導致模組移動時還有雷射，會造成拖尾，我想在M5加入一個Delay來解決這個問題，但是內外圈速度不一致的話Delay也要隨位置變化才行

幹嘛管馬達？

那個問題不是時間差造成的，我搞雷射時遇到也解決了。

那問題是出在哪個環節？

那是queue 的機制，你得先確認跑完再送指令。

這樣說來應該要在M3執行前加個條件檢核？ 不過程式語言不熟悉，條件函式應該怎麼下？
不過G1不是跑完才會走下一行的指令嗎？

我的雷射控制程式

St_syncronize(); 是關鍵

感謝！這條函式太重要了！（筆記）

前幾天看到一篇論文 可以解決雷射在動作上的同步問題 不知能不能把這技術放進去。
應用位置同步輸出之觸發控制雷射於銦錫氧化物薄膜微加工
http://ndltd.ncl.edu.tw/....../ccd=NDdYlL/record......

Po-Hsun Peter Wu 2.0.3版的韌體整個簡化了雷射部份的code，結果同步問題就跑出來了，建議修正一下code

修正前後差異

換完小心檢查絕緣

哪裡有料可以換

http://goods.ruten.com.tw/item/show?21211061436399 .

要調整噴頭旁微動開關的螺絲

收緊還放鬆？Home 時如圖，正常嗎? Home 時如果 Z to Zero，還會往上衝。

會往上衝就是太敏感了, 要嘛放鬆螺絲, 不然就把上蓋再弄鬆一點

謝謝大大，攪定了