Klipper: anet a8

[manotroll]

has support for anet a8
do you have support for automatic leveling?
Do you have temperature protection?

[KevinOConnor]

On Thu, Dec 28, 2017 at 08:43:39AM -0800, manotroll wrote:

has support for anet a8
do you have support for automatic leveling?
Do you have temperature protection?

I don't know what electronics are in the anet a8, so I can't be sure.

Automatic bed leveling still needs to be implemented (see the
docs/Todo.md file).

The micro-controller software will detect if a heater is outside the
min_temp/max_temp range and disable the heaters if so. Some more
advanced detetion of subtle heater failures (eg, the thermistor
falling off the heater) have not yet been implemented.

-Kevin

[rewolff]

FYI, while building two new 3D printers over the last few months, I've had about three times that the marlin firmware detected something odd going on and went into "safe mode". All false positives, but still it is nice to know that it works.

Now I must say that Marlin's handling of that situation is far from ideal: It shuts down completely, does not report temperatures anymore, and sometimes a whole reboot of the octopi machine is necessary to get things going again.

So... learning from that. When such an error condition is detected, keep responding to commands, but make sure that the heaters are in a "safe" mode for a while. Make sure that "manual intervention" happens before you enable them again. So maybe require that the temperature is set to zero before another temperature target can be set?

For context as to when something like this could happen:
I have an ATX powersupply that powers my machine. Apparently it has a feedback loop on the 5V and not on the 12V line: When the 3D printer loads the 12V line it drops to 11V and even to 10V when both bed and hotend are on. At 10V my hotend cannot reach the target temperature for my plastic: 225 degrees. A workaround is to load the 5V with one coil of a stepper motor I have.... So when Marlin detects: "I turned on the heater, but it took too long for the temperature to go up", I can reconnect the dummyload and get things to work better. Fault cleared, it would be nice to be able to allow the system to continue without having to reboot.

[manotroll]

I don't know what electronics are in the anet a8, so I can't be sure.

Automatic bed leveling still needs to be implemented (see the
docs/Todo.md file).

The micro-controller software will detect if a heater is outside the
min_temp/max_temp range and disable the heaters if so. Some more
advanced detetion of subtle heater failures (eg, the thermistor
falling off the heater) have not yet been implemented.

right
as soon as the customs finish reviewing the taxes I will test I already have a pi 3 + b ready
the videos I saw on YouTube show an incredible speed
I have completely discharged the marlin

FYI, while building two new 3D printers over the last few months, I've had about three times that the marlin firmware detected something odd going on and went into "safe mode". All false positives, but still it is nice to know that it works.

Now I must say that Marlin's handling of that situation is far from ideal: It shuts down completely, does not report temperatures anymore, and sometimes a whole reboot of the octopi machine is necessary to get things going again.

So... learning from that. When such an error condition is detected, keep responding to commands, but make sure that the heaters are in a "safe" mode for a while. Make sure that "manual intervention" happens before you enable them again. So maybe require that the temperature is set to zero before another temperature target can be set?

For context as to when something like this could happen:
I have an ATX powersupply that powers my machine. Apparently it has a feedback loop on the 5V and not on the 12V line: When the 3D printer loads the 12V line it drops to 11V and even to 10V when both bed and hotend are on. At 10V my hotend cannot reach the target temperature for my plastic: 225 degrees. A workaround is to load the 5V with one coil of a stepper motor I have.... So when Marlin detects: "I turned on the heater, but it took too long for the temperature to go up", I can reconnect the dummyload and get things to work better. Fault cleared, it would be nice to be able to allow the system to continue without having to reboot.

uses a better source with more amperage or a separate source
set to 13.8V

[rewolff]

Yeah, for a little more margin, i ordered a 15V, 40A powersupply. It arrived several minutes after writing the above comment.

[manotroll]

and solved it?

[rewolff]

Solved what?

I explained that I've seen from Marlin. This is intended to improve klipper: The same mistakes should be avoided.

The supply was advertised with "fan makes a little noise". Which could be interpreted as chinglish for "fan makes little noise: very quiet". However, this seems to be "fan is a little noisy" which is an euphemism for "fan is very loud (and always-on)".

[C4g2]

Just got my Anet A8 via Sain Smart! The mainboards IC is an Atmel branded ATMEGA1284p AU1720

Any other info you need to confirm compatibility? I'm VERY interested if this could run my machine.

[manotroll]

Solved what?

I explained that I've seen from Marlin. This is intended to improve klipper: The same mistakes should be avoided.

The supply was advertised with "fan makes a little noise". Which could be interpreted as chinglish for "fan makes little noise: very quiet". However, this seems to be "fan is a little noisy" which is an euphemism for "fan is very loud (and always-on)".

you did not have a drop problem for 10V and the 15V source arrived if you solved your reset problem

Just got my Anet A8 via Sain Smart! The mainboards IC is an Atmel branded ATMEGA1284p AU1720

Any other info you need to confirm compatibility? I'm VERY interested if this could run my machine.

C4g2
I think trying the same ramps settings might be a good way to start
perhaps looking at both electrical schematics of both is a good alternative

[rewolff]

I'm slowly starting to look into sources of klipper. It seems that the "total shutdown" that I dislike from Marlin is NOT present in klipper. I've found the code to maintain certain commands even when in "error shutdown". Good stuff.

[C4g2]

Apologies for newbing all over the place, but I thought this was a thread about if the Anet A8 could run the Klipper firmware. Id be more than willing to experiment with my hardware if no ones gotten it working with this model, but Im afraid ill need a bit more instruction. This is my first 3d printer and I've only done enough research to know that Klipper is the firmware I want to run/learn.

In that light:
What same ramp settings? a stock a8? a similar printer that does run klipper thats 'close enough'?
And again, which 'both' schematics?

I very much appreciate the response none the less!

ps. Your original post, 'has support for a8' was that a statement or a question? I think that kicked off my confusion.

[KevinOConnor]

On Sun, Dec 31, 2017 at 11:52:21PM +0000, C4g2 wrote:

Apologies for newbing all over the place, but I thought this was a thread about if the Anet A8 could run the Klipper firmware. Id be more than willing to experiment with my hardware if no ones gotten it working with this model, but Im afraid ill need a bit more instruction. This is my first 3d printer and I've only done enough research to know that Klipper is the firmware I want to run/learn.

Earlier, you indicated the electronics used an ATMEGA1284p. This is a
micro-controller that Klipper supports. You should be able to follow
the instructions in the docs/Installation.md document to compile and
flash your electronics.

Your next step is going to be putting together a config file for the
printer. This requires knowing which pins are attached to which
hardware features. (For example, the x axis step pin might be
"ar54".) This is pretty straight forward if you've got access to a
schematic for the board, or if you know of some other common firmware
that has support for the board that you can use as a reference.

In that light:
What same ramp settings? a stock a8? a similar printer that does run klipper thats 'close enough'?
And again, which 'both' schematics?

RAMPS is a common type of board (config/generic-ramps.cfg). I would
verify that your board uses the same pin mapping before trying to use
it though.

-Kevin

[rewolff]

Atmel branded ATMEGA1284p AU1720

That's an atmega-128-4-p-AU . 128 for 128 kb of memory. 4 for the 44-pin variant. p for the newer version that probably runs from 1.8V up to 5V and up to 20Mhz and AU for "TQFP" package. Yes, that should be compatible.
It was produced 2017, week 20. (may 14-may 20)

[kotfarepra]

Very much interested if this would have Anet A8 config/support as well .
its a replica printer ( prusa mk2 i believe ) and a low price ( ~ 180 USD ) so its popular for entry-level 3D printer https://www.banggood.com/Anet-A8-3D-Printer-DIY-Kit-1_75mm-0_4mm-Support-ABS-PLA-HIPS-p-1130694.html

Here the link on that same URL above for the docs https://1drv.ms/u/s!AuL7Lfc4swRWgR9OJnM0kLCzUM9m

Thank you

[rewolff]

I've seen even cheaper. (but maybe I didn't look carefully enough that something essential/expensive is missing). It is "I3" like.

Yes, it would be nice if someone would create a config file for these. However, this is not easily done "over the internet". You need to be close to the device to reverse-engineer the pinout.

