Custom MCU-module for UP! Mini...

Post improvements made for UP, and share ideas.
arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Mon Jun 18, 2018 3:18 pm

SingularitySurfer wrote:
Sat Jun 09, 2018 1:37 pm
Just the USB one, no WiFI. I would pay 40$! :)
I sold mine for 150eur to some Hungarian guy that found me on facebook .. (he offered 150eur so I took it, if he asked I would of given him the board for free)

frederikv
Posts: 2
Joined: Sat Jun 30, 2018 7:06 pm

Re: Custom MCU-module for UP! Mini...

Post by frederikv » Sat Jun 30, 2018 7:09 pm

Hi Guys,

The hotend temperature of my Cetus in smoothieware is about about 15 a 20 degrees.

What should I tweak to get this right?

Thx.

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Mon Jul 09, 2018 2:06 am

frederikv wrote:
Sat Jun 30, 2018 7:09 pm
Hi Guys,

The hotend temperature of my Cetus in smoothieware is about about 15 a 20 degrees.

What should I tweak to get this right?

Thx.
what firmware are you using? original firmware can't properly read the pt100 from these machines, you should use my fork from here:
https://github.com/arhi/Smoothieware
you need to compile yourself I don't have the binary there, if you have a problem I can send you the binary

frederikv
Posts: 2
Joined: Sat Jun 30, 2018 7:06 pm

Re: Custom MCU-module for UP! Mini...

Post by frederikv » Tue Aug 07, 2018 5:05 pm

Hi Arhi,

I'm using the firmware provided by Tinyfab. The temperature of the hotend is about 20 degrees lower then it should be.

I already swaped the hotend with another one but same result.

I assume that this can be fixed by tweaking the following parameters:
temperature_control.hotend.slope 0.0257604875
temperature_control.hotend.yintercept -18.54

I think I need to do the same calculations as you done in this post:
https://www.tiertime.com/forum/viewtopi ... 100#p47305

Would it be possible to explain the process? Or share the excel file?

Many thx!

bjorn
Posts: 172
Joined: Fri Aug 10, 2018 6:00 pm

Re: Custom MCU-module for UP! Mini...

Post by bjorn » Wed Aug 15, 2018 12:42 pm

I've just gotten my Up Mini 2, and while the hardware works well, it was markedet as "silent" - clearly not the case when used to Trinamic drivers in stealth chop mode, and software is buggy, slow work flow and lacking in features.

But this CPU module, at £78 with wifi only solves the UpStudio dependency right? Or does it enable smarter fan control too, cannot believe i have to unplug or switch off printer to get it silent at idle?! Just wondering if not getting a smoothieboard clone and rewiring everything isn't a better solution as it kills the stepper noise as well. But damn dissapointing to shell out for a "professional" printer and start modding it straight away because software just isn't up to par with the community driven software.

Owen Sparks aka Marksman
Posts: 610
Joined: Tue Mar 15, 2016 9:56 am

Re: Custom MCU-module for UP! Mini...

Post by Owen Sparks aka Marksman » Wed Aug 15, 2018 3:23 pm

Yup, I agree. If I had more time I'd have made an open source FrankenUpbox by now.

Owen S.

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Wed Aug 15, 2018 8:16 pm

bjorn wrote:
Wed Aug 15, 2018 12:42 pm
I've just gotten my Up Mini 2, and while the hardware works well, it was markedet as "silent" - clearly not the case when used to Trinamic drivers in stealth chop mode, and software is buggy, slow work flow and lacking in features.
can't comment on the new software (the original was pretty good, ages in front of everything available at the time, but limited in terms of temperature control) while the new one I have zero experience with (studio I really dislike) but wrt "silent" UP2Plus is the quetest printer I have tried that uses alegro drivers, so it's 10% of the noise other printers make ... using TMC makes it even quieter but for that you need to throw the whole electronics to garbage and install new one.. not a big deal but.. the original electronics is actually not that bad :) so this cpu mod is kinda cheap way to run a good firmware on the machine... you don't get TMC drivers but you get everything else... and not for too much money... the smoothieboard or replicape or duet will set you back lot more ... and I'm sure you don't really want to go 8bit route with marlin
bjorn wrote:
Wed Aug 15, 2018 12:42 pm
But this CPU module, at £78 with wifi only solves the UpStudio dependency right?
this one I have (original custom mcu) gets you the ability to run smoothieware. have not checked the one with wifi module but I guess it's the same thing.
bjorn wrote:
Wed Aug 15, 2018 12:42 pm
Or does it enable smarter fan control too, cannot believe i have to unplug or switch off printer to get it silent at idle?!
the original fan on upplus2 is connected directly to 12V over enable pin so if motors are enabled it will run at 100% speed ALWAYS, no way to pwm it to change the speed... you also do not want to change the speed of this fan as if you slow it down your hotend will jam and will not work so running fan there at 100% is ok.

