Skip to content

Instantly share code, notes, and snippets.

@arthurwolf
arthurwolf / gist:3129199
Created July 17, 2012 12:40
scissor jack dummy code
# current code is something like this : https://github.com/ErikZalm/Marlin/blob/Marlin_v1/Marlin/Marlin.pde#L1542
# that is :
void prepare_move(destination){
limit destination if it's over limits
feed_line_to_planner(destination);
current position = destination
}
# we want it like this : 
@arthurwolf
arthurwolf / gist:5102769
Created March 6, 2013 20:29
ExtruderFix compile error
Compiling libs/ChaNFS/FATFileHandle.cpp
Compiling libs/ChaNFS/FATFileSystem.cpp
Compiling libs/ConfigSources/FileConfigSource.cpp
Compiling libs/USBDevice/DFU.cpp
Compiling libs/USBDevice/USB.cpp
libs/USBDevice/USB.cpp: In member function 'int USB::addString(const void*)':
libs/USBDevice/USB.cpp:430:37: warning: cast from type 'const void*' to type 'usbdesc_base*' casts away qualifiers [-Wcast-qual]
Compiling modules/communication/GcodeDispatch.cpp
Compiling modules/communication/SerialConsole.cpp
Compiling modules/robot/Block.cpp
@arthurwolf
arthurwolf / gist:5209535
Created March 20, 2013 23:43
Smoothieboard config file for aluminatus
# Robot module configurations : general handling of movement G-codes and slicing into moves
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.2 # 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 10 # Lines can be cut into segments ( not usefull with cartesian coordinates robots ).
# Arm solution configuration : Cartesian robot. Translates mm positions into stepper positions
alpha_steps_per_mm 512 # Steps per mm for alpha stepper
beta_steps_per_mm 512 # Steps per mm for beta stepper
gamma_steps_per_mm 1600 # Ste
dmesg
[327244.654105] usb 2-1.4: new full-speed USB device number 34 using ehci-pci
[327244.748350] usb 2-1.4: New USB device found, idVendor=1d50, idProduct=6015
[327244.748356] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[327244.748359] usb 2-1.4: Product: Smoothieboard
[327244.748361] usb 2-1.4: Manufacturer: Uberclock
[327244.748364] usb 2-1.4: SerialNumber: 06060311535301644CF71966F5000006
[327244.749206] cdc_acm 2-1.4:1.0: ttyACM0: USB ACM device
[327244.749904] usb-storage 2-1.4:1.2: USB Mass Storage device detected
stepper interrupt
do the steps we decided to do from last interrupt ( we don't execute steps immediately but at the beginning of next interrupt, grbl does this too )
for each axis
store the new position for this axis based on the step just taken ( or not taken )
find the current block
// Called a great many times per second, to step if we have to now
inline void tick() {
// increase the ( fixed point ) counter by one tick 11t
fx_counter += (uint32_t)(1<<16);
// if we are to step now 10t
if (fx_counter >= fx_ticks_per_step)
step();
};
}
Changes needed for much more rational accel :
Essentially, all accel happens in stepticker, and the modules tell it what to do.
Note : once this is all done, experimenting with per-step accel is trivially easy ( the hardest part being changing planner to set accelerate_until and decelerate_after to be expressed in ticks instead of steps, which is not too hard, but has to be done )
Changes to steppermotor : 
* Instead of getting distance ( once ) and speed updates ( on a regular basis ), it gets distance + initial speed + accel + accelerate_until + decelerate_after ( once ) and stores them
* On accel tick call from stepticker, update speed ( speed += accel_change ), checks if we are at a point where the accel ramp needs to change, and if so, modify accel_change
Note : to try to limit the number of ifs, we don't test both for if(current_step = accelerate_until) and if(current_step = decelerate_after) but we check for if(current_steps = next_ramp_change), and then change next_ramp_change as needed when a ramp c
Changes needed for much more rational accel :
Essentially, all accel happens in stepticker, and the modules tell it what to do.
#########################
Changes to steppermotor :
* Instead of getting distance ( once ) and speed updates ( on a regular basis ), it gets distance + initial speed + accel + accelerate_until + decelerate_after ( once ) and stores them, then does accel itself
* On accel tick call from stepticker, update speed ( speed += accel_change ), checks if we are at a point where the accel ramp needs to change, and if so, modify accel_change
Note : to try to limit the number of ifs, we don't test both for if(current_tick = accelerate_until) and if(current_tick = decelerate_after) but we check for if(current_tick = next_ramp_change), and then change next_ramp_change as needed when a ramp change happens
Note : we need to modify planner to express those in term of ticks instead of steps, and then just compare them with the current tick
/*
This file is part of Smoothie (http://smoothieware.org/). The motion control part is heavily based on Grbl (https://github.com/simen/grbl).
Smoothie is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
Smoothie is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with Smoothie. If not, see <http://www.gnu.org/licenses/>.
*/
#include "Extruder.h"
#include "libs/Module.h"
require 'bigdecimal'
DOPLOT= false
TOFILE= false
STEPS_PER_MM= 80.0
STEP_TICKER_FREQUENCY= 100000.0
# set these
distance= 3 # total distance to move for single axis in mm