3D打印过程当中如果出现错层，会导致整个模型打印失败，严重的会造成打印机故障。虽然简单的错层可以通过后期打磨进行修复，但是严重的错层必须找出背后原因，否则会在下一次继续促成，甚至会导致喷头无法修复。
出现错层，然后没有停机，继续打印。往往出现在无人值守的打印过程中。如何减小出现错层的几率？
1.谨慎进行中途调速或速度过高。有的打印机支持调整速度。例如下图显示的s代表speed。初始默认为百分之百。也就是在设置打印文件时的速度。但是在打印过程当中可以动态的对该直进行调整。可以出现200% 300 400甚至更高。当打印机响应调速之后，速度会明显加快，并且电机声音频率会提高。
调速无疑可以减少打印时间，但是后遗症也很明显，那就是一旦出现喷头高速运动中被阻碍，极易出现错层。因此必须谨慎使用，而且要坚持有人值守。必要时可以在编辑打印代码时调整速度。
2.喷头滑杆受阻。
可以利用专业的溶剂进行清洗，同时用干净的纸巾擦除连接杆上的污渍。没有专业溶剂时，可以使用防锈润滑剂，同时要注意不要在喷头运动中对连杆进行擦拭。在喷溶剂时，不要喷到电器设备上。应尽量保持室内的清洁，在条件允许时应该加装净化器。室内的清洁环境有助于打印机寿命的延长。否则毛絮积攒在杆上会影响打印进程。
3.打印皮带或其他传动件松动或磨损。
出现皮带受损起边或其他螺丝松动的情况，应及时进行维修。
4.模型的代码问题。
以repetier软件为例，显示物体不是流形，也就是不是封闭实体，需要修复。
查看日志文件，可以了解更多信息。
20:51:21.676 : OpenGL extensions:GL_3DFX_texture_compression_FXT1 GL_AMD_depth_clamp_separate GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ARB_ES2_compatibility GL_ARB_ES3_1_compatibility GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_bindless_texture GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_cl_event GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_color_buffer_float GL_ARB_compatibility GL_ARB_compressed_texture_pixel_storage GL_ARB_compute_shader GL_ARB_conditional_render_inverted GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_cull_distance GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_indirect GL_ARB_draw_instanced GL_ARB_enhanced_layouts GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_fragment_shader_interlock GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_geometry_shader4 GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gpu_shader5 GL_ARB_gpu_shader_fp64 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_indirect_parameters GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_polygon_offset_clamp GL_ARB_post_depth_coverage GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior GL_ARB_robustness GL_ARB_robustness_isolation GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_atomic_counter_ops GL_ARB_shader_atomic_counters GL_ARB_shader_bit_encoding GL_ARB_shader_draw_parameters GL_ARB_shader_group_vote GL_ARB_shader_image_load_store GL_ARB_shader_image_size GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_stencil_export GL_ARB_shader_storage_buffer_object GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_border_clamp GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_cube_map_array GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_mirrored_repeat GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_transpose_matrix GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_64bit GL_ARB_vertex_attrib_binding GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ARB_window_pos GL_ATI_separate_stencil GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_polygon_offset_clamp GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shader_framebuffer_fetch GL_EXT_shader_integer_mix GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_storage GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_IBM_texture_mirrored_repeat GL_INTEL_conservative_rasterization GL_INTEL_fragment_shader_ordering GL_INTEL_framebuffer_CMAA GL_INTEL_map_texture GL_INTEL_multi_rate_fragment_shader GL_INTEL_performance_query GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_context_flush_control GL_KHR_debug GL_KHR_texture_compression_astc_hdr GL_KHR_texture_compression_astc_ldr GL_NV_blend_square GL_NV_conditional_render GL_NV_primitive_restart GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SUN_multi_draw_arrays GL_WIN_swap_hint WGL_EXT_swap_control
修复也是部分的拯救。
20:58:44.470 : Error drawing 3d view:Failed to make context 65537 current. Error: -1073283041 / 在 OpenTK.Platform.Windows.WinGLContext.MakeCurrent(IWindowInfo window)
20:58:44.470 : 在 RepetierHost.view.ThreeDControl.gl_Paint(Object sender, PaintEventArgs e)
20:58:58.430 : gl_Paint-2.OpenGL error:InvalidOperation
虽然还有一部分错误，但是勉强还是可以继续进行下一步切片的。否则无法进行打印。
分析模型，查看有无错误。
还有可能的链接问题：
打印机固件：固件具有用于传入和传出消息的通信缓冲区。它使用行号和校验和检查传入消息是否存在通信错误。
打印机 USB：这是 USB 串行转换器，打印机固件通过串行连接或集成在打印机固件中的本机 USB 驱动程序与其通信。
USB电缆：没有有源元件，但电气噪声，不良触点，不良屏蔽或只是长电缆都会在这里增加通信错误，因此它可能是故障源。
Usb Hip（可选）：某些用户具有级联 USB 集线器以获得足够的 USB 端口。每个中心都必须拆分并重新发送数据，以便再次提供源。
你的电脑的USB，PC操作系统：操作系统串行驱动程序看到设备，在操作系统中创建一个要连接的通信端口。
以下是详细解释。https://www.repetier-server.com/knowledgebase/printer-stops-mid-print/
Printer stops mid print
When the printer connected successfully and you could start a print, the connection settings are normally at least 95%. This entry tries to guide you, in case you could start a print and later on the print stopped for unknown reasons. That is something that normally does not happen, so there must be a reason. And often if the causing reason does not get removed it will happen over and over again. So if you have frequent unintentional stops, follow this guide and see what it is.
First thing you need to understand is how the communication flow is. The flow from printer into Repetier-Server takes the following steps.
Printer Firmware: The firmware has a communication buffer for in and outgoing messages. It checks incoming messages with line numbers and checksums for communication errors.
Printer USB: This is either a USB-Serial converter and printer firmware talks to it via serial connection or a native USB driver that is integrated in the printer firmware.
USB Cable: No active component, but electric noise, bad contacts, bad shielding or just long cables can add communication errors here, so it is a possible source of failure.
Usb Hip (optional): Some users have cascades of USB hubs to get enough USB ports. Each hub has to split and resend data, so possible source again.
Usb of your PC, PC Operating System: The OS serial driver sees the device, creates a communication port in the OS to connect to.
Repetier-Server connected vie communication port
As you see there are up to 6 instances involved and each has it’s own possible source of problems. So the main step required is to find out which device is causing it and what can you do against it.
One of the most important parts to identify the problem are log files. On server side the relevant parts are server.log which shows when a serialconnection gets opened or closed. It does not show the reason though. But it is with these informations at least possible to identify the timestamp when exactly the problem happened. The other server file is server print logging. You can enable this in printer conext menu. Normally it is just unneeded information and writes, so it is disabled by default. But when you are searching why you are loosing connections you should enable it. Part ofit can also be seen in the console, so that is also a nice source for real time view of problems, but you only see result of last 2000 lines, so information might be gone when you need it. The last are logs from the operating system. For linux this is the file /etc/logs/system – which you can download in the server log window as well. Note that syslog gets rotate on dayly basis, so if you download you always only get the one for the current day.
First check is connection quality when it works. So for a longer print check a log and count how many resend requests you see from printer and how many timeouts you see.
A resend happens when a firmware receives a command with checksum and the checksum does not match, so it means the line we did send is not identical to the received one. Something between step 5 and 1 changed the content or dropped part of the data send.
Especially with real serial<->USB converter a modification happens easily. There is no timing line, so if clocks of devices are not running at exactly same speed they might misinterpret a bit every now and then. When the printer allows switching baud rate you can try switching 115200 with 250000 or the other way around. Sometimes one of them creates less errors. Speed wise it makes not much difference as usb latency is the main speed limiter.
If you get very frequent resends, like 1 every 5-10 lines, your setting for input buffer size is too high and we are sending more data then the printer firmware can cache. Reduce it to 63. If that does not help switch to ping-pong-mode where we only send a new command when firmware marks the last send command as finsihed.
Timeouts are a result of communication errors in the other direction from printer firmware to server. For every command we send, we need to receive one line that starts with “ok”. A typical case is that the “o” is missing and “k” is not “ok”. So we wait and wait for it and firmware is waiting for next command not knowing that we did not receive the “ok”. So after the set value of “timeout” seconds and when we know the command should be fast, we assume this case, write the timeout message and continue sending data. Here you need to watch out to shoose a good value. Modern firmwares support a busy protocol, meaning if a command takes longer it send “busy” resetting the timeout every 2 seconds. In this time you can set timeout to 3 seconds and have a fast recover. If this is not supported, timeout should be 30 seconds or at least longer then the longest slowest move you plan to execute. Often this is a z move from top to bottom.
Especially if you get a good combination of timeouts and resends more frequent then one every 1000 lines (many printers are even much better, but I think below is a value where you really should investigate for the source), you have some electronic interference. This can be a power cable next to unshielded usb cable or heater/motor cable close to communication cable inside printer, long cable making problems, and more.
It might also be that the printer it self has a problem. Known problems and signs:
Firmware detected a recoverable error: In log/console you see normally a message from firmware with the info that M999 would restart firmware again. Newer server version also often give a hint depending on error and firmware.
Firmware detected a non recoverable error: Some firmware errors are thought of as critical by firmware authors and they stop firmware and keep in an endless loop. In console you typically see the reason. They ignore all communication until printer is reset.
Printer did reset for some reason. Many firmware will send the reason on next connection. If you see a message about brown out this means the printer had undervoltage. Watchdog means printer firmware had an unexpected hang.
Next big field is power. Especially the cpu boards of the printer can be either powered by main power of printer or from usb and main power. Latter case can draw power from the printer PC. USB 2.0 allows 500mA, but they might draw more or usb might not be able to send as much (especially passive hubs). Especially on tiny PC like the Raspberry Pi which is very sensitive to power issues, this can cause all kinds of problems form just a warning over disconnected printers or non working printers up to crashing operating system. For the Pi we have a hardware info in Repetier-Server GUI (bolt icon) that shows if the pi had or just suffers undervoltage, just because this is such a frequent issue for problems. Read this article for possible solutions: Undervoltage and throtteling of Pi
Linux actively closes usb connections for four reasons:
You unplugged the usb cord or disble dthe device so it stops communicating. That is the obvious one you can easily rule out.
Undervoltage exceeded a certain level. You see a message in /var/log/syslog
EMF. Again linux logs this one in /var/log/syslog
Driver crash. This is actually tricky. If it officially crashes you get a message in syslog I guess. But fact is that also it is active it is often only sending data in one direction and keeps the connection open.
When you see in print log “Connection closed by os” this means the port we were talking with disappeared. Here you should have a look at the syslog to see what linux tells about the reason. The timestamp would be close to the message timestamp, just account for syslog having a different time zone as our logs which are using local time.
For undervoltage/EMF the port appears a few seconds later and printer reconnects. You can tell in server settings to continue print in this case. Do this only if connection happens without reset. We try to prevent reset on fast reconnect, but not all serial drivers support this. Native usb connections do not reset anyway.
The really annoying case is when the serial port keeps open, but no or or only in one direction communication is happening. It is unclear where exactly this is happening. As a result you normally see frequent timeouts and we have added a server option to restart usb driver on linux system (USB Reconnect on Timeout). Early means after one timeout, conservative after 2 timeouts for the case of recoverable timeouts as described above. It restarts the server communication and linux driver. If you need to unplug and unpower printer to recover in this case, it seems that the hang is on the printer side.
The last and quite unlike case is a dead lock in Repetier-Server. This happened in the past, but by now we have resolved all known cases and had no found cases for a long time. None the less I want to mention it for completeness and in case we have accidentially added one. When it happens it is quite typical that the gui does not load completely or seems to hand as well. Page changes are not executed or content is missing that was there before. In case this happned on a linux system we would be grateful if you send us a backlog of all threads as described in here: Debugging crashes/hangs on Linux
6.选择合适的线材。便宜的耐久性可能低点。还是选择经得起时间检验的。某ying就比较有韧性。同样的储存时间，好的线材更不容易变脆，能够更长时间保持韧性。更光滑均匀，无杂质的线材也利于进料。从而从源头上避免了打印中断等问题的发生。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
