smoothieware / smoothieware Goto Github PK

According to git bisect commit addfb45 was the first commit to cause the following crash https://gist.github.com/wolfmanjm/4974793

However as several of the bisected builds did not even compile this may not be 100% accurate, but is probably close.

Something as simple as G1 Z100 F10000 will cuase it to crash, entered from either serial conasol or USB console

Planned refactor.

We would stop storing gcodes amongst with blocks. Instead, modules would read gcodes in on_gcode_received, transform those into a ModuleData storage thingie, that would be attached to blocks.

class ModuleData { Module* owner; }; .... class TemperatureControlBlob : public ModuleData { ... }; .... class Block { ... vector or whatever <ModuleData*> data; }

create a class StreamOutputPool that houses a list of all StreamOutputs like the new configsources system, and whose default printf() is sent to each StreamOutput.

When initiating the homing sequence, i.e. for the X axis, the position returned by M114 is not set to zero.

M114
C: X:0.000 Y:0.000 Z:0.000 
ok
G01X700
ok
M114
C: X:700.000 Y:0.000 Z:0.000 
ok
G28X
move done X
test a
test b
axis X 
test c
move done X
ok
M114
C: X:700.000 Y:0.000 Z:0.000 
ok

Would expect the output of M114 to be:

M114
C: X:0.000 Y:0.000 Z:0.000 

after homing the X axis, but I'm not sure if this is a bug or feature.

arthur-> eventually it'd be nice to have an option in the makefile that tells us if it's 68 or 69, and default it to 69
arthur-> so we have 120mhz by default
arthur-> not sure how practical that'd be
adamgr> The easiest way is to create a new 1769 target in the mbed SDK, configure it for 120MHz and then use the DEVICES variable in the makefile to build for both.
adamgr> YOu then get a LPC1768 and LPC1769 output directory.
arthur-> that sounds good
arthur-> wouldn't building for both take double the time ?
adamgr> The way the makefiles work today…yes.
adamgr> But could be optimized I think.
arthur-> adamgr: there is no emergency but at some point I'll ask you how to do that :)

Please add the G04 Dwell Pxx command support to Smoothie.

Pxx is usually defined as xx milliseconds.

Typical uses:

