For the most part the print looks alright but I’m seeing some artifact issues and I cannot figure out how to resolve them, I am seeing them in both SMjs and in Cura slices. I would be grateful if someone would look at my pics and direct me to a link that addresses what I’m seeing so I can learn what I need to do. All prints were in either the PLA that came in the box and Hatchbox. I’d tried multiple settings, temp and speed made a spool bolt to ensure it wasn’t the filament reel hanging up so it’s time to say Uncle and ask for help. Thank you for your time and knowledge.
I have diagnosed my issue and addressed SM support. Unfortunately this isn’t related to part design or slicer settings. I will update the resolution once support gets in touch with me but that maybe a day or two according to the return response I received to my inquiry. Until a resolution is provided I’m dead in the water as there’s no sense in wasting anymore PLA or PETG. If you are seeing similar issues please post with a picture or without an example as I’m curious as to whether mine is an isolated instance or not.
The very first one looks like initial layer height issues.
Most of the others look like the slicers are having a hard time with whatever total wall thicknesses the stl has. I would reslice with the same settings and go layer by layer in the slicer software preview and look for odd behavior in the areas you’re seeing issues with.
Your last post is kind of ominous? Can you elaborate a bit?
Thank you for your reply. On the initial layer height, what would you recommend for this print where I’m cutting text into the bottom layer that should give me a quality surface I’m looking for? Also what do like to normally like to use for prints normally?
As for the ominous post I was reluctant to post my findings as I am not 100% sure of my findings because I don’t have an oscilloscope at home to be able to confirm what I found, so I’m just going by my professional experience. I’m currently employed as a field engineer specializing on 3 axis gantry cranes and at this point and wasn’t wanting to cause a major problem/panic that may or may not be an issue. With that said, explaining what I found to the community as a whole and addressing it in the open hopefully will or should bring resolution quicker.
I noticed that all the flaws you see on the walls always happen at the same location on any cylinder body I print or with the case of the nut it was where that surface was aligned where the surface issues on the cylinder occur. This lead me to believe that there was an issue possible issue with the lead screw causing issues during linear movement as it’s printing.
During a print I could see that there was skipping occurring a given point of the print and I could feel it in the axis. So I stopped the print and turned the printer off so I could physically moved the printhead back in forth to see if I could identify the exact location where a mechanical interference might be happening.
Unfortunately what I saw wasn’t mechanical it was electrical. Not sure of your back ground so forgive me if I state the obvious but a stepper motor will generate electrical noise and current as it becomes a electrical generator when it’s not under load. When I moved the printhead back and forth at the exact point where the scaring occurs the touch screen lit up, now remember the printer is off at this point. This means the the stepper motor is back feeding noise and current back to the motherboard.
These are known electrical principles that get accounted for in design to mitigate their effects. However when I disassembled the linear axis to have a look at the stepper motor and wiring I found no provision to compensate/address for EMI (I.E. twisted pairs, grounded shielding or ferrite). I did not look in the CAM bus to see if they did something there but from an engineering best known practices it’s always best to handle it at the source.
So I made a video of the issue and set it off to SM support and explained my findings. I will order up some snap on ferrite’s to see if this helps but what I really need is to look at the signal with an oscilloscope to fully understand how to fix this the best way.
You don’t think the metal casing is shielding enough? I mean, it’s possible. This could account for the metal bed sensor having issues even if it was bad enough.
Is the thing you’re printing available free somewhere? It seems you have alot of experience with gantry hardware but not with 3d printing? I will check out the file and see if I see any issues, if you’d like.
I was an rma tech for a number of years. I now am a PCB layout designer.
As for the bottom layer, first off, if you’re using raft. Don’t use raft. Raft can work okay in Cura but you have to really dial it in, and the dial in options don’t seem available in Luban as far as I can tell. SOP is to have an initial height slightly less than your layer height. Ex. 0.16 for a normal layer of 0.2.
I’d recommend watching the first layer. There’s been leveling issues for some people. There are various threads on that already though.
First off thank you again for taking your time to help me work things out and it is greatly appreciated!
Got a response from SM support but they are not understanding my explanation, odd because my wife is Chinese and I work on Nuclear power plants in China, just joking! Hehe.
They think I’m talking about the noise you hear with physical interaction between the nut and linear screw and not EMI.
Hi Robert,
Thank you for reaching out to us.
This noise is caused by the relative movement between the screw and the nut and the sound is amplified in the linear module cavity. Here I offer two videos that show you the noise, which cannot be avoided.
We have innovatively adopted the CAN (Controlled Area Network) bus expansion solution, which was widely used in car automation. Rather than adding more ports and make a bigger control board with tangled cables, we’ve upgraded our controller to expand your creativity by providing universal ports, multiport adapters, and a CAN Hub for adding additional CAN-bus ports.
In conclusion that the noise will not affect the print quality and it will not appear when you are printing.
If you have any other questions, please feel free to contact us.
Stay safe.
While CAN Bus is nice you still have to account for EMI so unless their employing some super duper filter in the CAN or compensating for it in software it will be present and have affect on the mother board. As for your question about the metal casing not unless you had a drain wire from shielding using it as a grounding point which the motor does not.
My files are my own I designed it fusion 360, what files would you need to look at stl or gcode and how do I get it to you?
@ NilartPax P.S. I see your a PCB design, is it to early to call you my new best friend???
Have you used your SM to make any boards from home? I’m looking to make one for a electric smoker and dehydrator concept I’ve been working on.
This provides some detail of what I believe to be occurring. I searched it on google to make sure things haven’t changed and to teach an old dog new tricks I may not be aware of.
This explains how CAN deals with EMI it looks at the data returning and can choose to ignore the information but it can still can cause issue not sure how they are compensating or programing for it.
This is a pic from the video that leads me to believe it’s electrical, notice where the nozzle is when the touch screen powers up when I push the nozzle back and forth, now remember the printer is powered down at this point. The electrical pulse happen dead center of the bed at the same point the flaws on the print show up.
if you can look at the files and do a quick print it should show if it’s my software and settings are corrector not.
Thanks,
Robb
Hey @bloodybold!
It´s the same powering on, if you move an axis, on the snapmaker original.- Thats not your print-issue point at this time, i think.
What connection are you using to send the gcode?`
For example, if you use a desktop PC and you are running some rendering simultan to sending the gcode, this could cause a delay in sending gcode and cause your outline issue.
@ xchrisd
Thank you for your help in looking at this with me and @NilartPax.
It is not possible to test this in the normal configuration (powered up) this is because the code provides a holding torque to the stepper motors when the SM1 is idle. If I had access to my lab (DamN COVID_19) I could check the electrical resonance via an oscilloscope. The only other option would be to write new gcode that disables the motors while at idle, but I’m not sure how they are coding for holding torque, if I remember right it should look something like this; $1=255. I will look at the code to see if I can figure it out but normally I rely on my software engineers at work to handle this so I’m rusty/lazy when it comes to doing this, so If someone who’s a little more experienced would like to help out and write a quick machine idle code to disable the motor current I could test it out faster.
gcode is delivered to the SM1 via the USB that was provided with the printer.
Print settings are many but it is more than likely not the cause as it happens even in the default SMjs settings as well, you can look at the code sample I posted two reply’s back.
Only have run PLA and PETG, brands are Snapmaker, Hatchbox and SunLu.
@bloodybold i just have the snapmaker original. if i would disable the steppers which are in idle while printing, for example Z-Axis, the axis will drop.
if you want to try, the gcode command is M18 or M84 (entering via terminal or embedding in your gcode file) :
i think your print-settings are not right.
layer thickness?
print speed
outline speed
base speed
extrusion factor
number of shell´s inside/outside/bottom/top
infill percentage
rollout distance
what software do you use?
i think this is a slicing issue.- i print your test-gcode right now.
You are correct they will fall as there is no torque signal being provided to the motor to hold it in place this is why you see the piece of 2 X 4 (wood) holding the axis in place in the picture.
Thank you! for running the test print as it will help identify if it is in fact software related. Looking forward to your results.
So if I tether my laptop to the printer I can send the M18 or M84 command via Luban??? Could you please provide a screen shot of this, off your computer screen? It will help me to better understand. In the meantime I will connect to the printer and start getting familiar with the interface.
i have the same issues like you, on the leftside it is terrible.- i think you have to tune your retraction and or roll out settings.
i now make a testprint with my parameters. - about 20min
i run my machine with octoprint, so i could send commands via terminal.
if you checking out luban, you have to connect via serial(usb) or wifi.
if you are connected to your printer you could send gcode commands to the printer via console.- screenshots needed?
Also do you know if I need to keep my laptop tethered to the printer after the command is sent to the printer for the command to stay in place? I don’t want to leave my 4,000.00 Mac Pro connect when I’m checking the movement of the printer head and send current back to my laptop and fry it.
try it with wifi if you like to. printing via wifi is not recommened, there are some bugs.
printing over usb is the better way but to check some commands, wifi will work, i think.
Interesting. So the part was designed in fusion 360 and the slice was done with SMjs just modifying the temp settings of PLA the output settings were were left as deafult for to make sure it wasn’t something I erred on setting up.
So my prints show issues dead center of the build plate in the front as looking straight on to the printer and 180 degrees to the back =. you are seeing the same?
(DamN COVID_19) I could check the electrical resonance via an oscilloscope. The only other option would be to write new gcode that disables the motors while at idle, but I’m not sure how they are coding for holding torque, if I remember right it should look something like this; $1=255. I will look at the code to see if I can figure it out but normally I rely on my software engineers at work to handle this so I’m rusty/lazy 
when it comes to doing this, so If someone who’s a little more experienced would like to help out and write a quick machine idle code to disable the motor current I could test it out faster.