ATOM 3D Printer Group 造訪社團

Pronterface, Repetier host is for control 3d printer via USB. Not for upload fw.
ref: http://www.pronterface.com/

The same noise that made before reuploading the firmware

The lateral fans are not working

Is the fw from http://www.atom3dp.com/en/support/ ?
It should be the latest.
earlier version might have some bug.
BTW, remember to enter LCD menu restore failsafe & save

I can't identify the noise in the video yet, is there a longer version?

My guess is the printer's firmware got corrupted. Reload it (you use Arduino for this) then be sure to use the LCD to do Reload Fail-Safe and then Store Memory. Neither of these commands gives any feedback, but if you watch closely you'll see that the Store Memory command causes the LCD to blink once very quickly.

Before you do anything else try and unplug your printer. Pull out the power plug in the printer and USB if any. Wait 10 seconds and try printing again.

If possible,find a power supply replcement to identify if it`s the root cause.
BTW, also check if there are any short circuit on heating elements.

Birk Binnard Did you try to use restore failsafe first? I am wondering if it's some variable value changed in eeprom instead of the fw corrupt. The fw corrupt should be very rare to be happened.

Hi Clarence - yes, there were a couple of occasions when, after my Atom2 started doing strange things (like trying to do Auto-Level in the middle of the build space) that the only way I was able to get it back to normal was to physically reload the fir mware from Arduino, then do Load Failsafe & Store Memory.

All of these situations followed my early use of the Craftware slicer. Earlier version of that software apparently generated some GCode command or set of commands that scrambled Atom2's firmware memory. I understand this is unusual and clearly not expected, but it did happen to me on more than one occasion.

Sometimes the Atom2 would do worse things - like start to vibrate badly when I did an Auto-Home from the LCD. I was afraid I might break one of the stepper belts when this happened. Other times it would try to print below the Z=0 level; my printer bed has some scratches now because of that.

Fortunately I've only found (so far) one GCode command in the current version of Crafware that I have to comment out - it is an M83 command that is put at the beginning of the generated GCode.

It seems very abnormal to me, anyway I am not on arduino based controller for a few months. I would try to load the fw on my mega2560 for verify if it's reproducible on my setup.

@Clarence Lee, which controller do u use on your ATOM now? AZSMZ with Smoothie?

Rick Yang yes, but would like to move back to Smoothieboard 4X. When I finished the extension stepper driver wrapper board for TMC2100. I also have RADDS+BBB+Machinekit & DUE+Repetier on the lists to test.
I use smoothieware since last Sep.

looks like the error is come from power supply, maybe you can change it and try again

那個馬達哪裏買得到啊？水族館嗎？

馬達測試中，一般人是用沉水馬達的樣子，我用抽水馬達，電壓額定12V只開5V， 先試看看壽命，不行的話要再改設定

Is it real string by travel?? looks like loops(wall thickness) not enough, the sphere don't have enough adhesive to previous layer.

The Rhino model for this piece has 4 surfaces: outside, inside, top, and bottom. Originally, when I made the model for the small orange version, I had the inside and outside surfaces so close together that the final print had only one wall and it was 4 loops thick.

I thought that was not sturdy enough for a large version, so I changed the model to have more distance between the inner and outer surfaces. So in the large version the inside and outside surfaces printed as 3 loops thick and are separated by a small amount of infill.

All t his leads me to believe the strings really are strings and not loops from the inside surface. Also, even though it was difficult to see clearly, I did not notice any missing loops from the inside surface. I guess I'll find out for sure next time I print something like this part.

Try to review the gcode preview layer by layer might be helpful to find out the destring & travel point ^^

That's an interesting idea but I'm afraid I don't know enough GCode yet to enable me to reach any conclusion - or to even find the right place to look for something in the GCode file.

http://gcode.ws
or in Craftware, there should be a playback function for preview?

Ah yes - I should have thought of that. Craftware has a very nice playback function that I only looked at briefly a while ago. So far I have never had a need to use it - but I'll try it now.

Thanks for the suggestion - I would not have thought of that. Will let you know what I find out.

I looked at about a dozen layers of GCode in the shoulder area and traced the extruder path and found nothing that looked wrong.

I guess it is possible that what happened was that in that area for some reason the inside loop simply did not attach/adh ere properly to the loop below it. It was difficult to see what was happening inside there.

At any rate, increasing the Retract and Prime values by 0.5 mm should not hurt anything, and just might help.

Another thing I might try is to reverse the order of loop printing from perimeter ==> loops == > fills to fills ==> loops ==> perimeter. That way I think the currently printing loop would have more of the lower layer loops to stick to.

yes, should be that order would help on overhang