on top of extruder (as you can see in my other posts) there is a pwm-able connector where you can attach a second fan for your part cooling for e.g. and that one you can control from G-code like any other fan control, iirc my smoothieware config for that fan is posted here on forum, if not I can always post again.

other thing, you can control ENABLE from the smoothieware too (trough G-code) BUT there's a problem, since they didn't care much about EMI around USB lines when you disable motors your USB line will be broken so you will have to reconnect to printer to enable motors again. not a big deal but gets on my nerves from time to time ... so when you do M17 to enable stepper motors (and hotend fan) evertything is ok, you can then send g-code etc etc... but when you send M18 to disable steppers, it will "shut up" (disable steppers, turn of fan) it will disconnect your USB, so to start printing you need to reconnect USB and send M17 to enable steppers... this does not happen "every time", depends also on the quality of your usb cable, humidity etc etc.. but it's annoying for sure
bjorn wrote:
Wed Aug 15, 2018 12:42 pm
Just wondering if not getting a smoothieboard clone and rewiring everything isn't a better solution as it kills the stepper noise as well. But damn dissapointing to shell out for a "professional" printer and start modding it straight away because software just isn't up to par with the community driven software.
the problem with "smoothieboard clone" is that most of them don't work so don't waste money. MKS ones are POS don't waste a penny on them as they don't work... there's one named "aztech" or something similar, that one does work good but it's rather expensive (when you get the drivers it cost as much as original smoothieboard, so better get smoothieboard original imo)

now 76GBP for the cpu mod is bit overdoing it ... I'd rather get a whole original smoothieboard for 114eur then just this module for 85eur .. the extra 30eur gives you much better result... only smoothieboard does not go with TMC's they come with A5984 ... you can buy and attach tmc's on it if you need quieter printing.. but then maybe better to go with some of the duet boards if you want wifi and tmc drivers..

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Wed Aug 15, 2018 8:39 pm

frederikv wrote:
Tue Aug 07, 2018 5:05 pm
Hi Arhi,

I'm using the firmware provided by Tinyfab. The temperature of the hotend is about 20 degrees lower then it should be.

I already swaped the hotend with another one but same result.

I assume that this can be fixed by tweaking the following parameters:
temperature_control.hotend.slope 0.0257604875
temperature_control.hotend.yintercept -18.54
the firmware that used to be (dunno if he started shipping with my fork, would be cool if he did) provided by tinyfab was patched original fw to "kinda work" .. I implemented proper PT100 plugin for the smoothiware but it's rather "complex" for anyone not using these machines as on up's electronics there's not a simple amp for the pt100 but then also have 2 energizers and rather complex amp, so as almost everyone cared only about e3d pt100 amp and didn't care much about this complicated solution the pt100 plugin did not enter main smoothieware tree but the fork is pretty up to date with latest smoothieware (I catch up their edge every few weeks) so one can use my fork to run this up electronics with this custom mcu module. fork's addr for those who forgot: https://github.com/arhi/Smoothieware
frederikv wrote:
Tue Aug 07, 2018 5:05 pm
I think I need to do the same calculations as you done in this post:
https://www.tiertime.com/forum/viewtopi ... 100#p47305

Would it be possible to explain the process? Or share the excel file?
the xls file was shared on google docs I just need to find the url, I should have xls too lemme search...
as for the calc, it's rather simple, if you want to use linear "curve" and not the PT100 "real curve" you plot the bottom and top of the temp range you care about (180-300C in my case for e.g.) and you calculate the line formula (Y = A * X + B) where A is slope and B is up/down offset (where the line cuts the Y access). you calculate A = (y2 - y1) / (x2 - x1)

the xls that you see in that post only shows the line it's not very useful, there's one more useful, I'll find it and attach tonight

now using my fork with proper pt100 support, here's the config with PT100 (and coeff's), energizer pins for PT100 required for TT board, and top connector set as part cooling fan .. also on top of the extruder is the same pin's for auto bed leveling as on back of the board so config here utilizes that for mesh leveling too... here is the config