• with a milling spindle when the tool is turned on, to give it time to get up to speed (2 - 3 seconds)
• after a Z axis move down when drilling or milling to give time for the spindle to actually penetrate the material (some spindles, though driven down, are actually free floating and don't always drill down at the same rate the motor drives the spindle down).

in the case where axes may share an enable pin (eg it makes sense for XYE to share an enable pin on repraps) and we don't want E to turn off XY when we do a travel move.

the Pin object should remain valid, but silently ignore any attempts to set pin state and return success.

include a method to positively set a pin as 'not present' via config-set/config-get over serial, just in case

must be a module, must keep already played files

Steps to reproduce:

1. open the USB-terminal (couldn't reproduce it on the UART-Terminal, but that may be a coincidence)
   edit: it was coincidence
2. repeatedly type "play /sd/gcode/hw.gcode"
3. you'll get a crash after a random number of plays

Dump and the file that caused trouble: https://gist.github.com/powertomato/5506303

As GDB wasn't very helpfull I tracked it down to this line using "printfs" (it doesn't get further than that):
https://github.com/arthurwolf/Smoothie/blob/edge/src/modules/utils/player/Player.cpp#L62

Regardless of what setting is in the config file the top speed the delta/rostock seems to be 6,000mm/min, in any axis.

I cannot see why this should be I followed the logic in Robot and Planner and it looks good except where this->max_allowable_speed(-this->acceleration,0.0,block->millimeters); passes in 0.0 as the second parameter which looks like it will always return 2 * acceleration*distance, not sure if that is correct.

during first layer infill on the attached gcode, the extruder suddenly starts spinning very fast, then the motor makes the distinctive sound of being driven waaay too fast while the XY robot moves haltingly a few mm every few seconds.

gcode
config

The config is suitable for a MendelMax with gregstruder and 3mm ABS filament.

Extruder still uses the mbed libs, must be replaced with config options and Pin modules.

The LPC1768 has a notoriously unstable ADC. The mbed community has had a bit of experience dealing with this and have a few tricks to mitigate the problem. In addition to digital filtering (which we already do), they recommend that any unused analog inputs are grounded. An easy way to do this is to configure them as digital outputs and drive them low. It may be a good idea for Smoothie to do this, although it's unclear how this can be achieved in a hardware-independent manner.

References

• http://tech.groups.yahoo.com/group/lpc2000/message/56239
• http://mbed.org/forum/bugs-suggestions/topic/1514/?page=2#comment-7783
• http://mbed.org/forum/mbed/topic/1866/
• http://gvworks.blogspot.com/2011/03/lpc1768-adc-has-too-many-glitches.html
• http://mbed.org/users/chris/notebook/Getting-best-ADC-performance/

Must add the ON_IDLE event, that gets called both in the main loop, and when waiting is done in that main loop.

And while we are at it, make the sd card player in SimpleShell not say new commands if the queue is nearly full, so that commands can still be sent from Serial

• Module not loading when enabled...
• Please make the max laser intensity adjustable (besides the speed adjusted intensity)

Smoothie $ git log | head -n6
commit 0eb11a0
Author: Arthur Wolf [email protected]
Date: Wed Nov 23 10:41:46 2011 +0100

First seemingly working Extruder module

Smoothie $ make
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshort-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -fno-exceptions -I./src// -I./src//libs/ -I./src//modules/ -I./src//modules/communication/ -I./src//modules/communication/utils/ -I./src//modules/robot/ -I./src//modules/robot/arm_solutions/ -I./src//modules/tools/ -I./src//modules/tools/extruder/ -I./src//modules/tools/laser/ -I./src//modules/utils/ -I./src//modules/utils/pauser/ -I./src//modules/utils/simpleshell/ -I./gcc4mbed/external/mbed -I./gcc4mbed/external/mbed/LPC1768 -I./gcc4mbed/external/FATFileSystem -DTARGET_LPC1768 -c gcc4mbed/src/gcc4mbed.c -o gcc4mbed/src/gcc4mbed.o
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshort-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -fno-exceptions -I./src// -I./src//libs/ -I./src//modules/ -I./src//modules/communication/ -I./src//modules/communication/utils/ -I./src//modules/robot/ -I./src//modules/robot/arm_solutions/ -I./src//modules/tools/ -I./src//modules/tools/extruder/ -I./src//modules/tools/laser/ -I./src//modules/utils/ -I./src//modules/utils/pauser/ -I./src//modules/utils/simpleshell/ -I./gcc4mbed/external/mbed -I./gcc4mbed/external/mbed/LPC1768 -I./gcc4mbed/external/FATFileSystem -DTARGET_LPC1768 -c gcc4mbed/src/syscalls.c -o gcc4mbed/src/syscalls.o
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshort-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -fno-exceptions -I./src// -I./src//libs/ -I./src//modules/ -I./src//modules/communication/ -I./src//modules/communication/utils/ -I./src//modules/robot/ -I./src//modules/robot/arm_solutions/ -I./src//modules/tools/ -I./src//modules/tools/extruder/ -I./src//modules/tools/laser/ -I./src//modules/utils/ -I./src//modules/utils/pauser/ -I./src//modules/utils/simpleshell/ -I./gcc4mbed/external/mbed -I./gcc4mbed/external/mbed/LPC1768 -I./gcc4mbed/external/FATFileSystem -DTARGET_LPC1768 -c src//main.cpp -o src//main.o
In file included from src//libs/Kernel.h:11:0,
from src//main.cpp:9:
./src//libs/Config.h: In member function 'ConfigValue* ConfigValue::by_default(double)':
./src//libs/Config.h:60:46: warning: declaration of 'value' shadows a member of 'this'
arm-none-eabi-g++ -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshort-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -fno-exceptions -I./src// -I./src//libs/ -I./src//modules/ -I./src//modules/communication/ -I./src//modules/communication/utils/ -I./src//modules/robot/ -I./src//modules/robot/arm_solutions/ -I./src//modules/tools/ -I./src//modules/tools/extruder/ -I./src//modules/tools/laser/ -I./src//modules/utils/ -I./src//modules/utils/pauser/ -I./src//modules/utils/simpleshell/ -I./gcc4mbed/external/mbed -I./gcc4mbed/external/mbed/LPC1768 -I./gcc4mbed/external/FATFileSystem -DTARGET_LPC1768 -c src//libs/Kernel.cpp -o src//libs/Kernel.o
src//libs/Kernel.cpp:21:34: fatal error: modules/robot/Player.h: No such file or directory
compilation terminated.
make: *** [src//libs/Kernel.o] Error 1

My setup has a Z-axis end stop at the top instead of bottom. Consequently, my homing procedure moves the tool to 0,0,200, not 0,0,0. However, the origin is at 0,0,0, meaning my home and origin are not the same thing.

(i won't go into reasons for having it set up like this - suffice it to say that it's easier to adjust Z0 in software than fiddling with the endstop position)

With most Atmel/Arduino based firmwares, it's possible to choose the homing direction on a per axis basis, as well as the min and max coordinates for each axis, so homing towards max will reset the position for that axis to the max coordinate specified. It would be nice to have that in Smoothie.

My C++ is (more than) a bit rusty, but i might try and hack something up when my current work chaos subsides, unless someone else tackles this in the meantime.

The millimeters_of_travel is not correctly calculated in the case of a delta style bot.

This line
https://github.com/arthurwolf/Smoothie/blob/edge/src/modules/robot/Robot.cpp#L242

Caculates the distance but consider the case of a delta moving in Z, All three axis will move but the actual distance travelled will be Z not the sqrt of the square of all three.

I think the millimeters of travel calculation needs to be moved into the arm solution.

Gcodes always return "ok" no matter what happened.

A mean should be provided to modules to say that something went wrong.

Also something should be done if the gcode was not recognised as valid ( error or warning ).

Will require adding flags/counters to the gcode objects, and methods for modules to say if things went well or not.

My current implementation of HEAP_TAGS works in newlib but not newlib nano. Letting the Smoothie project kick the tires on newlib nano for a bit before I port this functionality over.

We should be able to detect when the thermistor is taken off the hotend and the temperature starts to drop, or the thermistor is disconnected, and act accordingly ( emergency stop ).

Add a module ( pbrier stated a basic working one using the mbed libs ) to turn on and off gpio pins.
Do that with a pool like temperaturecontrol, and config-based.

It makes sense as a way of signaling something is wrong, but unfortunately, clients like Pronterface choke on it.

Pronterface in particular tries to convert it into integer and errors out trying to refresh the temperature widgets (causing slight weirdness in Windows and major UI weirdness on Mac).

[12:49] pid?
[12:49] pid is Proportional, Integral, Derivative. a control algorithm used for tempcontrol in some repraps. http://en.wikipedia.org/wiki/PID_controller and a nice Arduinotutorial can be found at http://goo.gl/vWQpE -- Marlin can now auto tune your PIDparameters. First run M303, your bot will heat up to 150, let it cycle several times, marlin willprint out increasingly accurate pid values. Use M301 Px Ix Dx to enter new values and M500 to store

Hi
I want to use smoothie as a 3dprinter firmware on an mbed. When I connect to the device via a serial-termial, (115200, 8N1) it just echoes garbage back(bytes like: C1 FF). Can you give me a hint how I can solve this problem or could there be a problem in the code?
Thank you

I just created a wiki page for Smoothie project which give some information on how to connect GDB, etc. https://github.com/arthurwolf/Smoothie/wiki/Debugging
Also linked to it from wiki home page.
adamgr: is it ok if I move that to the wiki at http://smoothieware.org/ ?
or maybe I can just link to it ...
adamgr: awesome !!!!!!!!!!!!!!!!!!!!!!!!
omg awesome
Do with it as you see fit :)
adamgr: thank you a ton, that will help a lot
no problem.
Hope it helps
it will
I think you have seen, with the amount of mri talk there is on this channel :)
it's even useful to me :)
adamgr: can I manually enter MRI mode from smoothie code ?
like enter_mri() ?
yep
#include "mri.h"
__debugbreak()
I need to implement a command for that
making that a ticket