Kevin, for initial config it would be nice to have some sort of debugging mode. In that mode it would be nice to be able to toggle and pulse arbitrary inputs and outputs to try and find those that control things. As I understand things now, the protocol between the server and the hardware already allows this. Not sure if the /tmp/printer protocol allows it. Then a separate application (web based?) can be used to show all inputs and allow control over all outputs. Click on output "D8" and suddenly the analog value on some analog pin (I don't know which by heart) starts to change and... the bed starts heating up. That sort of stuff. Of course, without feedback this is a bit dangerous, so proper warnings should be issued. ....

[C4g2]

Thanks for the detailed reply! Knowing that it Will work with the A8 chip is great to hear, very encouraging!

News when Im stuck or have it.

[manotroll]

in marlin has the ramps settings files and A8 can be a good place to base

[lenne0815]

Reowulf, theres a working A8 pinout for marlin, pins can just be copied from there.

[KevinOConnor]

On Mon, Jan 01, 2018 at 12:50:27PM +0000, Roger Wolff wrote:

Kevin, for initial config it would be nice to have some sort of debugging mode. In that mode it would be nice to be able to toggle and pulse arbitrary inputs and outputs to try and find those that control things. As I understand things now, the protocol between the server and the hardware already allows this. Not sure if the /tmp/printer protocol allows it. Then a separate application (web based?) can be used to show all inputs and allow control over all outputs. Click on output "D8" and suddenly the analog value on some analog pin (I don't know which by heart) starts to change and... the bed starts heating up. That sort of stuff. Of course, without feedback this is a bit dangerous, so proper warnings should be issued. ....

There is a console tool that can be used to issue low-level commands
(see docs/Debugging.md). I wouldn't recommend trying to find pins by
trial and error though.

As lenne0815 stated, there appears to be a Marlin config for an anet
board, so I'd start with that.

-Kevin

[kotfarepra]

Dont know how relevant this might be. Output of Octoprint when connected to printer

2018-01-02 18:06:16,896 - octoprint.util.comm - INFO - Printer reports firmware name "ANET_A8_20160525  http://www.anet3d.com/"
2018-01-02 18:06:16,898 - octoprint.util.comm - INFO - Detected Repetier firmware, enabling relevant features for issue free communication

[lenne0815]

I think to make it work you need to let klipper generate the firmware hex and flash these via atmel studio to the board, maybe someone can confirm this ?

[dragonnn]

First of - learn how to flash you board for example by flashing Marlin with is official supported. then try to learn how clipper works.

[tilsonm]

I think to make it work you need to let klipper generate the firmware hex and flash these via atmel studio to the board, maybe someone can confirm this ?

@lenne0815
I managed to compile the hex, pull it to my Windows desktop, and flash the board using atmel studio, but it soft-bricked my board. I was able to re-flash Marlin 1.1.8, though. Tried with avrdude, and same result.

Here is the output from avrdude.

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM3
         Using Programmer              : arduino
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega1284P
         Chip Erase delay              : 55000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    10   128    0 no       4096    8      0  9000  9000 0xff 0xff
           flash         65    10   256    0 yes    131072  256    512  4500  4500 0xff 0xff
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 2
         Firmware Version: 1.16
         Vtarget         : 0.0 V
         Varef           : 0.0 V
         Oscillator      : Off
         SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705 (probably m1284p)
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading input file "C:\Users\tilso\Desktop\klipper.elf.hex"
avrdude: writing flash (13338 bytes):

Writing | ################################################## | 100% 3.78s

avrdude: 13338 bytes of flash written
avrdude: verifying flash memory against C:\Users\tilso\Desktop\klipper.elf.hex:
avrdude: load data flash data from input file C:\Users\tilso\Desktop\klipper.elf.hex:
avrdude: input file C:\Users\tilso\Desktop\klipper.elf.hex contains 13338 bytes
avrdude: reading on-chip flash data:

Reading |                                                    | 0% 0.00savrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x49

avrdude: stk500_paged_load(): (a) protocol error, expect=0x14, resp=0x4e
Reading | #                                                  | 1% 0.05savrdude: stk500_cmd(): programmer is out of sync
avr_read(): error reading address 0x0000
    read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2

avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: stk500_cmd(): programmer is out of sync
avrdude: safemode: Sorry, reading back fuses was unreliable. I have given up and exited programming mode
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x2e

avrdude done.  Thank you.

[tilsonm]

@lenne0815 I've successfully flashed my Anet v1.0 with klipper. I have no idea what changed, but after flashing back to Marlin, I tried avrdude again and it flashed flawlessly. I _think_ that it worked the first time, but I mistakenly thought that it not being able to read back the flash data and then the white squares on the display that it was soft-bricked.

Testing now.

[C4g2]

@Tilsonm Thats great to hear, what config file did you use when building the hex? Best of luck on the test!

@Lenne0815 Hey, just recognized your name from Hackaday comments on this firmware, thanks for the videos you posted!

[tilsonm]

@C4g2 I ran menuconfig with Atmega AVR, atmega1284p, 16MHz, 115200 baud rate. When I flashed the board, I had to modify the flashing baudrate to 57600, and it has to be flashed manually with avrdude or with Atmel Studio, or at least that's the only way I could get it to flash.

[tilsonm]

Good news, all. I've got klipper working on the stock Anet v1 board and have verified the board configuration. I'm going to do some testing to see if I can work out some "optimal" settings, but it works.
I will try to write up a quick guide in the next few days so others can try to replicate it on their Anet v1 boards.

Quick question: any hopes of the LCD screen working? Has a generic framework been implemented yet?

[C4g2]

Across my research I think I've found mention of atleast 3 different layouts, yet still called Anet V1 boards, with mainly just the addition of trim pots for some or all of the stepper drivers. The specific board I have has a single trim pot for the Z stepper driver, if anyone has suggestions how to differentiate between them when talking, please help. For now I've been calling mine what is printed on the board, even tho it makes no sense, the "Anet V1-5." One through Five? One dash Five? whatever...

Point is I found a schematic
https://github.com/ralf-e/ANET-3D-Board-V1.0/blob/master/ANET3D_Board_Schematic.png
and have put together what i believe is a correct config file based on this schematic and a few online calculators for step per mm and whatnot. I'll be reporting back with how the first run goes as soon as I have it up.

@tilsonm I thought the 1284p was a 20mhz chip? Thats too bad to hear about the RaspPi flash not working tho.

[rewolff]

I thought the 1284p was a 20mhz chip? Thats too bad to hear about the RaspPi flash not working tho.

From the "world of arduino" there is some legacy that even though the chips can do 20MHz,. they are clocked at only 16Mhz.
For arduino the origin is that they started with an atmega8 chip, which is only 16Mhz. The upgrade to atmega168 allowed 20Mhz, but they decided to keep as much software compatibility by keeping the 16Mhz clock frequency.

For the atmega1286 and the likes, the chip might be able to do other frequencies, but to do USB they might need a specific crystal. Chips like STM32F072 allow a 4-24Mhz crystal (or none!) and then still they can do USB. The ATMEL chips require one of a few specific crystals: 8 or 16 to be able to do USB. If you decide 12MHz (which is what the FT232 requires to be able to do USB) then the atmel simply can't do USB. Simple as that.

I might be talking about a slighly older version of the atmel chips and that they've updated their USB module. in this chip allowing different crystals. But in any case, the question in the printer.cfg file is not: "what can your chip do?" but "what crystal is installed on your board" ?

@c4g2: Try selecting all the text, and hitting "code" (the angled brackets) above the edit window.

[C4g2]

Thank you for the clarification, that could have been a small headache to figure out! My last post just doesnt wanna work for me. I tried a few things, including the code button, before giving up and blaming it on my mac running an old version of chrome. But thank you for trying.

I'll try flashing with the rasppi just to make sure it wasnt a problem with tilsonm's specific hardware, if it still fails, avrdude then load this mess of a config file and give it a go!

[C4g2]

One last try at config file:

Anet_A8.cfg

# This file is for the Anet A8 boards, based on the Anet V1-5 board.
# All versions come populated with the Atmel ATMEGA1284P.
#
# Pin names may be preceded by an '!' to indicate that a reverse
# polarity should be used (eg, trigger on low instead of high). Input
# pins may be preceded by a '^' to indicate that a hardware pull-up
# resistor should be enabled for the pin.


# The stepper_x section is used to describe the stepper controlling
# the X axis in a cartesian robot.
[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: 0.15385
endstop_pin: ^PC2
#position_min: 0
position_endstop: 0
position_max: 220
homing_speed: 25
#homing_retract_dist: 5.0
#homing_positive_dir: False
#homing_stepper_phases: 0
#homing_endstop_accuracy: 0.200
#homing_endstop_phase: 0
#homing_endstop_align_zero: False

# The stepper_z section is used to describe the stepper controlling
# the Z axis in a cartesian robot.
[stepper_y]
step_pin: PC7
dir_pin: PC6
enable_pin: !PD6
step_distance: 0.15385
endstop_pin: ^PC3
#position_min: 0
position_endstop: 0
position_max: 220
homing_speed: 25
#homing_retract_dist: 5.0
#homing_positive_dir: False
#homing_stepper_phases: 0
#homing_endstop_accuracy: 0.200
#homing_endstop_phase: 0
#homing_endstop_align_zero: False

# The stepper_z section is used to describe the stepper controlling
# the Z axis in a cartesian robot.
[stepper_z]
step_pin: PB4
dir_pin: PB2
enable_pin: !PA5
step_distance: 0.004
endstop_pin: ^PC4
#position_min: 0
position_endstop: 0.25
position_max: 240
#homing_speed: 5.0
#homing_retract_dist: 5.0
#homing_positive_dir: False
#homing_stepper_phases: 0
#homing_endstop_accuracy: 0.200
#homing_endstop_phase: 0
#homing_endstop_align_zero: False

# The extruder section is used to describe both the stepper
# controlling the printer extruder and the heater parameters for the
# nozzle.
[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .002
# The remaining variables describe the extruder heater.
nozzle_diameter: 0.400
filament_diameter: 1.750
#max_extrude_cross_section: 0.64
#max_extrude_only_distance: 50.0
#max_extrude_only_velocity:
#max_extrude_only_accel:
#pressure_advance: 0.0
#pressure_advance_lookahead_time: 0.010
heater_pin: !PD5
#max_power: 1.0
sensor_type: NTC 100K beta 3950
sensor_pin: ^PA7
#pullup_resistor: 4700
#adc_voltage: 5.0
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
#pid_deriv_time: 2.0
#pid_integral_max: 1.0
#min_extrude_temp: 170
min_temp: 0
max_temp: 250

# The heater_bed section describes the heated bed.
[heater_bed]
heater_pin: !PD4
sensor_type: NTC 100K beta 3950
sensor_pin: ^PA6
control: watermark
max_delta: 2.0
min_temp: 0
max_temp: 100

#Front Mounted Part Cooling Fan
[fan]
pin: PB4
#max_power: 1.0
#hard_pwm: 0
#kick_start_time: 0.100

#Side Mounted Extruder Fan
[heater_fan extruder_fan]
pin: PD0
heater: extruder
#heater_temp: 50.0
#fan_speed: 1.0
#max_power: 1.0
#hard_pwm: 0
#kick_start_time: 0.100

# Micro-controller information.
[mcu]
serial: /dev/ttyACM0
baud: 115200
#pin_map: -Removed 'arduino'
#restart_method: arduino

# The printer section controls high level printer settings.
[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
#max_accel_to_decel: 1500
max_z_velocity: 5
max_z_accel: 100
#motor_off_time: 600
#junction_deviation: 0.02

[manotroll]

how many people testing and I still do not have my printer to help with the tests: \

how to solve the recording problem since the board runs at 20mhz had to change something in arduino IDE?

[lenne0815]

@tilsonm Theres neither need nor plans to implement the lcd displays afaik. Look at Printoid for a great gui instead.

[tilsonm]

@C4g2 I suggest doing an ls -l /dev/serial/by-id and getting the exact path to your printer. I turn my printer off but leave my Pi on, and when I restart the symlinked /dev/tty* path has changed. Oddly, mine is /dev/ttyUSB, not /dev/ttyACM

Also, the A8 has a head offset, so that will need to be taken care of in your cfg to get correct positioning.

See section from FAQ for setting the address more concretely
https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md

EDIT: Here is my printer.cfg for the Anet v1 and have confirmed everything working except my extruder is wonky and needs some work.

`# This file contains common pin mappings for Melzi v2.0 boards. To use
# this config, the firmware should be compiled for the AVR
# atmega1284p.

# Note that the "make flash" command does not work with Melzi
# boards. The boards are typically flashed with this command:
#  avrdude -p atmega1284p -c avrisp -P /dev/ttyUSB0 -U out/klipper.elf.hex
# or on some boards with:
#  avrdude -p atmega1284p -c arduino -P /dev/ttyUSB0 -U out/klipper.elf.hex

# See the example.cfg file for a description of available parameters.

[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC2
position_endstop: -20
position_max: 220
position_min: -20
homing_speed:  100

[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC3
position_endstop: -8
position_min: -8
position_max: 208
homing_speed: 100

[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: 0.0025
endstop_pin: ^!PC4
position_endstop: 0.5
position_max: 200
homing_speed: 20

[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .002
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: ATC Semitec 104GT-2 
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250

[heater_bed]
heater_pin: PD4
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 130

[fan]
pin: PB4

[mcu]
serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
baud: 57600 

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100

[C4g2]

Will do, mine is /ttyUSB0 as well, and thank you for posting your config file! Copied most your axis measurements & offsets (Z isn't ~240?), and also helped me notice a typo at my z step pin.

About the sensor type; I've not found much info on what comes stock in this MK8 extruder, I did find more than one place mentioning the NTC 3950, but that could of been meant as an upgrade from stock equipment.
If Im reading the schematic correctly, both of the sensors have 4.7k pull ups on them. But you confirmed End and Bed temp both reporting correctly?

Anyone else lurking this thread now or later, if you're looking to program your printers board and dont have a programmer, apparently you can [program your AVR via RaspPi's GPIO] (https://learn.adafruit.com/program-an-avr-or-arduino-using-raspberry-pi-gpio-pins/overview) have yet to try it, but it looks solid.

[C4g2]

I can also confirm that make flash does not work via rasppi. Tried both /dev/ttyUSB0 and the /by-id/** at 250k 115k and 57k, regardless, printer restarts then times out.

Is this a Bootloader issue, or something else, hopefully more easily fixed?

[rewolff]

"make flash" tries to program the MCU in the printer. Normally, a program like "AVRDUDE" talks to "programming hardware", which then programs the target CPU. The original thinking in "arduino" was that an arduino would be simple because you would not need a separate programmer. This was accomplished by burning a program into the arduino that would PRETEND to be a programmer, while infact programming the CPU itself. So ESP8266 and STM32 have a boot loader protocol that is different from what hardware progammer modules use, but here the bootloader simply emulates being a programmer.

On my system this worked: my MCU was tricked to boot into the bootloader, and my pi talked to the MCU in the "programmer-protocol" while the bootloader pretended to be programming a different MCU while in fact it was self-programming.

This works because my board is actually an arduino with a bootloader. But if you are selling hundreds of A8 printers, you get to chose: "Do we program the bootloader AND the default firmware, or do we just program the firmware?"

You can bet your ass that the choice was made to program just the firmware.

So when you issue "make flash" the makefile will try to program your MCU by trying to get it into the bootloader (not present, so it will immediately boot back into the default firmware) and then try to talk to it using the bootloader/programmer protocol. That'll time out.

[C4g2]

So first thank you for the answer! But that leads me to the question is it worth putting a 'standard' bootloader on there? Is there even such a thing? Cause if klippers firmware portion is gonna be undergoing many revisions, it sounds like it might be worth the time to get the rasppi flashing it properly. I know this is almost outside the scope of klipper, but im curious : )

[KevinOConnor]

On Thu, Jan 04, 2018 at 02:40:23AM -0800, C4g2 wrote:

So first thank you for the answer! But that leads me to the question is it worth putting a 'standard' bootloader on there? Is there even such a thing? Cause if klippers firmware portion is gonna be undergoing many revisions, it sounds like it might be worth the time to get the rasppi flashing it properly. I know this is almost outside the scope of klipper, but im curious : )

Yes. If your board did not come with a bootloader installed, then you
will need to use an external programmer to program the board. In that
process, you should write a bootloader to the board (there is no
downside to having a bootloader). Then it should be possible to
program future firmware updates without requiring an external
programmer.

-Kevin

[tilsonm]

@C4g2, lenne0815 reminded me today that I never shared my "secret formula" of avrdude commands to flash the hex file to my Anet board.

Here goes (written as if I was doing this again for the first time):

1. ssh into pi using PuTTY.
2. git clone https://github.com/KevinOConnor/klipper
3. ./klipper/scripts/install-octopi.sh
4. cd ~/klipper/
5. make menuconfig
6. Select options: MCU = Atmega AVR; Processor Model = atmega1284p; Processor speed = 16MHz; Baud Rate = 115200. Save using default file name suggested by utility. Exit utility.
7. make

8. sudo service klipper stop

   Here's where the REAL magic starts

9. _avrdude -v -p atmega1284p -c arduino -P /dev/ttyUSB# -b 57600 -D -U flash:w:/home/pi/klipper/out/klipper.elf.hex:i_

Explanation of arguments (to the best of my ability):

• avrdude calls avrdude
• -v means the program will display 'verbose' feedback as it programs the board
• -p means the "part type" (board model, which in this case is atmega1284p. It should match the make menuconfig.)
• -c means the programmer used. In this case it's arduino. All the research I can find says it should be avrispmkII, but I got the terminal command from ArduinoIDE on a successful flash of Marlin and even though I selected avrispmkII in ArduinoIDE, the command programmed with arduino.
• -P means the path to your device. In my case it's /dev/ttyUSB0 or /dev/ttyUSB1 (it changes each time I power up my printer). I've read that most cheap Chinese boards will show up as ttyUSB#..
• -b mean baud rate. Even though the printer communicates at 115200, it apparently gets programmed at 57600. Another parameter that I got from ArduinoIDE.
• -D means disable auto erase for flash memory - from what I've read, it will prevent the programmer from wiping the board if the flash fails for some reason.
• -U means a memory operation, in this case "flash memory, write file /home/pi/klipper/out/klipper.elf.hex in hex file format" [[http://www.nongnu.org/avrdude/user-manual/avrdude_4.html]]

Then you can run sudo service klipper start and follow the rest of Kevin's instructions in the Installation page.

[C4g2]

@Tilsonm Awesome guide, the flag explanations help with whats in man avrdude. I would advise anyone like me new to flashing chips that the Anet board is not particularly friendly with its programmer header; upside down and only the middle 6, good pics and other sage advice about this printer there too.

@Kevin Programming the board doesnt seem to be any problem, but might as well do it "hard" once and easy the rest. Optiboot was the first loader I found, hes looking for folk with the 1284p to test it, but I have no idea what to look for in terms of requirments or compatibility, essentially if Optiboot is even an option for this project.

Other news, I got the link I posted previously about AVR programming with RaspPi GPIO pins working, and just had my first success at a -v and getting a response from the chip with a 40-pin ribbon cable and 6 dupont male to female wires. Figured I'd wait to find something like Tilsonm's guide, thanks again, before I finally flashed anything. Now I think I'll try a bootloader option first and see if the rasppi can do this via usb.

Any suggestions?

[hg42]

you can try any boot loader, you can always flash another.

You eventually need to program the fuses, because different boot loaders often start at different addresses.
https://embedderslife.wordpress.com/2012/08/20/fuse-bits-arent-that-scary/
http://www.engbedded.com/fusecalc/

You can fake to flash a boot loader with the arduino ide. This will output command lines in the terminal that you can use as hint, which values you need. You have to choose the correct board and cpu. Eventually you need to install additional board managers for this.

These command lines are for the Arduino standard boot loader, so you may have to change the fuses for the start address. You can see which meaning the values have and also change options and calculate new values with the fusecalc in the second link.

With my TronXY board I had best success with the boot loaders in the arduino ide (see command lines to find them).

[rewolff]

-c means the programmer used. In this case it's arduino. All the research I can find says it should be avrispmkII, but I got the terminal command from ArduinoIDE on a successful flash of Marlin and even though I selected avrispmkII in ArduinoIDE, the command programmed with arduino.

I explained that the bootloader in the arduino pretends to be a programmer. Well, my memory for such details is bad, but that programmer is apparently 'avrispmkII'. When you specify "arduino" as the programmer, then avrdude will follow the AVRISPMKII protocol, but before starting the protocol avrdude will issue a few tricks that will cause an arduino to restart-into-bootloader. If your anet responds to this with a succesfull flash, you've proven me wrong in that there IS a bootloader in your board. :-)

In my case it's /dev/ttyUSB0 or /dev/ttyUSB1 (it changes each time I power up my printer).

The Linux kernel will chose the first free /dev/ttyUSBxx with xx being a number starting at 0. Now if you unplug the printer while it is connected as "ttyUSB0", it is likely that SOME program is still holding a filedescriptor to that device. So at that moment, the /dev/ttyUSB0 device file will be removed, but the index "0" is not yet marked as free. If you replug the device, it will get index 1: /dev/ttyUSB1. At that moment you notice something isn't working and you reconfigure klipper to use /dev/ttyUSB1 and it releases the filedescriptor and the index becomes free again.

[rewolff]

(there is no downside to having a bootloader).
There is very little downside to having a bootloader.... The small downside is that you lose a few bytes of your flash memory to the bootloader. With the firmware fitting easily in what's left, for klipper there is indeed no downside.... :-)

[tilsonm]

@rewolff that makes sense. What you said the first time didn't quite click, but thanks for repeating it. It makes more sense now.

How can I fix the ttyUSB#. I thought the suggestion I made to c4g2 about ls -l /dev/serial/by-id would take care of it, but it still seems confused when I power my printer off and back on and switches between USB0 and USB1. I've tried symlinking to /dev/anetv1 by using USB characteristics, but for some reason it's still not recognizing and automatically adding that symlink. Or maybe I'm going about this all wrong.

[KevinOConnor]

On Fri, Jan 05, 2018 at 12:41:14PM +0000, tilsonm wrote:

How can I fix the ttyUSB#. I thought the suggestion I made to c4g2 about ls -l /dev/serial/by-id would take care of it, but it still seems confused when I power my printer off and back on and switches between USB0 and USB1. I've tried symlinking to /dev/anetv1 by using USB characteristics, but for some reason it's still not recognizing and automatically adding that symlink. Or maybe I'm going about this all wrong.

Did you follow the directions at:
https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#wheres-my-serial-port

If so, can you provide the klippy.log file with the failure (along
with ls -l /dev/serial/by-id/ after the failure).

-Kevin

[KevinOConnor]

On Thu, Jan 04, 2018 at 04:22:05PM -0800, tilsonm wrote:

@C4g2, lenne0815 reminded me today that I never shared my "secret formula" of avrdude commands to flash the hex file to my Anet board.

Here goes (written as if I was doing this again for the first time):
[...]

Thanks. I've updated the Klipper build so that it will always use "-c
arduino" for the atmega1284p (commit 5a86391f). So, once one gets a
bootloader on the board, it should be possible to use the standard
"make flash" instructions to flash Klipper.

I don't have the board, but this link seems helpful for getting a
bootloader installed:
http://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/

-Kevin

[C4g2]

@kevin Thanks, good link too, I found the bootloader the talking about and judging by the file name, it looks to support the 1284p!

So the .hex is what I flash with avrdude using -U boot:w:~/optiboot_atmega1284p.hex:i? There is also a .lst file in the parent folder of the .hex that has the exact same name, do I need to do anything with that?

[C4g2]

I was thinking about Tilsonm's last post, I'm not at home right now so I cant try this myself, but I was thinking about symlinking the /dev/serial/by-id to /dev/anet? udev should have a rules file you could try hardcoding it in if you're brave!

[tilsonm]

@c4g2 I tried using udev and couldn't get it to work. Lol. You might have better luck.

[rewolff]

There is also a .lst file in the parent folder of the .hex that has the exact same name, do I need to do anything with that?

No. The .lst will list where things have ended up in memory. i.e. if you declare a variable "int steps_to_make", the LST will describe what address in memory is now used for storing that variable.

[C4g2]

So I've read up on fuses and locks enough to know I wont be immediately picking up on this and also wont feel comfortable just doing it, that said I havnt given up. I found enough detail to put together this monstrosity: sudo avrdude -p atmega1284p -C /avrdude_rpgpio.conf -c rpgpio -b 57600 -v -v -U lock:w:0x3F:m -U lfuse:w:0xFF:m -U hfuse:w:0xDC:m -U efuse:w:0xFC:m -U flash:w:/optiboot_atmega1284p.hex:i -U lock:w:0x2F:m

The RPGPIO nonsense at -C and -c is for the rasppi programmer I'm using. -b 57600 as per tilsonm. And -v -v for very verbose, cause I like when text scrolls past quickly. Avrdude will process the following -U in the order presented it.

-U lock:w:0x3F:m Unlocks the chip or area to write the bootloader.
-U lfuse:w:0xFF:m Sets the clock. This is frankly the most overwhelming list I've seen in quite a while. Fortunately I have yet to find a guide that says anything other than 0xFF, still, considering the danger when messing with this fuse I'd like conformation before setting.
-U hfuse:w:0xDC:m Seems to be reserving space for the bootloader? Optiboot is 1.37kB, ~702 words, needing 1024 words.
-U efuse:w:0xFC:m This one looks to exclusively deal with the brownout detection? +5v means this should be set to 4.3v yes?
-U flash:w to load the Optiboot code on the chip...
-U lock:w:0x2F:m Locks again. The 0x2F was suggested by an Optiboot author so anything flashed after can read the boot area.

This may be a gross oversimplification, but hopefully not enough to be wrong.

[mabl]

@KevinOConnor Thanks for this fix (5a86391). However the ANET board also needs its baud rate set to 57600, which is not currently menuconfig option, correct? It might make sense to make this configurable too. When doing so, I can successfully flash klipper on my ANET board.

[KevinOConnor]

On Sat, Jan 06, 2018 at 03:17:44PM +0000, Matthias Blaicher wrote:

@KevinOConnor Thanks for this fix (5a86391). However the ANET board also needs its baud rate set to 57600, which is not currently menuconfig option, correct? It might make sense to make this configurable too. When doing so, I can successfully flash klipper on my ANET board.

Okay, thanks. Can you run the following commands and copy-and-paste
the output for me?

cd ~/klipper/
avrdude -patmega1284p -carduino -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i
avrdude -patmega1284p -carduino -b57600 -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i

[KevinOConnor]

On Sat, Jan 06, 2018 at 03:17:44PM +0000, Matthias Blaicher wrote:

@KevinOConnor Thanks for this fix (5a86391). However the ANET board also needs its baud rate set to 57600, which is not currently menuconfig option, correct? It might make sense to make this configurable too. When doing so, I can successfully flash klipper on my ANET board.

Which bootloader did you flash to your ANET board? Looking at the
directions from:

http://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/

it recommends writing the bootloader from:

http://lauszus.github.io/Sanguino/

which has a boards.txt file with an unpload speed of 115200:

https://github.com/Lauszus/Sanguino/blob/master/avr/boards.txt

-Kevin

[lucashpandolfo]

¿Does the Anet A8 uses a Melzi too?

I have a Tronxy p802ma (also uses Melzi) and also had some problems flashing the firmware.

First, as someone else said, it appears the only baudrate supported is 57600. Surprisingly enough, just changing the baudrate worked for me and allowed me to flash the firmware. I later reflashed the original firmware to test something. When I wanted to flash Klipper again, I couldn't do it. I tried for hours. In the end I had to reflash a bootloader.

Using my raspbery and this guide I successfully flashed a bootloader to the Melzi (this one from a guide at reprap.org ) but for some reason the Melzi still refused to let me flash the firmware.

In the end I flashed this other bootloader and it worked flawlessly. But again, I could not get it working with another baudrate besides 57600.

[tilsonm]

@lucashpandolfo
The Anet came with Melzi boards at one point and I think the Anet v1.x boards that are supplied now are considered a Melzi clone, but I think if I remember right, the pinout is different. I think the Tronxy board is similar. Not sure why you're having issues flashing klipper again though.

[tilsonm]

@kevinoconnor
I think the Anet boards come with a bootloader loaded by default. I've never had to jump through any hoops to flash Marlin. You can choose to load Optiboot but it's not required to flash firmwares from ArduinoIDE.

Biggest benefit of Optiboot on the Anet, unless you soft-brick your board, is that it takes up less space allowing you to have a bigger firmware footprint. Marlin features eat up a lot of space. Klipper is so small in comparison that there is no obvious benefit (that I can think of) to flash Optiboot before flashing klipper. especially given the unforgiving nature of possibly messing up the locks and fuses.

[lucashpandolfo]

I WAS having issues due to the bootloader (or lack of) it seems.
And looking at the config supplied in this thread looks like the pinout is a bit different.

Anyway, for the ones in need of a bootloader, just keep in mind you can use your raspberry as an spi programmer.

Cheers.

[C4g2]

Alright so finally back at it today. Was thinking about it earlier and polled my chip for the fuses as is avrdude: safemode: Fuses OK (E:FD, H:DA, L:D6) My line of thought is leave the Low Fuse alone at 0xD6, as thats the one dependent the boards external hardware, and swap in my High 0xDE and Extended 0xFC for appropriate bootloader space and brownout detection. Can anyone confirm these, or my previous, fuse settings?

[mabl]

I believe the ANET boards to be mostly identical, as seen from the firmware. This is supported by not finding alternate firmware versions by ANET for different boards. On my "V1-5" board, I had good success flashing marlin (using their example settings) and the "standard" board file from here using the "Anet V1.0" (not the optiboot) settings:

https://github.com/SkyNet3D/anet-board/blob/master/hardware/anet/avr/boards.txt

It has been a long time since I did AVRs last, so I don't know if flashing via bootloader includes flashing the a new bootloader, probably not? Maybe I could switch to optiboot without ICSP. Anyways, the current state of things is fine. It's just that it wants a different baud rate by default. And this is also how it came from China.

@KevinOConnor:
Sure thing. I hade hacked the baud rate into the Makefile before, but it obviously also works on the command line:

pi@octopi:~/klipper $ avrdude -patmega1284p -carduino -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x01
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xff
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x92
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xd3
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x68
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x0a
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x26
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x48
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x3d

avrdude done.  Thank you.

pi@octopi:~/klipper $ avrdude -patmega1284p -carduino -b57600 -P/dev/ttyUSB0 -D -Uflash:w:out/klipper.elf.hex:i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (13340 bytes):

Writing | ################################################## | 100% 3.26s

avrdude: 13340 bytes of flash written
avrdude: verifying flash memory against out/klipper.elf.hex:
avrdude: load data flash data from input file out/klipper.elf.hex:
avrdude: input file out/klipper.elf.hex contains 13340 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.72s

avrdude: verifying ...
avrdude: 13340 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

[mabl]

@tilsonm: Thanks for the config file. You still have an error in the extruder speed. It ought to be step_distance: .01. Apart from this I got it working! Nice!

[KevinOConnor]

On Sun, Jan 07, 2018 at 08:13:38AM +0000, Matthias Blaicher wrote:

I believe the ANET boards to be mostly identical, as seen from the firmware. This is supported by not finding alternate firmware versions by ANET for different boards. On my "V1-5" board, I had good success flashing marlin (using their example settings) and the "standard" board file from here using the "Anet V1.0" (not the optiboot) settings:

https://github.com/SkyNet3D/anet-board/blob/master/hardware/anet/avr/boards.txt

It has been a long time since I did AVRs last, so I don't know if flashing via bootloader includes flashing the a new bootloader, probably not? Maybe I could switch to optiboot without ICSP. Anyways, the current state of things is fine. It's just that it wants a different baud rate by default. And this is also how it came from China.

To the best of my knowledge, the only way to flash the bootloader is
to use an external programmer. Just to be clear, you've never done
this - you've only ever written to the flash via the existing USB
port?

@KevinOConnor:
Sure thing. I hade hacked the baud rate into the Makefile before, but it obviously also works on the command line:

Thanks!

-Kevin

[mabl]

Just to be clear, you've never done this - you've only ever written to the flash via the existing USB port?

Indeed, I have only touched the ANET board via USB, hence leaving the bootloader intact.

I have been using Klipper on my A8 all day today and it is really nice. Thank you!

[KevinOConnor]

On Sun, Jan 07, 2018 at 08:14:50AM -0800, Matthias Blaicher wrote:

Just to be clear, you've never done this - you've only ever written to the flash via the existing USB port?

Indeed, I have only touched the ANET board via USB, hence leaving the bootloader intact.

I have been using Klipper on my A8 all day today and it is really nice. Thank you!

Thanks.

If you can post a confirmed working config, I'll add it to the repo.
(Your printer is from 2017, right?)

-Kevin

[mabl]

Yes, I have a 2017 printer using a V1-5 board (but if one believes Marlin it will work on all previous revisions too). The config file is based on the work of @tilsonm and @C4g2.

# This file contains common pin mappings for ANET v1 boards. To use
# this config, the firmware should be compiled for the AVR
# atmega1284p.

# See the example.cfg file for a description of available parameters.

[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6 
step_distance: .01
endstop_pin: ^!PC2
position_endstop: -33
position_max: 220
position_min: -33
homing_speed:  100

[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC3
position_endstop: -10
position_min: -10
position_max: 220
homing_speed: 100

[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: 0.0025
endstop_pin: ^!PC4
position_endstop: 0
position_max: 235   # When not using a glass bed, this could be 240 mm

[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .01
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: ATC Semitec 104GT-2 
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250

[heater_bed]
heater_pin: PD4
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 130

[fan]
pin: PB4

[mcu]
serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

[printer]
kinematics: cartesian
max_velocity: 400
max_accel: 2000
max_z_velocity: 8
max_z_accel: 100

[C4g2]

Can confirm @mabl is the solution to the problem!!

make flash FLASH_DEVICE=/dev/ttyUSB0
  Flashing out/klipper.elf.hex to /dev/ttyUSB0 via avrdude

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: reading input file "out/klipper.elf.hex"
avrdude: writing flash (13344 bytes):

Writing | ################################################## | 100% 3.33s

avrdude: 13344 bytes of flash written
avrdude: verifying flash memory against out/klipper.elf.hex:
avrdude: load data flash data from input file out/klipper.elf.hex:
avrdude: input file out/klipper.elf.hex contains 13344 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 2.85s

avrdude: verifying ...
avrdude: 13344 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

I deleted the Klipper directory and Klippy_Env to start from scratch and followed all the install instructions UP TO Make. At that point I did a Nano ~/klipper/src/avr/Makefile and changed this line at the very bottom:
$(Q)avrdude -p$(CONFIG_MCU) -c$(CONFIG_AVRDUDE_PROTOCOL) -P"$(FLASH_DEVICE)" -D -U"flash:w:$(OUT)klipper.elf.hex:i"

Add -b57600 to this command. After I saved (^O to save ^X to exit) I followed the rest of the instructions, including using the /dev/ttyUSB0 line instead of By-ID.

Happily continuing the install and configuration!

[kotfarepra]

@C4g2 can you upload a video too how it works/moves with klipper installed ?

[rewolff]

Do you have temperature protection?

I tried flashing klipper on my "megatronics" based BEAGLE delta printer. Something went wrong, and I decided to call it a day. A few hours later I found that the black goo falls of the hotend when you overheat the hotend. I now have an "as new" clean metal hotend, but alas not the plastic in reasonable shape.....

For temperature protection to work, the firmware needs to know the safe state of each of the pins. That's "OFF" for heaters, and "ON" for things like a FAN. So before you get to the state where that sort of information is correct, things can go wrong.

[C4g2]

@kotfarepra Lenne has posted a few videos in the comments of the Hackaday article about Klipper.

I'd love to upload one myself, but after finishing the installation instructions I'm getting:
Recv: // The klippy host software is attempting to connect. Please Recv: // retry in a few moments. Recv: !! Printer is not ready

at OctoPrints terminal. I've restarted the pi and the printer, waited quite a few moments but nothing seems to happen on its own. And nothing but ok's when I send either 'restart' or 'status'.

[C4g2]

I'm getting the "Recv: // The klippy host software is attempting to connect. Please" too, it just wont post with markdown.

[C4g2]

Okay nevermind that last messed up post, I checked the log and saw it was still trying to connect to the by-id, I switched it to ttyusb0 in config file and printer is responding now!!

[rewolff]

I spent 15 minutes looking for that video in the hackaday commends.... https://www.youtube.com/watch?v=clixTeZ3fJA

[C4g2]

My bad, I remembered it being embedded not a link, but still, more videos there and I'm sure theres even more if ya Youtube 'klipper firmware' or the such.

Thanks again to everyone who helped me get this running!

[kotfarepra]

@C4g2 i was thinking more about a video specific to anet a8 .
Interested if the default extruder/hotend keeps up OK with 100/250mm/s2

[lenne0815]

@kotfarepra That actually was an A8 at one point in the video ;) guess the A8 tops out around 60mms / 2500 accel for fine detailed prints. 100 should be okay, make sure to run tiny retracts like 0.5 for 250 reduce layer height, maybe even down to 0.08 if the default stepper drivers can keep up at all.

[tilsonm]

I've added a configuration file for the Anet A8 and sent a pull request. It's based on my work and that of @C4g2.

[KevinOConnor]

On Sun, Jan 07, 2018 at 02:54:42PM -0800, tilsonm wrote:

I've added a configuration file for the Anet A8 and sent a pull request. It's based on my work and that of @C4g2.

Thanks. I've added the example config file for the anet a8 (commit
f183871e).

-Kevin

[MrWu-at-msv]

I successfully flash Anet Board with:
make flash FLASH_DEVICE=/dev/ttyUSB0
On anet-a8-2017.cfg file you must add:
baud: 115200
under [mcu]
because anet board use CH340 chip and on this chip 250000 baud is not working or errors % make very the connection very unstable
https://www.olimex.com/Products/Breadboarding/BB-CH340T/resources/CH340DS1.PDF
(this also apply to many arduino mega2560 or arduino duo, cheap clones that also are equipped with CH340 chip)

on Make menuconfig set also baud to 115200.

however my board had already the Bootloader on it, re flashed using arduino IDE and https://github.com/SkyNet3D/anet-board.

[hg42]

the CH340 Problem seems to be vodoo, do you have definite knowledge or own experiences with it or did you only read about it?

My TronXY board has a CH340G and works well with 250000, though it usually prints 2-3 hours.

[MrWu-at-msv]

Any vodoo don't worry ;-) , is enough reading the datasheet of CH340 and AVR ATmega to have definite knowledge and is very well known problem.
If you use baud speed on Microcontroller in conjunction with Serial chip who don't support that baud speed you will face high frequency(clock speed) percentage errors, is not because apparently is 'working' that means is the right way to do it.
The main problem with CH340 and Avr ATmega micro-controllers running with quartz at 16Mhz (or 20Mhz) is that arduino 0% errors baud speed is at 250000 (or 0.5M or 1M)) due to the UART divisor and quartz speed.
Arduino board/Avr ATmega micro controller at 16Mhz at 230400 baud have 8.5% frequency(clock speed) errors, when you try use 250000 baud speed on CH340 the chip try to communicate at the closest speed that is 230400.
At 115200 baud frequency errors on arduino/ Avr atmega is 3.5% who is acceptable in somes cases.

Furthermore, theoretical calculations correspond to practical test (8 data bit+ parity), if you try transfert data and you do check consistencies of transferred data you will see is not 100% reliable.

This will not occurs with FTDI-USB chip (original Arduino Mega) because baud rates are compatible with the speed of 250000 baud, usually using a integer divisor of 12 and the internal chip quartz generator.

Moreover if you don't use OctoPi on original raspberry PI, who is already patched, you must be sure your OS can support 250000 baud. For example CH340 Driver In Windows can't go over 128000 (yes some people use Octoprint under windows, i know that sound crazy but someone do)

To conclude, i can say the CH340 is not 100% reliable at that speed (250000 Baud) in conjunction with a ATMega microcontroller running at 16Mhz.
99.9999% reliable that isn't enough for me. For some it may be, but not for me.
But at least at 115200 baud you have less chance to encounter a critical error.
If you want lowering the risks even more for sensible data transfer you can lower at 76800 baud for 0.2% error.

[hg42]

the only sentences in the data sheet of CH340 about baud rates tell us some examples and the last Chinese word of these means something like "etc.". There is no clear statement, that 250000 is not supported. Rates are from 50 to 2Mbaud. For IR it seems to be more restricted.

Instead it tells that the error will be <0.3% without stating for which baud rates exactly.
It cannot be a simple divider because then the error would be similar to the errors of the AVR cpus (and for a 12MHz xtal, which is worse for some baud rates), which is much higher.
So there is something like a PLL or some other means to reach such tolerances with a 12MHz xtal.

Up to now I have no numbers about the baud rate error of the CH340 at 250000 baud.
Someone with an oscilloscope or a frequency counter could measure it instead of speculating.

We at least know AVR has big baud rate errors and at 250000 this error is 0%.

For me the current knowledge is still kind of vodoo (meaning someone read something somewhere, but no concrete data), as an engineer, I am used to clear data sheets and I wouldn't call the CH340 sheet a real "data sheet", at least in respect to the baud rates.
I know there are many problems with serial communication over USB, but there are so many reasons, that we need real facts.

[KevinOConnor]

On Sat, Jan 13, 2018 at 11:40:03AM +0000, MrWu-at-msv wrote:

To conclude, i can say the CH340 is not 100% reliable at that speed (250000 Baud) in conjunction with a ATMega microcontroller running at 16Mhz.
99.9999% reliable that isn't enough for me. For some it may be, but not for me.

Klipper places a CRC on every message block, validates the CRC, and
does automatic retransmission. (See docs/Protocol.md for the
details.) Further, the stats include information on how many
retransmits occur and how many "invalid" messages are found.

I'd like to see some logs after a long print with this chip when the
mcu and host are set to 250000.

-Kevin

[hg42]

I don't understand why you say this:

when you try use 250000 baud speed on CH340 the chip try to communicate at the closest speed that is 230400

CH340 is designed to work with 12MHz xtal (as it is on my TronXY board) and this divided by 48 is exactly 250000. I cannot imagine that such a simple divider doesn't work.
For 115200 it would be about 104.17, so I guess they use 104 which gives you 115384.62 baud. The 3.5% for the AVR is -3.5% in reality giving you 111111 baud, so it's an even higher difference of 3.7%.

[hg42]

I'd like to see some logs after a long print with this chip when the mcu and host are set to 250000

you already looked into mine, where my TronXY board was included for Y and E...

The board has a CH340G on 12MHz and a 1284p processor and runs on 250000 all the time.
I admit I don't pay attention to the stats because it always worked for me with Printrun on Linux before using Klipper.

[hg42]

last line is this:
Stats 20811.8: gcodein=958987 print_time=16165.836 buffer_time=0.000 print_stall=0 ramps: mcu_awake=0.002 mcu_task_avg=0.000034 mcu_task_stddev=0.000039 bytes_write=1024420 bytes_read=192019 bytes_retransmit=0 bytes_invalid=0 send_seq=21675 receive_seq=21675 retransmit_seq=0 srtt=0.003 rttvar=0.001 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=15993291 tronxy: mcu_awake=0.006 mcu_task_avg=0.000072 mcu_task_stddev=0.000061 bytes_write=1467878 bytes_read=747252 bytes_retransmit=0 bytes_invalid=0 send_seq=29133 receive_seq=29133 retransmit_seq=0 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=16000143 adj=16006848

so, for tronxy:

bytes_write=1467878
bytes_read=747252
bytes_retransmit=0
bytes_invalid=0

and with

99.9999% reliable

there probably are very few retransmits
and because Klipper sents everything asynchronous ahead of time, it will not influence anything...
another great advantage of Klipper

[rewolff]

On Sat, Jan 13, 2018 at 12:36:39PM -0800, Harald wrote:
CH340 is designed to work with 12MHz xtal (as it is on my TronXY board)
and this divided by 48 is exactly 250000.

Many, many serial chips divide the system clock to 16 times the baud
rate. That is the input clock to the async serial module.

So, if your system clock is 6 MHz, you might think you'd be able to
make 250000 baud with 0% error, but in fact, you get to chose between
375000 (divisor 1) and 187500 (divisor 2).

This, like so many posts of mine in this thread to increase
understanding: The 12 MHz crystal divides by three exactly to create
the 4Mhz base-clock for serial communication at 250kbps.

Modern serial chips might have fractional divisors. So that would mean
that you can divide by say 2.5 instead of by either 2 or
three. usually only two bits. The physical implementation is that when
hitting the top value of the divisor, instead of resetting the whole
counter register, you reset all the bits except the lowest one. That
one gets loaded with the carry from adding the fractional part to a
temporary (2-bit) register. (i.e. it only requires rewiring of one bit
of the divisor circuit and adding four flipflops and two full-adder
sections. Really nothing compared to 512 bits required for an
USB-packet-buffer)

[hg42]

@rewolff ok, thanks for mentioning that, I didn't explicitely think of that.

However, you used 6Mhz for a reason, I guess :-)

For 12Mhz (which is used by the CH340) the divider would be 3 and 250000 would still have 0%

[hg42]

especially this:

when you try use 250000 baud speed on CH340 the chip try to communicate at the closest speed that is 230400

is very unlikely, because for 12MHz the 230400 is much more misaligned than 250000 in any case. 12MHz/230400 = 52.083333 ~= 13 x 2 x 2 via 12MHz/250000 = 48 ~= 3 x 2 x 2 x 2 x 2, so much more exactly fitting divider combinations for 250000 and always an additional error for 230400.
(sorry for all those edits)

[rewolff]

I agree with you that it is likely that the CH340 does something like all other chips to generate baud rates. But without looking into the datasheet you can guess that it divides the 12MHz down to the requested baud rate, but you can't be sure. With "baud rates up to 2Mbps" it might be dividing the 2 MHz or 4MHz down to 250kHz and get it exact. But you really can't tell.
The datasheet that I found: https://www.olimex.com/Products/Breadboarding/BB-CH340T/resources/CH340DS1.PDF
does not specify anything except that baud rates like 230400 (and many others) are generated with better than 0.3% error. And that is impossible with our theory that the serial-communications-module requires a 16x the baud rate clock.
So.... In short: there is some unknown trickery going on inside the CH340, and we cannot rule out that it has a high baudrate error at 250kpbs. On the other hand, someone posted a log file without any errors at 250kbps above. So that indicates that even if there might be a baud rate error, it might be small enough.

Yes, I used 6MHz for a reason. Most "serial communications" modules require a clock of 16x the baud rate: This enables them to detect the EDGE of the start bit, and then start sampling in the middle of the following bits. Moreover they sample at cycle 7-8-9 and do majority voting to filter noise.
Even with a 12MHz crystal, they will be using a PLL to make 48MHz to do USB. So the base frequency is likely to be 48MHz. Then using that directly as the clock for the UART module would lead to 3Mbps as being the highest baud rate.
Some UART modules will allow you to set "high speed" mode. That means not 16 but 8 is used as the main divider. Less accurate "sample in the middle of the bit". But it should still work.
A fractional 1.5 divider or that "high speed" mode would then allow 2mbps. Maybe the divider needs a minimum count.

On the other hand, maybe they have a PLL to generate 14.7456 as their base baud rate. This would allow perfect generation of the common baudrates that are a power of two times 300 bps or 900bps. Read the datasheet to find out....

[hg42]

does not specify anything except that baud rates like 230400 (and many others) are generated with better than 0.3% error

the sentence is very indefinite, so I would not even like to derive this as a fact from it, nor that these baud rates are better than those that are missing. The given rates are just some of the usual ones.

So.... In short: there is some unknown trickery going on inside the CH340, and we cannot rule out that it has a high baudrate error at 250kpbs

yes, that was my point above, most so called "facts" about this topic are speculations and therefore I can only accept them as such. There are too many other reasons for failing communications.
Measurements or robust statistical data could help given the lack of definitive data sheet information (if you trust the manufacturer at all).

The log was mine, btw. :-) and that's only one sample and not a really long print.

On the other hand, maybe they have a PLL to generate 14.7456 as their base baud rate.

from my state of knowledge (many years ago) PLLs use dividers on a variable oscillator and then "lock" by comparing the phase between the divided frequency and a reference. Which means it is kind of multiplier. A fraction would use the PLL to multiply with the numerator of the fraction and then divide through the denominator.
The fraction would be:
9216 ∕ 625 which would generate fairly high frequencies. But I agree it could use a fraction with more error but lower numbers.

I already said:

So there is something like a PLL or some other means to reach such tolerances with a 12MHz xtal

[rewolff]

With the chip generally not having to do anything above 48MHz, it is unlikely to be able to run the oscillator at much above that. So it's not doing 12*9212 and then dividing that by 625.

But from UARTs we know that fractional dividers are possible. Hints might be found in the Linux kernel driver.

I just looked and from the driver it looks as if they indeed have BOTH a PLL AND fractional dividers. In software with 5 bits behind the binary point, you could just pretend they have a 2^5 times higher base clock. That's what happens. The kernel starts by declaring the base baud to be: 1532620800, 1.5GHz. I suspect that they have 5 bits of fractional divider and a PLL to generate 47.8944 MHz from the 12Mhz crystal.

From reading the kernel driver (for the CH341) I would say that the CH34x comes pretty close.

OK. I went ahead and did some measurements. My FT232 has 0.2% offset at 230400. and 0.05 at 250kbps.
My aruduino with CH341 (or similar) gets 0.72% at 230.4kbps and 0.5% at 250kbps.

Note that this was just a quick measurement. I might have made an error somewhere. I measured the elapsed time across 1 million bit-times by sending a 100001 byte file to the port. I then measured the difference between the startbit of the first and last byte.

Still,.... Even if the errors are 10 times larger, they are still well within tolerance: Async serial will continue to work with a bit-time error of max 5% between the two communications partners. When one is perfect, the other could have a 4.9% offset. Anything below 1% is not going to introduce bit errors. Not ever.

Keep in mind that my measurements also have "the frequency offset of my logic analyser" that plays a role. Also the offsets of the crystals on the two boards will play a role. Hmm. My FTDI board does not have a crystal. It's freeloads off the crystal in my PC, doing some PLL stuff to recreate the 48MHz that USB runs from.

[hg42]

nice...thanks for measuring that.

today a (digital) PLL can indeed have fractional dividers.
This is done by switching the divisor between N and N+1 (or N and M) in a certain ratio:
see http://www.ti.com/lit/an/swra029/swra029.pdf

According to the acceptable errors:
The error for baud is to be multiplied by the bits you use, usually is 1 start + 8 data + 1 stop = 10. You must do this because synchronization only happens at the edge from stop to start bit.
So with 5% error on each bit (= baudrate) you get 50% shift of the sample point of the last bit, which is the absolute maximum if the sample point is placed in the middle of a bit (you usually want tolerance in both directions). 1% baudrate error would mean 10% for the last bit, which should be pretty safe (40% clearance instead of 50%).

Keep in mind that my measurements also have "the frequency offset of my logic analyser" that plays a role

were both errors in same or different directions?

[rewolff]

IIRC, all measurements gave a baud rate that was TOO FAST. I got 2304xx/230400 = 1.0007xxx Those numbers were always larger than one. So, maybe my logic analyser is terribly slow. (i.e. sampling at only 11.9MHz instead of the claimed 12MHz. It's a cheap chinese device after all...).

[hg42]

so if we assume the likely case that one of the frequencies is exact, it would mean the other is only 0.25% off. I would expect such rates from a fractional-N PLL implementation. And for integer N one of them would be much higher. So I think we can conclude that the simple baudrate error will probably not cause the mentioned transmission errors.

Of course there are other considerations, like manufacturing variations or faults.
May be older versions of CH340 had some problems or bad production batches are/were sold cheap.
btw what's the difference between CH340 and CH341?

[rewolff]

As far as I know, ch340 is the more recent version that's even cheaper than the '341. I expect that it's more or less the same chip, but possibly with some stuff left out. Like most of the handshake lines. That allows a low cost (SO14) package instead of the larger and finder pitch tsop28 of the 341.
I would not assume "one of them is correct". There are small variations, and all devices probably test at less than 1% error: The conclusion must still be that any transmission errors are not the result of bitrate errors.

I have two "arduino mega" clones. One of them is currently running my delta 3D printer, using klipper. One of them was advertized as: "Will NOT work in a 3D printer.... ".
As I forgot which one, Either I got lucky or my setup "octoprint/marlin" and now "octoprint/klipper" works better than expected.

[cyberjacob]

To confirm, is Klipper currently usable on an Anet A8? This issue seems to have drifted slightly off-topic.

[KevinOConnor]

On Thu, Jan 18, 2018 at 01:49:36PM +0000, Jacob Mansfield wrote:

To confirm, is Klipper currently usable on an Anet A8? This issue seems to have drifted slightly off-topic.

There have been several reports of success. See the
config/anet-a8-2017.cfg as a starting point.

-Kevin

[manotroll]

avrdude -v -p atmega1284p -c arduino -P /dev/ttyUSB# -b 57600 -D -U flash:w:/home/pi/klipper/out/klipper.elf.hex:i

now when I connect to the computer I get the unknown device message
Is there any way to reverse it?

[manotroll]

re-recorded and resolved
but I could not make it work

[manotroll]

pi@octopi:~/klipper $ avrdude -v -p atmega1284p -c arduino -P /dev/ttyUSB0 -b 57600 -D -U flash:w:/home/pi/klipper/out/klipper.elf.hex:i

avrdude: Version 6.1, compiled on Jul 7 2015 at 10:29:47
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "/etc/avrdude.conf"
     User configuration file is "/home/pi/.avrduderc"
     User configuration file does not exist or is not a regular file, skipping

     Using Port                    : /dev/ttyUSB0
     Using Programmer              : arduino
     Overriding Baud Rate          : 57600

avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xf8
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x21
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xee
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xb8
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x31
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xba
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xd6
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xc8
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xc8

avrdude done. Thank you.

[nickcaruso]

This thread was a ton of help. Here is what my config file looks like right now. Shes printing great, 200mm/s no problem. Biggest difference from above was the z step distance. Also the bootloader info was great, no bootloader on mine to start. You can easily flash a bootloader with the LCD cable on the Anet, an arduno, some spare wire, and google!

`

[stepper_x]
step_pin: PD7
dir_pin: PC5
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC2
position_endstop: -30
position_max: 220
position_min: -30
homing_speed: 50

[stepper_y]
step_pin: PC6
dir_pin: PC7
enable_pin: !PD6
step_distance: .01
endstop_pin: ^!PC3
position_endstop: -8
position_min: -8
position_max: 220
homing_speed: 50

[stepper_z]
step_pin: PB3
dir_pin: !PB2
enable_pin: !PA5
step_distance: 0.000624
endstop_pin: ^!PC4
position_endstop: 0.01
position_max: 240
homing_speed: 5

[extruder]
step_pin: PB1
dir_pin: PB0
enable_pin: !PD6
step_distance: .0105
nozzle_diameter: 0.400
filament_diameter: 1.750
heater_pin: PD5
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA7
control: pid
pid_Kp: 22.2
pid_Ki: 1.08
pid_Kd: 114
min_temp: 0
max_temp: 250
pressure_advance: 0.10
pressure_advance_lookahead_time: 0.010

[heater_bed]
heater_pin: PD4
sensor_type: ATC Semitec 104GT-2
sensor_pin: PA6
control: watermark
min_temp: 0
max_temp: 130

[fan]
pin: PB4

[mcu]
baud: 115200
serial: /dev/ttyUSB0

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 2000
max_z_velocity: 5
max_z_accel: 20
`

[nickcaruso]

Does anyone know how to make the bed heat before the extruder when the print button is pressed on octoprint?

[kotfarepra]

@nickcaruso do you have stock anet a8 ? Really interested in trying that config you pasted above

[rewolff]

Nick: bed/extruder heating is done in GCODE. in your slicer, there is usually something called start gcode that does things like home and warmup. I just looked. In slic3r that I use, apparently the things slic3r thinks it needs are not in the startup gcode section.

[nickcaruso]

@kotfarepra I believe so. When I purchased it I don't recall the name... it was an eBay china type purchase. But I have been using anet a8 support and everything seems to be the stock anet. I would use the config file. Home your Z, and make a 100mm move and measure to check for accuracy.

[manotroll]

fix bootloader
http://www.instructables.com/id/HOW-TO-FIX-ANET-BRICKED-BOARD-USING-AN-ARDUINO-UNO/
:)

[ghost]

MrWu-at-msv you saved my azz, i couldnt connect till i added the baud rate under mcu