Code: Select all

# NOTE Lines must not exceed 132 characters

default_feed_rate                            4000             # Default rate ( mm/minute ) for G1/G2/G3 moves
default_seek_rate                            4000             # Default rate ( mm/minute ) for G0 moves
mm_per_arc_segment                           0.5              # Arcs are cut into segments ( lines ), this is the length for
                                                              # these segments.  Smaller values mean more resolution,
                                                              # higher values mean faster computation
#mm_per_line_segment                          5               # Lines can be cut into segments ( not usefull with cartesian
                                                              # coordinates robots ).

alpha_steps_per_mm                           644              # Steps per mm for alpha stepper
beta_steps_per_mm                            644              # Steps per mm for beta stepper
gamma_steps_per_mm                           644              # Steps per mm for gamma stepper

planner_queue_size                           32               # DO NOT CHANGE THIS UNLESS YOU KNOW EXACTLY WHAT YOU ARE DOING
acceleration                                 1000             # Acceleration in mm/second/second.
#z_acceleration                              500              # Acceleration for Z only moves in mm/s^2, 0 uses acceleration
                                                              # which is the default. DO NOT SET ON A DELTA
acceleration_ticks_per_second                1000             # Number of times per second the speed is updated
junction_deviation                           0.02             # Similar to the old "max_jerk", in millimeters,
                                                              # see https://github.com/grbl/grbl/blob/master/planner.c
                                                              # and https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.8
                                                              # Lower values mean being more careful, higher values means being
                                                              # faster and have more jerk
#z_junction_deviation                        0.0              # for Z only moves, -1 uses junction_deviation, zero disables
                                                              # junction_deviation on z moves DO NOT SET ON A DELTA

# Stepper module configuration
microseconds_per_step_pulse                  1                # Duration of step pulses to stepper drivers, in microseconds
base_stepping_frequency                      100000           # Base frequency for stepping

# Cartesian axis speed limits
x_axis_max_speed                             30000            # mm/min
y_axis_max_speed                             30000            # mm/min
z_axis_max_speed                             1200             # mm/min

alpha_step_pin                               2.1
alpha_dir_pin                                0.11!
alpha_en_pin                                 2.4!
alpha_current                                1.5
alpha_max_rate                               30000.0

beta_step_pin                                2.0
beta_dir_pin                                 0.5
beta_en_pin                                  2.4!
beta_current                                 1.5
beta_max_rate                                30000.0

gamma_step_pin                               2.2
gamma_dir_pin                                0.20
gamma_en_pin                                 2.4!
gamma_current                                1.5
gamma_max_rate                               1200.0           # mm/min

uart0.baud_rate                              115200           # Baud rate for the default hardware serial port
second_usb_serial_enable                     false  
leds_disable                                 true             # disable using leds after config loaded

# Kill button (used to be called pause) maybe assigned to a different pin, set to the onboard pin by default
kill_button_enable                           true             # set to true to enable a kill button
kill_button_pin                              2.12             # kill button pin. default is same as pause button 2.12
                                                              # (2.11 is another good choice)

currentcontrol_module_enable                 false            #

## Extruder module configuration
extruder.hotend.enable                       true

#extruder.hotend.steps_per_mm                   960            # up 640*1.53 Steps per mm for extruder stepper
extruder.hotend.steps_per_mm                   800
extruder.hotend.filament_diameter              1.75
extruder.hotend.default_feed_rate              600           
extruder.hotend.acceleration                   500            # Acceleration for the stepper motor mm/sec²
extruder.hotend.max_speed                       50            # mm/s
extruder.hotend.step_pin                        2.3           # Pin for extruder step signal
extruder.hotend.dir_pin                         0.22          # Pin for extruder dir signal
extruder.hotend.en_pin                          2.4!          # Pin for extruder enable signal

delta_current                                1.5    

laser_module_enable                          false 