Currently, with a line like this :

G90 G21

Smoothie does not read multiple gcodes.
It should

Whenever I issue a G-code command, Smoothie doesn't store current position. The current position after G0, G1 command becomes new zero coordinate.
On the other hand, DIR works correctly.

wolfmanjm hit a crash today and provided me with a full crash dump.

The gist is here: https://gist.github.com/wolfmanjm/4726146

I have done some initial investigation which I will link to in a followup.

Currently the planner_queue_size configuration option does nothing despite being in the default configuration. This should be fixed.

Tabs should be ignored or treated as white space.

On a 3-axis cnc machine, moves longer than 20mm are not smooth.

This happens when manually entering gcode in a console, or when playing a gcode file.

Moves 20mm or less are smooth and working as expected.

Smooth moves:

• Manual gcode: "G0 X-20" resulting video http://db.tt/Lqqzl6TU
• Play gcode file gcode000.gco http://pastebin.com/98hpaGhW & resulting video http://db.tt/uvvwYrEN

Unsmooth moves:

• Manual gcode: "G0 X30" resulting video http://db.tt/pY6xbI6Z
• Manual gcode: "G0 X60" resulting video http://db.tt/XxzygGoe
• Play gcode file gcode001.gco http://pastebin.com/Rk6HmtJH & resulting video http://db.tt/FQgwGJkq

Breadboard & Config

