AstroBox sees the USB Device as “FT232 USB-Serial (UART) IC” but just stays in a “connecting” state and never actually successfully connects. Any info on this one? Is the mightyboard running sailfish supported?
Thanks
DiamondDrake
AstroBox sees the USB Device as “FT232 USB-Serial (UART) IC” but just stays in a “connecting” state and never actually successfully connects. Any info on this one? Is the mightyboard running sailfish supported?
Thanks
DiamondDrake
Yes. You need to change your driver to x3g in the printer profile section of the settings app
I tried that, it changes the name of the device it sees to “TOM FTDI”, but it still never successfully connects. I can get it to work fine with my printrbot jr v2, but it refuses to connect regardless of profile to the wanhao duplicator. Maybe I should reinstall?
edit: Reinstalling did not fix the issue.
According to the manufacturer its a sailfish based mightyboard, but this is what I get back in the info log from repitier-host when connect to it.
13:50:39.788 : FIRMWARE_NAME:Repetier_0.91 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 REPETIER_PROTOCOL:2
any help on this would be great. I want a way to monitor my prints when Im not home.
Thanks,
That’s very odd, It seems as if the machine is running Repetier firmware… Did you modify the firmware? or are you still using the original? What other host programs do you use besides AstroPrint?
I’m using it vanilla, I have made no changes to the firmware or settings on the printer.
It connects fine with repitier-host and cura. Octoprint and Astrobox both seem not to be able to connect to it.
Wanhao seem to be making changes to the printer without giving the hardware revisions, for example the website and community say that the powersupply/controller box has no fan, but the that was shipped to me does have a fan.
Should astrobox be able to connect to repetier_0.91 firmware? if that is infact what is running?
It should, we have only tested it with 0.7 but I’m not aware of the protocol having being broken on higher releases.
The protocol has included a V2 command, but it’s not clear that it has completely changed. I’ve included the communication protocol readmes from the different versions of the firmware.
Is it clear why astrobox won’t connect? Is there something I could do to help get this supported?
Here is the protocol doc from repetier 0.71
repetier communication protocol
Intermediate description - a complete protocol definition will follow if have
the time to document it!
Why a new protocol?
The current reprap communication is just sending the gcode string to the reprap.
If communication is to slow, the printer waits. If communication fails very
strange things can happen, depending on the detection of the error. The current
checksum method is not very secure. I’ve seen errors with correct checksums.
The last disadvantage is the required parsing. It is for an arduino quite
time consuming.
What is better in this protocol?
- Data is send in binary form, no need for number conversion
- Binary format is shorter. We can transfer more commands with the same
bandwidth.- Improved checksum validation.
Comparison of sizes:
Command 1:
G1 E10810.1 F1000
Original size: 21 Bytes
Updated for errorcheck:
N6654 G1 E10810.1 F1000 *65
Errorcheck size: 29 Bytes
repetier-protocol: 15 Bytes
Command 2:
G1 X69.4864 Y48.1169 E10813.1 F2400
Original size: 36 Bytes
Updated for errorcheck:
N7665 G1 X69.4864 Y48.1169 E10813.1 F2400 *78
Errorcheck size: 56 Bytes
Repetier-protocol:23 Bytes
As you can see, this protocol reduces the average data transfered to
less then 50%.
Gcode Letter to Bit and Datatype:
N : Bit 0 : 16-Bit Integer
M : Bit 1 : 8-Bit unsigned byte
G : Bit 2 : 8-Bit unsigned byte
X : Bit 3 : 32-Bit Float
Y : Bit 4 : 32-Bit Float
Z : Bit 5 : 32-Bit Float
E : Bit 6 : 32-Bit Float
: Bit 7 : always set to distinguish binary from ASCII line.
F : Bit 8 : 32-Bit Float
T : Bit 9 : 8 Bit Integer
S : Bit 10 : 32 Bit Value
P : Bit 11 : 32 Bit Integer
Ext : Bit 13 : There are 2 more bytes following with Bits, only for future versions
Int :Bit 14 : Marks it as internal command,
Text : Bit 15 : 16 Byte ASCII String terminated with 0
A GCode line is transformed into a binary parameterization.
16 bit integer with given parameter set
if bit 0 set: 16 bit linenumber
if bit 1 set: 8 bit M value
if bit 2 set: 8 bit G value
if bit 3 set: 32 bit floatpoint X value
if bit 4 set: 32 bit floatpoint Y value
if bit 5 set: 32 bit floatpoint Z value
if bit 6 set: 32 bit floatpoint E value
if bit 7 set: 32 bit floatpoint F value
if bit 8 set: 8 bit T value
if bit 9 set: 8 bit string length + string data
16 Bit checksum
The checksum is computed by Fletcher-16 checksum algorithm.
See http://en.wikipedia.org/wiki/Fletcher’s_checksum
Advantage: We build checksum over checksum and both bytes are 0 if
correct.
The maximum size for a command without string is 2+2+3+5*4+2=29 Byte.
Here is the protocol doc from repetier 0.93
repetier communication protocol
Intermediate description - a complete protocol definition will follow if have
the time to document it!
Why a new protocol?
The current reprap communication is just sending the gcode string to the reprap.
If communication is to slow, the printer waits. If communication fails very
strange things can happen, depending on the detection of the error. The current
checksum method is not very secure. I’ve seen errors with correct checksums.
The last disadvantage is the required parsing. It is for an arduino quite
time consuming.
What is better in this protocol?
- Data is send in binary form, no need for number conversion
- Binary format is shorter. We can transfer more commands with the same
bandwidth.- Improved checksum validation.
Comparison of sizes:
Command 1:
G1 E10810.1 F1000
Original size: 21 Bytes
Updated for errorcheck:
N6654 G1 E10810.1 F1000 *65
Errorcheck size: 29 Bytes
repetier-protocol: 15 Bytes
Command 2:
G1 X69.4864 Y48.1169 E10813.1 F2400
Original size: 36 Bytes
Updated for errorcheck:
N7665 G1 X69.4864 Y48.1169 E10813.1 F2400 *78
Errorcheck size: 56 Bytes
Repetier-protocol:23 Bytes
As you can see, this protocol reduces the average data transfered to
less then 50%.
Gcode Letter to Bit and Datatype:
N : Bit 0 : 16-Bit Integer
M : Bit 1 : 8-Bit unsigned byte
G : Bit 2 : 8-Bit unsigned byte
X : Bit 3 : 32-Bit Float
Y : Bit 4 : 32-Bit Float
Z : Bit 5 : 32-Bit Float
E : Bit 6 : 32-Bit Float
: Bit 7 : always set to distinguish binary from ASCII line.
F : Bit 8 : 32-Bit Float
T : Bit 9 : 8 Bit Integer
S : Bit 10 : 32 Bit Integer
P : Bit 11 : 32 Bit Integer
V2 : Bit 12 : Version 2 command for additional commands/sizes
Ext : Bit 13 : There are 2 more bytes following with Bits, only for future versions
Int :Bit 14 : Marks it as internal command,
Text : Bit 15 : 16 Byte ASCII String terminated with 0
If version 2 is set, 2 more bytes with bitfields follow:
I : Bit 0 : 32-Bit float
J : Bit 1 : 32-Bit float
R : Bit 2 : 32-Bit float
D : Bit 3 : 32-Bit float (V3)
Bit 2-15 reserved
If Text bit is set in V2, the text length is send as byte 5 Text follows at
the end just before the checksum.
A GCode line is transformed into a binary parameterization.
16 bit integer with given parameter set
if bit 0 set: 16 bit linenumber
if bit 1 set: 8 bit M value
if bit 2 set: 8 bit G value
if bit 3 set: 32 bit floatpoint X value
if bit 4 set: 32 bit floatpoint Y value
if bit 5 set: 32 bit floatpoint Z value
if bit 6 set: 32 bit floatpoint E value
if bit 7 set: 32 bit floatpoint F value
if bit 8 set: 8 bit T value
if bit 9 set: 8 bit string length + string data
16 Bit checksum
Protocol version 2 extension:
The existence of M codes > 255 and additional parameter made it necessary to
introduce version 2. Version 2 code is indicated by setting V2 bit 12 in the bits field.
If the extra data is not needed, it is preferred to use V1 command to send/store data.
First main difference is G and M codes are 16 bit in V2.
Second difference are text codes send.
The checksum is computed by Fletcher-16 checksum algorithm (using modulus 255).
See http://en.wikipedia.org/wiki/Fletcher’s_checksum
Advantage: We build checksum over checksum and both bytes are 0 if
correct.
The maximum size for a command without string is 2+2+3+5*4+2=29 Byte.
I just built an Astrobox today for my Wanhao Duplicator i3 and am hitting the EXACT same issue…
Help please
Could you paste here a complete init dump with Repetier host? Or Cura?
Also you can enable serial logs on the astrobox advanced settings, reboot the box and try to connect using the GCODE driver. After that you can send the logs to us from the settings interface. This will allow us to see what’s going on
This is a dump from repetier-host
13:55:23.378 : OpenGL version:4.5.13399 Compatibility Profile Context 15.200.1062.1002
13:55:23.379 : OpenGL extensions:GL_AMDX_debug_output GL_AMD_blend_minmax_factor GL_AMD_conservative_depth GL_AMD_debug_output GL_AMD_depth_clamp_separate GL_AMD_draw_buffers_blend GL_AMD_framebuffer_sample_positions GL_AMD_gcn_shader GL_AMD_gpu_shader_int64 GL_AMD_interleaved_elements GL_AMD_multi_draw_indirect GL_AMD_name_gen_delete GL_AMD_performance_monitor GL_AMD_pinned_memory GL_AMD_query_buffer_object GL_AMD_sample_positions GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_atomic_counter_ops GL_AMD_shader_stencil_export GL_AMD_shader_stencil_value_export GL_AMD_shader_trinary_minmax GL_AMD_sparse_texture GL_AMD_stencil_operation_extended GL_AMD_texture_cube_map_array GL_AMD_texture_texture4 GL_AMD_transform_feedback3_lines_triangles GL_AMD_transform_feedback4 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_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_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_imaging 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_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_query_buffer_object GL_ARB_robust_buffer_access_behavior 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_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_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sparse_buffer GL_ARB_sparse_texture 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_snorm 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_transform_feedback_overflow_query 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_draw_buffers GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_buffer GL_EXT_copy_texture GL_EXT_depth_bounds_test GL_EXT_direct_state_access GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_histogram GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shader_image_load_store GL_EXT_shader_integer_mix GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texgen_reflection GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_bptc GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object 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_EXT_vertex_array GL_EXT_vertex_array_bgra GL_EXT_vertex_attrib_64bit GL_IBM_texture_mirrored_repeat GL_INTEL_fragment_shader_ordering GL_KHR_context_flush_control GL_KHR_debug GL_KHR_robust_buffer_access_behavior GL_KHR_robustness GL_KTX_buffer_region GL_NV_blend_square GL_NV_conditional_render GL_NV_copy_depth_to_color GL_NV_copy_image GL_NV_depth_buffer_float GL_NV_explicit_multisample GL_NV_float_buffer GL_NV_half_float GL_NV_primitive_restart GL_NV_texgen_reflection GL_NV_texture_barrier GL_OES_EGL_image 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
13:55:23.379 : OpenGL renderer:AMD Radeon HD 7700 Series
13:55:23.380 : Using fast VBOs for rendering is possible
13:57:52.035 : Printer reset detected - initalizing
13:57:52.044 : start
13:57:54.702 : N1 M110 *2
13:57:54.702 : N2 M115 *4
13:57:54.702 : N3 M111 S6 *68
13:57:54.708 : N4 T0 *30
13:57:54.708 : N5 M20 *52
13:57:54.709 : N6 M80 *61
13:57:54.709 : N7 M105 *0
13:57:56.851 : Info: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
13:57:56.851 : Free RAM:10732
13:57:56.921 : ok
13:57:56.921 : ok 2
13:57:56.922 : FIRMWARE_NAME:Repetier_0.91 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 REPETIER_PROTOCOL:2
13:57:56.922 : Printed filament:201.54m Printing time:1 days 0 hours 30 min
13:57:56.923 : ok 3
13:57:56.923 : N8 M220 S100 *73
13:57:56.923 : N9 M221 S100 *73
13:57:56.923 : N10 M111 S6 *118
13:57:56.923 : ok 4
13:57:56.923 : ok 5
13:57:56.923 : Begin file list
13:57:56.923 : N11 T0 *42
13:57:56.925 : Cura_14.07.exe 18817812
13:57:56.925 : CURA_WANHAO_EDITION_USER_M 1801928
13:57:56.925 : OK(2015).gcode 8192769
13:57:56.925 : WANHAO_i3_FIRST_RUN-EXPERI 1106749
13:57:56.925 : WANHAO_I3_UNBOXING_AND_HAR 1182426
13:57:56.925 : Woman_Body_Venus_Build.gco 7513203
13:57:56.925 : nobar_sixteen.gcode 7271601
13:57:56.925 : end_two.gcode 1070302
13:57:56.925 : bedend.gcode 994817
13:57:56.925 : Heart Dice.gcode 935140
13:57:56.925 : DrawerDiv_Sml4_01 (4way).g 135247
13:57:56.925 : End file list
13:57:57.117 : Error:Format error
13:57:57.117 : Resend:6
13:57:57.130 : ok
13:57:57.130 : Error:Wrong checksum
13:57:57.130 : Resend:6
13:57:57.130 : ok
13:57:57.130 : Error:Format error
13:57:57.130 : Resend:6
13:57:57.130 : Resend: N6 M80 *61
13:57:57.130 : Resend: N7 M105 *0
13:57:57.130 : Resend: N8 M220 S100 *73
13:57:57.130 : Resend: N9 M221 S100 *73
13:57:57.130 : Resend: N10 M111 S6 *118
13:57:57.130 : Resend: N11 T0 *42
13:57:57.133 : ok
13:57:57.133 : Error:Format error
13:57:57.133 : ok 6
13:57:57.133 : Unknown command:
13:57:57.156 : Error:Wrong checksum
13:57:57.156 : Resend:6
13:57:57.164 : ok
13:57:57.164 : ok 6
13:57:57.164 : ok 7
13:57:57.167 : T:23.76 /0 B:23.83 /0 B@:0 @:0
13:57:57.167 : ok 8
13:57:57.167 : SpeedMultiply:100
13:57:57.167 : ok 9
13:57:57.167 : FlowMultiply:100
13:57:57.167 : ok 10
13:57:57.167 : ok 11
13:57:57.751 : N12 M105 *52
13:57:57.764 : ok 12
13:57:57.764 : T:23.83 /0 B:23.76 /0 B@:0 @:0
13:57:58.755 : wait
13:57:59.762 : wait
13:58:00.769 : wait
13:58:00.816 : N13 M105 *53
13:58:00.817 : ok 13
13:58:00.833 : T:23.76 /0 B:23.76 /0 B@:0 @:0
13:58:01.840 : wait
13:58:02.847 : wait
13:58:03.854 : wait
13:58:03.874 : N14 M105 *50
13:58:03.886 : ok 14
13:58:03.886 : T:23.76 /0 B:23.76 /0 B@:0 @:0
13:58:04.893 : wait
13:58:05.948 : wait
13:58:06.940 : N15 M105 *51
13:58:06.955 : wait
13:58:06.955 : ok 15
13:58:06.956 : T:23.76 /0 B:23.76 /0 B@:0 @:0
13:58:07.945 : wait
13:58:08.953 : wait
13:58:10.001 : N16 M105 *48
13:58:10.040 : ok 16
13:58:10.040 : T:23.76 /0 B:23.83 /0 B@:0 @:0
13:58:11.047 : wait
13:58:12.054 : wait
13:58:13.045 : wait
13:58:13.061 : N17 M105 *49
13:58:13.077 : ok 17
13:58:13.077 : T:23.83 /0 B:23.76 /0 B@:0 @:0
13:58:14.148 : wait
13:58:15.139 : wait
13:58:16.128 : N18 M105 *62
13:58:16.130 : ok 18
13:58:16.146 : T:23.76 /0 B:23.83 /0 B@:0 @:0
13:58:17.137 : wait
13:58:18.240 : wait
13:58:19.192 : N19 M105 *63
13:58:19.199 : ok 19
13:58:19.199 : T:23.83 /0 B:23.76 /0 B@:0 @:0
13:58:20.207 : wait
13:58:21.198 : wait
13:58:22.205 : wait
13:58:22.249 : N20 M105 *53
13:58:22.349 : ok 20
13:58:22.349 : T:23.76 /0 B:23.76 /0 B@:0 @:0
13:58:23.340 : wait
13:58:24.347 : wait
13:58:25.315 : N21 M105 *52
13:58:25.322 : ok 21
13:58:25.322 : T:23.76 /0 B:23.76 /0 B@:0 @:0
13:58:26.328 : wait
13:58:27.335 : wait
13:58:28.342 : wait
13:58:28.373 : N22 M105 *55
13:58:28.374 : ok 22
13:58:28.390 : T:23.76 /0 B:23.76 /0 B@:0 @:0
13:58:29.381 : wait
13:58:30.388 : wait
13:58:31.436 : N23 M105 *54
13:58:31.443 : wait
13:58:31.443 : ok 23
13:58:31.443 : T:23.83 /0 B:23.76 /0 B@:0 @:0
I sent the astrobox logs from astrobox interface.
@DiamondDrake got the logs. There’s seem to be garbage over the line. Are you using the same baud rate as in repetier-host? Also the new release 0.8(1) has a GCODE console app, you could try to send some commands to the printer to see if it responds.
Yes I’m using what the display on the Wanhao says its configured for, 115200, which is the same as I have set in repetier- host.
Did you ever figure this out? I’m seeing the same issue.
Just got my AstroBox in today and am having the exact same issue. I even tried removing the AutoReset jumper and messing with different baud rates (suggestions on the Google Groups page), all to no avail. Has anyone been able to successfully connect a Wanhao i3 to an AstroBox? It would be a shame to have to return my box because they don’t support one of the highest trending / most popular printers on 3D Hubs…
Astrobox has some great features, but the software is essentially a branch of the octoprint with enormous changes. AstroPrint just won’t connect to the WanHao duplicator i3, but the lastes OctoPrint does. If anyone really needs the ease of host control of this type of solution, until the AstroBox team can get the WanHao Duplicator i3 Supported, It looks like OctoPrint is the way to go.
Thanks @DiamondDrake, we will look into the version of Octoprint that supports the i3 and implement the changes. Would you mind to let us know which version of Octoprint we should look into?
The octoprint webui shows “Version: 1.2.8 (master branch)” at the bottom of every page
Hi Guys,
My Duplicator i3 is working fine with my astrobox that I just built.
you can try removing the auto reset jumper on the i3 mbx and see if that work for you.
got this info below from one of the google wanhao user.
“open up the controller box and remove the jumper that says something about Auto Reset. (JP14?) Seen as the jumper on the right side, middle edge of the board here. That is the only thing that would really cause issues. As long as you have the baud rate the same and the same com port (and Repetier host is closed) it should work
http://3dprinterbrain.com/pmwiki.php/DupI3/PrinterBoardInfo?action=dispimg&im=i3board.p.png”
I haven’t tried removing the auto-reset jumper, but I installed a fresh copy of astrobox on my raspberry pi, used a powered usb hub, high quality cables, and nothing. Is there some significance to this jumper? The controller does reset, but octoprint handles that just fine.