## Temperature control configuration
temperature_control.hotend.enable              true
temperature_control.hotend.sensor              pt100
temperature_control.hotend.thermistor_pin      0.23
temperature_control.hotend.ampmod1_pin         1.20           # UP! printer uses this to "energize" the RTD
temperature_control.hotend.ampmod2_pin         1.21           # set as nc if you don't need to energize RTD
temperature_control.hotend.slope               0.0257604875
temperature_control.hotend.yintercept         -18.54
temperature_control.hotend.heater_pin          2.7
temperature_control.hotend.set_m_code          104
temperature_control.hotend.set_and_wait_m_code 109
temperature_control.hotend.designator          T
temperature_control.hotend.max_temp            500
temperature_control.hotend.min_temp            0
temperature_control.hotend.p_factor            23.0
temperature_control.hotend.i_factor            1.104
temperature_control.hotend.d_factor            120

temperature_control.bed.enable                 true
temperature_control.bed.sensor                 pt100
temperature_control.bed.slope                  0.0234092253
temperature_control.bed.yintercept            -2.85
temperature_control.bed.thermistor_pin         0.24
temperature_control.bed.heater_pin             2.5
temperature_control.bed.set_m_code             140
temperature_control.bed.set_and_wait_m_code    190
temperature_control.bed.designator             B
temperature_control.bed.bang_bang              true
temperature_control.bed.hysteresis             1.0
temperature_control.bed.min_temp               0
temperature_control.bed.max_temp               150
temperature_control.bed.runaway_heating_timeout 0
temperature_control.bed.runaway_cooling_timeout 0

## Endstops
endstops_enable                                true    
alpha_min_endstop                              1.26^
alpha_max_endstop                              1.26^
alpha_homing_direction                         home_to_min
alpha_min                                      0
alpha_max                                      140

beta_min_endstop                               1.24^
beta_max_endstop                               1.24^
beta_homing_direction                          home_to_min
beta_min                                       0
beta_max                                       145

gamma_min_endstop                              1.28^
gamma_max_endstop                              1.28^
gamma_homing_direction                         home_to_max
gamma_min                                      0
gamma_max                                      135.4

# optional order in which axis will home, default is they all home at the same time,
# if this is set it will force each axis to home one at a time in the specified order
homing_order                                   ZXY
move_to_origin_after_home                      false          # move XY to 0,0 after homing

alpha_fast_homing_rate_mm_s                    50             # feedrates in mm/second
beta_fast_homing_rate_mm_s                     50             # "
gamma_fast_homing_rate_mm_s                     4             # "
alpha_slow_homing_rate_mm_s                    25             # "
beta_slow_homing_rate_mm_s                     25             # "
gamma_slow_homing_rate_mm_s                     2             # "

alpha_homing_retract_mm                         5             # distance in mm
beta_homing_retract_mm                          5             # "
gamma_homing_retract_mm                         1             # "

#endstop_debounce_count                        100            # uncomment if you get noise on your endstops, default is 100

## Z-probe
## UP Z probe offset from tip is 19.4208mm
zprobe.enable                                  true           # set to true to enable a zprobe
zprobe.probe_pin                               1.30!          # pin probe is attached to if NC remove the !
zprobe.slow_feedrate                           5              # mm/sec probe feed rate
#zprobe.debounce_count                         100            # set if noisy
zprobe.fast_feedrate                           100            # move feedrate mm/sec
zprobe.probe_height                            10             # how much above bed to start probe
#gamma_min_endstop                             nc             # normally 1.28. Change to nc to prevent conflict,

# associated with zprobe the leveling strategy to use
leveling-strategy.three-point-leveling.enable  false                # a leveling strategy that probes three
                                                                   # points to define a plane and keeps the Z
                                                                   # parallel to that plane
#leveling-strategy.three-point-leveling.point1      15.0,5.0         # the first probe point (x,y) optional may be defined with M557
#leveling-strategy.three-point-leveling.point2      125,5.0       # the second probe point (x,y)
#leveling-strategy.three-point-leveling.point3      70.0,135.0       # the third probe point (x,y)
#leveling-strategy.three-point-leveling.home_first  true            # home the XY axis before probing
#leveling-strategy.three-point-leveling.tolerance   0.03            # the probe tolerance in mm, anything
                                                                   # less that this will be ignored, default is 0.03mm
##leveling-strategy.three-point-leveling.probe_offsets  0,0,0       # the probe offsets from nozzle, must be x,y,z,
                                                                   # default is no offset
##leveling-strategy.three-point-leveling.save_plane     false       # set to true to allow the bed plane to be saved
                                                                   # with M500 default is false