• Config file: http://pastebin.com/iBHU8aTL
• Breadboard image: http://db.tt/bBqUnNBF
• Stepper driver wiring: http://db.tt/3hmojyrx

The PID values entered into my config file are not read by the smoothie firmware. The config entries are

temperature_control.hotend.p_factor 73.4
temperature_control.hotend.i_factor 0.515
temperature_control.hotend.d_factor 131

temperature_control.bed.p_factor 66.5
temperature_control.bed.i_factor 0.134
temperature_control.bed.d_factor 413

Currently, gcode strings are popped in and out of existence on the stack.
That's very very bad.

We must use a static array like we do for the Block objects in the queue.

It would be great if Smoothie would allow for configuring the number of axes, i.e. allow for more than three axes and the axis names i.e. "XYZABC".

Don't know how much effort needs to be put in on the coding side.

A use-case would be @koppi 's six-axes Mitsubishi RM501 MoveMaster robot -- it's an oldtimer robot with a new diy servo controller unit, see here - http://www.youtube.com/watch?v=RJ7PFPT9ocw

What do you think?

Originally in :
#9

The fixed point counters in Stepper are 32bits, which is not good enough for long linear moves, and can cause bugs.
A temporary solution is to reduce mm_per_line_segment.

But the bitmath of this should be changed.

Currently, acceleration is calculated in a separate interrupt, at a fixed frequency.
We want it to update every step.

This is an interresting read : http://www.eetimes.com/design/other/4026992/Linear-motor-control-without-the-math-item-1

Currently SerialConsole uses hardware directly, but this should be done through a hal in libs/ like pins.h or adc

Currently Laser uses hardware directly, but this should be done through a hal in libs/ like pins.h or adc

auto-executes of boot if present

when I'm trying to switch to the edge branch, I get following error:

error: unable to create file
config-smoothieboard-copy_me_to_sd_card_and_rename_as_"config" (Invalid argument)

As I understand on NTFS git cannot create file with " in the file name.

Please remove " from file name.

Data sent via kernel->streams does not come out of the uart (replies to commands, start message). Data sent by plain printf (DFU messages, MRI gdb string) does. Smoothie successfully receives data from the uart.

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
85ce043 "Move files in preparation for new build system."
172d42d "Update to new build system."
We cannot bisect more!

this bug created mostly as a placeholder for discussion, will dig soon

It takes too long to go there, should happen in another, lower priority interrupt. But still happen as soon as possible.

G92 is making weird steppings and stupid stuff and forgets the offset at the end...

Printing the gcode file attached to https://gist.github.com/wolfmanjm/4981263 the crash also in that gist is seen. Quite repeatable.

Used play /sd/gcodefile.g -q
from USB console

On current edge. Printing with Rostock solution. Need to see if it also crashes cartesian solution.

May well be an out-of-memory issue. at time of crash
sp 0x10007c88
heap 0x10007c00

With a 12v Prusa PCB heated bed, PID autotune (M303 S1 P100) runs endlessly, because the starting voltage of 6v is insufficient to heat the bed above 80c.

The Autotune code should detect when its test voltage is insufficient, and restart the test with a higher voltage.

particularly the pin needs to be set in config so that p21 / p2_5 is not 'reserved'

I have this turned on temporarily to make it easier to debug write faults. Once we get through debugging the current heap related issues, this option should be disabled.

Testing usb console on latest edge (with briands usb fixes) gives me odd results

There seems to be a buffer of the commands sent as the response from console/printer is delayed compared to what has been sent
[23:05] arthur-_ wait what's the symptom exactly ?
[23:05] arthur-_ do you get an answer to "ls" ?
[23:05] geektopia e.g.. If I connect to the usb console /dev/ttyACM0, and sent the following here.s what happens
[23:05] geektopia ls : nothing happens
[23:05] geektopia ls : nothing happens
[23:06] geektopia ls : (third time) I get output
[23:06] geektopia If instead I send gcodes mixed with consol commands I get confused e.g.
[23:06] arthur-_ geektopia: is that right after a reset ? it's possible after reset there is a delay before the usb starts being responsive
[23:08] geektopia ls: (nothing), M105: (nothing), G0 X10 :(output of ls), ls: (output of M105) etc...
[23:08] arthur-_ oh that's weird
[23:08] geektopia and pronterface can't connect, he aboce is through cutecom
[23:08] geektopia above
[23:08] arthur-_ ok thanks a lot

Smoothie consistently crashes only seconds after beginning a print. The binary was built with -O0 as I was already tracking down another issue at the time of the crash. The crash dump and binary are available here. This was on my issue95 branch