I'm a big fan of adding a UPS into the mix. This way, I don't have to worry about most things on that end of the cord. And then of course, those ferrite cores are necessary.
I realized that i’m just a hobbyist user so a failed print here and there is okay I suppose. Some have failed due to filament winding.
A power failure is so rare that I wouldn’t really cover for that incident. What bothered me I suppose was that Octoprint tried to reconnect a few times and then stopped trying. I changed the settings there but I suppose it would still fail.
I wonder if I had paused the print job first and then power cycled the printer would have worked. I’m just wondering what is the best way to resuscitate a loss of connection.
I have implemented ferrites on both ends of USB and power cables. It seems to have sorted out the communication issues.
Maybe I could have restarted the print if I left out setting absolute position in the gcode. Alternatively a program to set relative position and convert the coordinates from absolute to relative would allow a restart.
I think I’ll try duet 3 on my second printer but for now this first printer is keeping my busy.
Definitely EMI. Every time the print was to finish just a hour or so after I got home. Hue lights etc etc switch on when I get home. One other time it was easy to put 2+2 together. I got home and played with a brushed rotary to polish parts. The print stopped.
Ferrites are a MUST. To the level imho they should be discussed right in the Octoprint installation procedure.
My experience mirrors yours in terms of RPI power. The canakit PSU puts out a good 3.5A at 5v. When I tried even a 65w USB C PD power supply I happened to have a HDMI screen connected to it so I saw the low voltage error. Some of those can supply a lot of watts but not necessarily at 5v. Or possibly the Pi USB C PD setup isn’t working yet.
I’m currently using the tape mod for the USB power issue to the printer board. That was annoying.
Now if EMI is main cause of all these issues wouldn’t the ultimate solution be to (beyond ferrites on cords) put the board inside a faraday cage and mount it?
This Ender 3 V2 is a great printer and actually has a 32 bit board and quiet steppers. However it seems over time I will end up replacing or modding every single thing except the aluminum frame.
good quality cable solves this issue of the EMI arriving from outside (lights, drills, vacuum cleaner ..) if the mainboard is of ok quality, if mainboard is not of ok quality nothing will help as those motor drivers produce a lot of EMI and you can't shield them other than properly routing the board ..
I see. So far the ferrites have been great.
I’m still too scared to run that router while printing. Maybe I’ll do it on the next print.
BTW someone is wanting to write an Octoprint plugin for Duet 3 using the virtual printer plugin. What do you think of that approach?
I suppose that depends upon whether or not you want wifi to that.
Not in the printer board but pi would be mounted outside with ferrites on the microusb connection to it.
Oh... okay. Yeah, the printer board (RAMPS/whatever) could be enclosed in a metallic box. I think I've written before about some techniques for doing this.
USB disconnects from EMI, or the bed current, are caused by the ground loop that you get if you use two power supplies with their own earth connection. If you run the RPI from the printer's PSU, perhaps via a buck converter, and ground it to the control board ground, not the PSU ground, the problem goes away.
I.e. the RPI ground is the same potential as the control board, regardless of the voltage drop in the PSU ground connection caused by the bed current, or any RFI induced voltage.
Most of my printers are powered by ATX PSUs and the RPI is on the 5V standby. One has an XBOX PSU that also has 5V standby. The have short 30cm USB leads without ferrites. They never disconnect.
Before I used Octoprint on a RPI I used a laptop and would get USB disconnects when I switched a light on and off unless I powered the laptop from the same mains socket as the printer. I.e. kept the ground loop area as small as possible.
1 Like
not always. e.g. my TT convert to smoothieware (teartime electronics with replacement cpu board with nxp lcp mcu that runs smoothieware) will in 50% cases when you "disable steppers" lose USB connection between rpi and smoothieware. Everything powered from same power brick (20V to TT machine, a DCDC 5A 5V step down for rpi), short shielded cable with 2 rfi chokes. The EMI affects the traces between the USB B connector and MCU 
. Luckily that's about the only thing that will kill USB on that printer, all the outside influence does not affect it.
I seen similar issue on MKS/SKR boards, using a proper USB cable and proper power supply you solve outside influences but the routing of the board is not very good (if you look, most 32bit boards are 4 layer boards) and the board itself is rather "dirty" and USB gets unstable...
There are some "recommendations" and some "requirements" for routing USB lines, on many boards out there those are not followed
SKR brags about it's 4 layer boards. What can you expect for $35 I guess?
FWIW, I've been printing error free nearly non stop since I put those ferrites on.
1 Like
I was inspired by your tool, and am in the process of adding this to ArcWelder:
Source File Extrusion/Retraction Counts
0.000mm to 0.002mm - 552
0.002mm to 0.005mm - 1034
0.005mm to 0.010mm - 2012
0.010mm to 0.050mm - 38165
0.050mm to 0.100mm - 150620
0.100mm to 0.500mm - 2492435
0.500mm to 1.000mm - 150413
1.000mm to 5.000mm - 328344
5.000mm to 10.000mm - 47335
10.000mm to 20.000mm - 16633
20.000mm to 50.000mm - 24332
50.000mm to 100.000mm - 42894
>= 100.000mm - 3691
Total: 6579869.207mm
Target File Extrusion/Retraction Counts
0.000mm to 0.002mm - 313
0.002mm to 0.005mm - 859
0.005mm to 0.010mm - 1871
0.010mm to 0.050mm - 21460
0.050mm to 0.100mm - 32044
0.100mm to 0.500mm - 206507
0.500mm to 1.000mm - 251788
1.000mm to 5.000mm - 533230
5.000mm to 10.000mm - 49773
10.000mm to 20.000mm - 17665
20.000mm to 50.000mm - 24710
50.000mm to 100.000mm - 42890
>= 100.000mm - 3700
Total: 6579869.207mm
For now it only outputs to the console, but I will be adding it to the plugin too. This version counts retraction and extrusion since ArcWelder can compress both. I'm interested in any feedback anyone may have.
1 Like
Looks good! When will we get to try it?
You can try it today! Use this link to install: https://github.com/FormerLurker/ArcWelderPlugin/archive/devel.zip
I added a few other goodies too, like compatibility with the cura and prusa slicer thumbnail plugins, and the ability to delete the source file. I also fixed a g92 bug when x/y offsets are applied. Case is also preserved for unaltered gcodes and comments. The console version has also been updated.
As usual, please post any issues here.
hi im a newbie, i cant tell you that conspiracy is not true, ive got a problem trying to slow my geeetech a10 down,after i loaded klipper and octopklipper. here is my config: i also can not get bl touch working, and when i mean newbie ive got no idea what im doing! lol. i just did a 45min print on marlin/ now 10 min on klipper ; # This file is the example config file for cartesian style printers.
One may copy and edit this file to configure a new cartesian
printer.
DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
FIRST. Incorrectly configured parameters may cause damage.
See docs/Config_Reference.md for a description of parameters.
[stepper_x]
step_pin: ar37
dir_pin: !ar39
enable_pin: !ar35
step_distance: .01245
endstop_pin: ^!ar24
position_endstop: 0
position_max: 235
homing_speed: 100.0
[stepper_y]
step_pin: ar31
dir_pin: !ar33
enable_pin: !ar29
step_distance: .01245
endstop_pin: ^!ar28
position_endstop: 0
position_max: 235
homing_speed: 100.0
[stepper_z]
step_pin: ar25
dir_pin: ar23
enable_pin: !ar27
step_distance: .0025
endstop_pin: ^!ar30
position_endstop: 0
#endstop_pin: probe:z_virtual_endstop
position_max: 250
position_min: -2
[extruder]
step_pin: ar46
dir_pin: !ar44
enable_pin: !ar12
step_distance: .002304147
nozzle_diameter: 0.400
filament_diameter: 1.750
max_extrude_only_distance: 60.0
#pressure_advance: 0.03
#pressure_advance_lookahead_time: 0.020
heater_pin: ar10
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog11
pullup_resistor: 4700
control: pid
pid_Kp: 29.667
pid_Ki: 2.355
pid_Kd: 93.451
#min_extrude_temp: 170
min_temp: 0
max_temp: 255
[extruder1]
step_pin: ar49
dir_pin: !ar47
enable_pin: !ar48
step_distance: .002304147
nozzle_diameter: 0.400
filament_diameter: 1.750
max_extrude_only_distance: 60.0
#pressure_advance: 0.03
#pressure_advance_lookahead_time: 0.020
shared_heater: extruder
[extruder2]
step_pin: ar43
dir_pin: !ar45
enable_pin: !ar41
step_distance: .002304147
nozzle_diameter: 0.400
filament_diameter: 1.750
max_extrude_only_distance: 60.0
#pressure_advance: 0.03
#pressure_advance_lookahead_time: 0.020
shared_heater: extruder
[heater_bed]
heater_pin: ar4
sensor_type: EPCOS 100K B57560G104F
sensor_pin: analog10
control: pid
pid_Kp: 73.964
pid_Ki: 2.315
pid_Kd: 590.784
min_temp: 0
max_temp: 120
[fan]
pin: ar9
[mcu]
#serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
serial: /dev/ttyUSB0
pin_map: arduino
[printer]
kinematics: cartesian
max_velocity: 200
max_accel: 6000
max_accel_to_decel: 1250
max_z_velocity: 1
max_z_accel: 1000
square_corner_velocity: 1.0
[display]
lcd_type: hd44780
The type of LCD chip in use. This may be "hd44780" (which is used
in "RepRapDiscount 2004 Smart Controller" type displays), "st7920"
(which is used in "RepRapDiscount 12864 Full Graphic Smart
Controller" type displays), "uc1701" (which is used in "MKS Mini
12864" type displays), or "ssd1306". This parameter must be
provided.
rs_pin: ar20
e_pin: ar17
d4_pin: ar16
d5_pin: ar21
d6_pin: ar5
d7_pin: ar36
The pins connected to an hd44780 type lcd. These parameters must
be provided when using an hd44780 display.
#cs_pin:
#sclk_pin:
#sid_pin:
The pins connected to an st7920 type lcd. These parameters must be
provided when using an st7920 display.
#cs_pin:
#a0_pin:
The pins connected to an uc1701 type lcd. These parameters must be
provided when using an uc1701 display.
#cs_pin:
#dc_pin:
The pins connected to an ssd1306 type lcd when in "4-wire" spi
mode. The default is to use i2c mode for ssd1306 displays.
#menu_root:
Entry point for menu, root menu container name. If this parameter
is not provided then default menu root is used. When provided
menu entry is 'deck' type then it'll be initiated immediately at startup.
Description of menu items is located in example-menu.cfg file.
#menu_timeout:
Timeout for menu. Being inactive this amount of seconds will trigger
menu exit or return to root menu when having autorun enabled.
The default is 0 seconds (disabled)
encoder_pins: ^ar40, ^ar42
The pins connected to encoder. 2 pins must be provided when
using encoder. This parameter must be provided when using menu.
click_pin: ^!ar19
The pin connected to 'enter' button or encoder 'click'. This parameter
must be provided when using menu.
#back_pin:
The pin connected to 'back' button. This parameter is optional, menu
can be used without it.
#up_pin:
The pin connected to 'up' button. This parameter must be provided
when using menu without encoder.
#down_pin:
The pin connected to 'down' button. This parameter must be provided
when using menu without encoder.
#kill_pin:
The pin connected to 'kill' button. This button will call
emergency stop.
#[bltouch]
#sensor_pin: !ar30
#control_pin: !ar11
#pin_move_time: 0.320
#pin_up_reports_not_triggered: False
#pin_up_touch_mode_reports_triggered: False
#x_offset: -37
#y_offset: 0
#z_offset: 1.45
#[bed_mesh]
#speed: 50
#horizontal_move_z: 6
#samples: 3
#sample_retract_dist: 2.5
#min_point: 54,15
#max_point: 233,220
#probe_count: 4,4
#algorithm: lagrange
#[gcode_macro G29]
#gcode:
G28
G1 Z10 F600
BED_MESH_CALIBRATE
M300 : Play tone, Beeper support, as commonly found on usual LCD displays
Usage: M300 [P] [S<Hz>] P is the tone duration, S the tone frequency.
#[output_pin BEEPER_pin]
#pin: ar18
#pwm: True
#value: 0
#shutdown_value: 0
#cycle_time: 0.001
#scale: 1000
#[gcode_macro M300]
#default_parameter_S=1000
#default_parameter_P=100
#gcode: SET_PIN PIN=BEEPER_pin VALUE={S}
G4 P{P}
SET_PIN PIN=BEEPER_pin VALUE=0
so if anyone can help i would be greatful; i also get on the printer and turn flow down to 30%. and i get a good print, this config will not home after completion.
Hey @anthony!
Please don't hijack threads with unrelated issues. If you want help with Klipper, I'm sure they have a community somewhere, or if you ask nicely enough around here there are people who use it. Just might find help quicker elsewhere. Please at least open a separate topic to discuss different problems. Thanks!
You even acknowledge at the start of your post you don't know about the USB problems, then proceed to post about an unrelated issue....
Sorry as I stated I'm very new to these computers and components.
Interesting topic. Being new to both 3D printing, and Octoprint, I wasn't aware there was the possibilities of these issues. I'm running an Ender 3 with the BTT SKR mini E3 v2 & TFT 35 v3. I've only had my Rasberry PI 3B+ & Octoprint running for a little less than 2 weeks, but I haven't seen any issues that I'm aware of. I was told to buy a 32g card to have plenty of room for plug-ins, files, and a camera. I've only installed 4 or 5 plug-ins, and about 10 gcode files because I do not plan to use this to replace the SD card (actually plan to switch over to a thumb drive), as the primary means of file transfer. Although, I admit that I've gotten a little spoiled sitting in the living room, sending the file to print, and then watching it via cam, lol.
Edit...Forgot to mention my PI is powered via it's own power supply. It is not hooked to the printer in any way except USB...and I have tape over the power pin in that.
This seems so wrong ... Also when reading from SD-CARD Marlin needs to read each line and parse it. The only thing it doesn't have to do is send an ACK back to OctoPrint that things have been received. I cannot understand that in 2022 with a 32-bit board (SKR E3 Mini v2.0), I'm now again facing the same problem and now am considering also converting this printer over to Klipper - even though I would prefer having a mix of Klipper and Marlin especially now that Marlin has input shaping ...
But like some others, I have been testing everything possible: increasing buffering, Arc Welder, MeatPack, ... but nothing helps. The bandwidth through serial is not the problem: if I use Marlin Binary File Transfer I get a great throughput, but uploading gcode to SDCARD using OctoPrint (basically streaming gcode to a file on sdcard) is SLOWWWWWW.
I would really have expected things to have evolved by now. It cannot be so difficult to implement a better more efficient and decently buffering transmission protocol over a fast serial-over-usb link, right?