leveling-strategy.rectangular-grid.enable               true     # The strategy must be enabled in the config, as well as the zprobe module.
leveling-strategy.rectangular-grid.x_size               140      # size of bed in the X axis
leveling-strategy.rectangular-grid.y_size               140      # size of bed in the Y axis
leveling-strategy.rectangular-grid.size                 7        # The size of the grid, for example, 7 causes a 7x7 grid with 49 points.
#leveling-strategy.rectangular-grid.grid_x_size         7        # mora bude neparno
#leveling-strategy.rectangular-grid.grid_y_size         7
leveling-strategy.rectangular-grid.probe_offsets        0,0,0    # Optional probe offsets from the nozzle or tool head
leveling-strategy.rectangular-grid.save                 true     # If the saved grid is to be loaded on boot then this must be set to true
leveling-strategy.rectangular-grid.initial_height       10       # will move to Z10 before the first probe
leveling-strategy.rectangular-grid.human_readable       true
#leveling-strategy.rectangular-grid.only_by_two_corners  true     # This mode designed for PCB milling
mm_per_line_segment 1 # necessary for cartesians using rectangular-grid
leveling-strategy.rectangular-grid.height_limit         3
leveling-strategy.rectangular-grid.dampening_start      1


leave_heaters_on_suspend true

## Panel
panel.enable                                 false
network.enable                               false

switch.fan.enable                            true
switch.fan.input_on_command                  M106
switch.fan.input_off_command                 M107
switch.fan.output_pin                        1.18
switch.fan.output_type                       hwpwm
switch.fan.max_pwm                           100
switch.fan.ignore_on_halt                    true
switch.fan.startup_state                     true
switch.fan.startup_value                     0
switch.sw1.fail_safe_set_to                  100


arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Wed Aug 15, 2018 9:53 pm

sheet with e3d amp and both linear and curve matching for pt100

this have hardcoded values in B1-C15 fields and these are values for E3DAMP, now D2-D15 is what the whole sheet uses are "reference values" for temperatures in C2-C15... this is derived from B2-B15 but you can hardcode these from what you read directly from the ADC when you read the data ... I can't find original sheet where I made the C vs ADC table, I'll try to find it (that's on the sheet you have snapshot on that old post, you can retype it if I can't find it) but basically you just change the D values (note the *4 'cause smoothieware takes 4 measurements and adds them together)

hope this helps
Attachments
PT100 E3D.zip
here's the calculation with E3D Amp (not for UP)
(26.92 KiB) Downloaded 93 times

Owen Sparks aka Marksman
Posts: 610
Joined: Tue Mar 15, 2016 9:56 am

Re: Custom MCU-module for UP! Mini...

Post by Owen Sparks aka Marksman » Thu Aug 16, 2018 7:40 am

Good stuff Arhi, thanks for sharing it :+1:

Owen S.

bjorn
Posts: 172
Joined: Fri Aug 10, 2018 6:00 pm

Re: Custom MCU-module for UP! Mini...

Post by bjorn » Thu Aug 16, 2018 10:20 pm

arhi wrote:
Wed Aug 15, 2018 8:16 pm
Thanks for your input! I guess I will use the Up Mini2 as is to finish modding the reprap delta and decide which one gets the aztech board I already have sitting on the desk. But I would guess it goes in the delta and then put the 8-bit board in the Up Mini2, at the speeds its operating 8-bit and repeteir/marlin is sufficient. Both pritners will have trinamic drivers, one with SPI one without, and their own Orange PI with Octoprint, so getting case fan under control and proper pre-heat on top of silent operation seems like a win regardsless of 8/32 bit CPU.

Owen Sparks aka Marksman
Posts: 610
Joined: Tue Mar 15, 2016 9:56 am

Re: Custom MCU-module for UP! Mini...

Post by Owen Sparks aka Marksman » Mon Aug 20, 2018 6:48 am

bjorn wrote:
Thu Aug 16, 2018 10:20 pm
arhi wrote:
Wed Aug 15, 2018 8:16 pm
... Both pritners will have trinamic drivers, ...getting case fan under control and proper pre-heat on top of silent operation seems like a win .
And working GCODE, and first layer control (for raft removal), and multiple infill settings in the same part...

How is that an individual private user can do this but the manufacturer can't?

Owen S.

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Wed Aug 22, 2018 1:50 am

I really don't want to bash manufacturer because
1. this board is pretty good I have to admit, not something I'm used to seeing from PRC manufacturers, properly designed, proper layout, good quality parts and decent soldering work!!! now they use alegro, alegro is great for this work, trinamic is quiet but they have their own issues (lower torque, number of "fancy" features they have don't really work repeatably etc etc... ) and they didn't exist in the time these boards were made so ..

2. the sound of the motors is lower then *any* of the printers I tried (before TMC) and I tried hundreds!!! so they properly paired motors with properly configured drivers, not something you usually get from much more expensive machines

3. most (almost *all*) professional systems (talking 100+ kEUR machines) use the same setup as TT's electronics use, the calculation is done on the "host" and the "stepping" file is uploaded to the high speed mcu capable of doing crazy fast and precise stepping. Apart from rudimentary "scripting" (setup temp, keep set temp, putput pwm..) the mcu on board does nothing but playing the stepping pattern from the file. This way you get super uber turbo mega giga precise stepping that is impossible to get (similar you get with e.g. replicape where you have 2 pru's doing stepping, or smoothieboard v2 with fpga dedicated for stepping, or mesa cards or...) if your mcu is the one doing the calculations. So complaining that their cpu works like professional machines and not like our hobby ones is badly placed complaint!!!! what I did complain about (and why I moved from their "cpu") is that protocol to talk with their CPU is not open but proprietary and format of the prepared file is not open but is proprietary so in order to prepare the file and send it to their CPU to play you have to guess, check out crystal ball, sniff, sniff, sniff, try, error, try, error etc etc... and after a lot of time and filament you get to something like: https://github.com/UP3D-gcode/UP3D ... if https://github.com/UP3D-gcode/UP3D existed back in the day I'd probably not switch my CPU board.. no clue where they are at the moment and how good they hacked the protocol and file format but.. one should try it out :D ... IMO TT SHOULD NOT change their firmware and move to some DIY firmware like smoothieware or redeem or, god forbid, marlin <cough, cough>crap</cough, cough> .. they should OPEN the protocol and file format so that ppl can use the good system properly.

4. back in the day when UP2 and UPPlus2 printers were pushed out they were performing 1000000x better and only 'cause of the TT software!!! It was not Studio back then but it was called iirc UP. It lacked support for thin wall (came later, no other slicer had that support neither) it didn't allow for temp control, but the print quality was 100000000000x better then anything on the market (including 4x more expensive machines), it "just worked", and the support system was so good everyone else was hitting their heads trying to figure out how the hell it works so good and trying to reproduce it ... now "today" things are kinda different, studio is kinda crap, for me it looked like they lost the source of the original sw and someone new rewrote it from scratch... dunno if it got better over time (moved from it long time ago) but the open source solutions catched up... Cura, Slic3r, CraftWare are in front of it and opening the system is the only proper way to move forward.

all in all, these are nice little machines that do the job good. they looked like they are based on the big systems, the only issue they have is sw is bit lacking and the fastest way to solve that is by opening the sw.. everything else would be solved if that's done properly :)

btw attached is the latest firmware build (my fork) with pt100 support
Attachments
FIRMWARE.zip
latest smoothieware with PT100 support
(210.22 KiB) Downloaded 100 times

bjorn
Posts: 172
Joined: Fri Aug 10, 2018 6:00 pm

Re: Custom MCU-module for UP! Mini...

Post by bjorn » Fri Aug 24, 2018 11:28 pm

arhi wrote:
Wed Aug 22, 2018 1:50 am
I really don't want to bash manufacturer because
You're right about all of the above, but if they could couple the progress made by the open source community (with respect to electronics and software) with the premium hardware and quality control they would be so much better. The custom MCU solves some issues, but If I'm going custom, might as well go all the way.

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Wed Aug 29, 2018 3:37 am

bjorn wrote:
Fri Aug 24, 2018 11:28 pm
You're right about all of the above, but if they could couple the progress made by the open source community (with respect to electronics and software) with the premium hardware and quality control they would be so much better.
uh, don't get me there really :( ... 90% of the open source hw wrt 3d printing is scary bad!! I'm not talking about bad PRC implementation (like what MKS does) but I'm talking about original shitty design that's created without any real knowledge and experience behind it.. having EDA tools available for "everyone" was, while good in one case, scary bad on the other, as ppl without basic knowledge of power distribution, security & safety and high power applications are producing "professionally looking" (looking being keyword here) boards that ppl use in their machines, PRC "engineers" copy (even badly) and put into "commercial" machines etc etc... that they produce shitty results I could not care less but they are serious health and safety hazards.. smoke poisoning and fire starting from these machines is not something that's rare!!!!!

so unfortunately, "open source electronics" in 3d printing is, to say mildly - TERRIBLE!! and to be honest - dangerous!!

there's no real review of the open source hardware here and real engineers can't give "honest review" as the boards are mostly "crap from start to end" there's no "Review" to be made apart from - this is an utter crap, have to be redone from scratch :( ... and the "community" always dislikes those type of reviews and bash the ppl making them hence they are, for years now, not made...

firmware on the other hand - commercial printers as a rule of thumb turn off all safety firmware features as they printers are heaps of crap so they have to do it as their broken wires and crappy connectors can't work with safeties on, the point that they also catch fire is not important as long as the machines are cheep :(

apart from shitty organization and shitty results with complete lack of proper approach to problem solving in most projects, firmware's are safe and worse issues with them are shitty quality prints..... of course, and safety issues when you manually turn them off

from the available devices replicape and smoothieboard (original's only, the clones are faaaaaaaaaaaaar from it) are among very very very few boards that are acceptable. they are not ideal but they are ok and they are safe .. and as for the firmware... I'll prevent myself from saying what I really think :( ...

so having the "commercial" solution is not bad at all, as long as protocols are not proprietary!!! and that's the only thing I really hate about TT printers and reason I stopped purchasing TT printers myself and why I stopped suggesting ppl get TT printers (and they sold at least 200 printers to ppl I directly convinced to go with TT and not another vendor so while not much it's certainly not a little amount of printers) ... if they went the "open way" and opened the protocol I'd happily get another CPU directly from TT and get back on the wagon :) but..
bjorn wrote:
Fri Aug 24, 2018 11:28 pm
The custom MCU solves some issues, but If I'm going custom, might as well go all the way.
IMO custom MCU is solving just few things so it's not really a "solution" for anything ... just a simple workaround.. and the cost is such that you can replace the whole chabang (or at least it was) .. so it's not something I'd be 100% supportive about but if you do have it then I am willing to help one get most out of it :) ... I was personally hoping the original sw will come back and that I'd move back to original fw but that never happened and...

if one do not have custom mcu already, I believe investing time in
https://github.com/UP3D-gcode/UP3D
would be time much better spent :)

yoyo42_cetus3d
Posts: 3
Joined: Sun Sep 02, 2018 9:33 pm

Re: Custom MCU-module for UP! Mini...

Post by yoyo42_cetus3d » Sun Sep 02, 2018 9:43 pm

Hi Arhi

I have a Cetus MkII extended with the tinyfab CPU. I'm trying to sort it out to use Klipper rather than smoothieware and I'm at the stage of hooking up the various control pins. My current issue is trying to read the PT100 hotend thermistor via the Tiertime electronics. I see from your SmoothieWare module for this that you energise both the pins, read the ADC pin, then turn them off again. I'm going to add something similar to the Klipper code.

Your code for reference:
int PT100::new_thermistor_reading()
{
int t;
if(this->use_ampmod1) this->ampmod1_pin.set(true);
if(this->use_ampmod2) this->ampmod2_pin.set(true);
// filtering now done in ADC
t = THEKERNEL->adc->read(&thermistor_pin);
if(this->use_ampmod1) this->ampmod1_pin.set(false);
if(this->use_ampmod2) this->ampmod2_pin.set(false);
return t;
}
Klipper is a split-role system where lightweight near-real-time firmware runs on the MCU (Tinyfab) and all the parsing and calculations are done on the Pi which is also running Octoprint and sent through to the MCU together with the exact time they should be executed. My question is whether the pin-on,read, pin-off sequence is required or whether I can just enable the pins and read it when ready? With the split roles of Klipper it's more tricky to sequence several operations like that, it would be far easier to just schedule a repeated temp sensor read that feeds back to the PT100 calculations which can then be done in Python on the Pi.

Thanks

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Sat Sep 08, 2018 12:24 am

yoyo42_cetus3d wrote:
Sun Sep 02, 2018 9:43 pm
I have a Cetus MkII extended with the tinyfab CPU. I'm trying to sort it out to use Klipper
there is klipper stepper fw for arm too? cool, I tought they only have the slave/stepper fw for duino.. not that I see a point for 32bit system doing stepping but .. interesting to know :D ... I'm personally waiting for a right moment to try out klipper but time is just ... well ..
yoyo42_cetus3d wrote:
Sun Sep 02, 2018 9:43 pm
My question is whether the pin-on,read, pin-off sequence is required or whether I can just enable the pins and read it when ready?
yes you can. the way I figure out this works (you can see the whole schematic of the ADC amp in some of my posts, will try to add it to this post too if I find it :D ) is that "energizing" those two pins is used for dual purpose
1. with combo of 00, 01 and 10 you should / might be able to do some calibration of the readout to have more precise readings. I assume that 'cause that's the only reason I could explain the schematic and why the two pins are used. There's no other explanation I can come up with for using 2 pins instead of just one.... especially I never figured out where the other end of RA30 goes to :(

2. if you constantly push current trough PT100 it gets heated from that current itself so your temp will read higher trough time then actually is as the sensor itself gets compromised, so this way you push current trough sensor only when you do the read, then you "turn it off", so your readings are consistent and accurate. This again is assumption as I do know sensors do heat up from the current pushed trough them but empirically I tried a 45min print with these pins on 100% of the time and I did not notice any issues ... also was reading the "ambient" trough the sensor for 60min and there was no noticeable errors in reading, no visible drift ... maybe 10h print would show some different results but since I anyhow did the energize/unenergize I didn't care too much ..

So answer is - no clue .. will the reading be less accurate - surely it will, is it important, will it affect the print quality - no idea :( .. in theory yes, in practice - probbly no.
Attachments
Capture.JPG
the PT100 amplifier on board of UP
Capture.JPG (54.8 KiB) Viewed 7043 times

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Sat Sep 08, 2018 8:36 pm

forgot to add, RA30 is linked to ENABLE, I don't know where it goes trough the enable relay but it is connected to enable relay and if enable is off your readout of the PT100 will not be ok, so other then those 2 energize pins that have to be on to read the temp enable must be on too!

yoyo42_cetus3d
Posts: 3
Joined: Sun Sep 02, 2018 9:33 pm

Re: Custom MCU-module for UP! Mini...

Post by yoyo42_cetus3d » Mon Sep 10, 2018 9:51 pm

That's great, thanks. I have a feeling I saw that diagram somewhere before but I haven't been able to find it again.

Yes, there's a Klipper for the LPC176x now, it's quite recent but seems to work fine. With various hacks to get around the thermistor not working yet I've had it 'print' a tree frog at 150mm/s and it seems very smooth and quiet. I used Octoklipper as the simplest way to drive it and play with the config and I'll push the config back to the Klipper github when I've got it all going (if they'll have it!). If not I guess I put my own fork up or put it on the Cetus FB group or something.

Based on what you've said about energising full-time not seeming to cause issues, short term at least (and print times will be a lot shorter at 150mm/s), I'll switch my focus to getting accurate temps out now and leave the pins energised for the first draft and fix it later. There are so many safety features in Klipper that if the heater isn't seeming to heat as fast as it expects it shuts it off again, which makes it tricky to do trial and error...

The other issue I'm seeing at the moment is that the Z axis seems to come down more than it goes up, I'm guessing it's missing steps when it's harder to push. The Z axis on the Cetus seems really slow (especially when 'home' is at the top of the extended 280mm tower) but driving it faster makes it worse :-(

The stepper current is set in hardware on the Cetus and it worked fine with Smoothie (Tinyfab does distribute a fork based on your PT100 fork) so I don't think that's the issue.

More later...

arhi
Posts: 256
Joined: Sun Mar 08, 2015 10:51 pm

Re: Custom MCU-module for UP! Mini...

Post by arhi » Fri Sep 14, 2018 12:33 am

drop the speed and accel for Z, not that it's too important to run it fast :D

as for the temp, what I did was I detached the PT100 from the extruder pcb and connected a crocodile clips instead, then I used a table for PT100 vs R

e.g.: https://www.intech.co.nz/products/tempe ... ypert.html

then, I see on the table, 0C is 100R, I get my super precise 4 wire multimeter and I turn my 200R multiturn pot to 100.000R, I hook it to the crocodile clips instead of the PT100 and I read the ADC values from the mcu (or with klipper, whatever you can extract as temp value)

then, look at table, 10C is 103.90, rotate multiturn to 103.900000 hook back to printer, read value ...

do it every 10C till you get to 350C

draw the curve, figure out how to make transformation from that curve into real values and put that polynomial function into your klipper system :D

Post Reply