Greetings
This build is mostly created from leftovers from the spare parts bin.
Most parts are new / unused.
Recently acquired a new 40W tube (freebie) and have a bunch of motors, motion rails, wires, drive boards etc left over from other projects including a new smoothieboard.
Unfortunately … have never used a smoothieboard before.
Or
Have never used Lightburn before.
Lightburn and smoothieboard are talking and there is some movement … machine probably could be use “as is” but it runs roughly.
The issues :
When stop button is activated software must be closed and restarted. i.e. M999 or $X won’t restart the program.
Pause button not working.
Keyboard shift plus move command causes a runaway which then crashes the machine. (Keyboard control plus move command does perform a small jog)
$H or G28 moves opposite of desired direction but only a small amount and then resets all axis(s) to zero.
Home is set wherever the head happens to be when program is opened.
Homing command does not cause the machine to seek the end stops.
Lightburn and smoothieboard have the most recent version of firmware.
config files are available to examine.
Tried lots of different configurations.
No joy.
Thought I’d try here.
This sounds like they have not implemented compatibility with Smoothie. We can help them do that if they ask us, no issue. Possibly even easier, is they can just look at the source code of software that already has compatibility ( Pronterface, octoprint, laserweb, visicut, bcnc, etc ) or look at some of the example code provided along with the smoothie codebase.
Homing not working isn’t normal. What does M119 say? ( see the troubleshooting page and the endstops page )
Lightburn does indeed work with Smoothieboard as I run it on my 4xC smoothieboard. Have you tried G28.2 for homing? The pins may need to be inverted in the config depending on how its wired. It should “home” to the switches(upper-left on most K40’s for comparison) but “Origin(0,0)” is always bottom-left. Limit switches are best if hooked up as normally closed connected to ground so that if a wire gets damaged it will stop (better than the other way where it wont!).
Pause I believe is tricky depending on the operation. I believe that even hitting pause, smoothie will still run through whatever is loaded in the buffer(which can be up to 32 commands I believe. for engraving that’s not much at all but for cutting that could be several seconds of action or potentially the whole job if it is small.)
When you hit stop try right-clicking on devices to reset the connection, that might work to reset it. i don’t use keyboard commands to move around so I couldn’t help you there. Have you tried the move laser to position feature in Lightburn? Its on the left bar you click it then click where you want the laser head to move. Amazing feature. Arthur can clear up any miscommunications of mine as he knows the boards much more than I as he helped develop them.
Each command ( G-code ) is cut-up into segments ( thinks of a circle, we cut it into a list of very small segments ). Smoothie can have 32 segments in it’s buffer ( they might all come from a single G-code in some situation ).
The buffer is used for look-ahead: doing the math in advance to know if we are going to need to accelerate or decelerate soon, and acting in accordance. A longer or shorter buffer ( within reason, 16-64 say )really shouldn’t have significant impact on speed or ability/quickness to pause.
To debug endstops, I strongly recommend reading the endstops page on the wiki, thousands of users a year use it to step endstops with no issue. If you read it and still have questions, at that point you should be able to ask more precise/relevant questions.
If you don’t want to wait for a pause command, you can use the kill command, which stops instantly. The only downside is after a kill you have to seek the origin ( $H ) before you can work again.
See http://smoothieware.org/stopping-smoothie
Lasers should use the CNC build ( see dedicated wiki pages, a good start is http://smoothieware.org/grbl-mode ), and on that build, homing is done through the $H command ( G28* is about moving to the origin ( when it is known ), not seeking it )
Arthur
Thanks for the push.
After re-reading the end-stop pages a few more times the machine now homes as expected in X and Y axis.
Switches were indeed configured incorrectly.
Z axis is moving backwards and haven’t figured that out yet.
Next try will be to swap wires from the motor to the board and then toggle the direction button in the software.
This is definitely a software/config issue, you shouldn’t change your wiring to accomodate it, you should instead fix your config ( by inverting the direction pin ). This is explained in detail in the documentation, you really should read all the parts that are relevant to your machine.
LightBurn does indeed have Smoothieware support. The next release adds a feature to alter the GCode output for faster pausing as well.
Smoothieware will execute all moves remaining not only in the planning buffer, but the communication receive buffer as well. LightBurn sends data as fast as Smoothieware will accept it to improve raster performance, but that means more moves in the queue that must be executed before a pause. If those moves are long and slow, like cutting a simple rectangle, it can take minutes before a pause command actually pauses the machine.
The new “Improved Pause” feature reduces this to a few seconds. It would be much better if Smoothieware itself had a real feed-hold command, but this workaround makes it more tolerable.
Smoothie does have a feed hold, the same one GRBL has I believe, it’s just not specifically documented I believe as it’s relatively recent ( less than a year at this point ). I believe bCNC is able to use Smoothie’s feed hold but I might be wrong.
Ah, just got word from Jim, who devs this, that ! does nothing at the moment, it was removed. Sorry for all the noise then
Note if one’s homing is relatively fast, you can do kill ( which is instant, but looses homing ), then home. That’s the fastest way to stop right now.
Oh an important thing also. If it takes minutes to stop when cutting a large rectangle, you can fix that by setting the millimeters per segment values to something like 1mm. Then you’ll never have more than 64mm at a time in the buffer, and it’ll always stop in 64mm ( that is significantly less than a second at normal speeds ) or less.
If you have a small flare up, or notice that the cutter is headed for a clamp, “pause now” is really nice to have and doesn’t ruin the job like stop/home would.
And I should revise my earlier statement - in my experience, it appears that Smoothieware executes all pending moves, both in the planning buffer and in the receive buffer, but I can’t say that for certain - I haven’t verified it. If this is true though, it would mean that having Smoothieware segment the moves into sections wouldn’t be enough.
Having a maximum segment length ignores speed. LightBurn segments the gcode output based on the feed rate, so moves are time limited, not distance limited. If your job includes slow cutting, with a feedrate of 5mm/sec, for example, 64 moves in the buffer would take almost 13 seconds to pause, but a feed rate of 250mm/s would stop in 0.256 seconds. If you shorten the segment length enough to pause reasonably when moving slow, you might not have enough look-ahead to go fast if your acceleration isn’t high enough. Time limiting the moves gives identical performance at all speeds.
The buffers are not that long. Low values of segment size should still enable you to have the stop happen in a few seconds max ( as long as the host stops sending commands immediately ).
Having a maximum segment length ignores speed.
Not sure what you mean.
you might not have enough look-ahead to go fast if your acceleration isn’t high enough.
We’re talking about laser cutters here. They accelerate to full speed in well under a second typically. You could do 0.1mm segments ( that’s 1.6 seconds stop in your 5mm/s scenario ) and still be fine.
Right, but then you can’t go fast any more, as we see constantly with raster engraving of photos hitting the 800 gcode/sec processing limit. With a 0.1mm segment, you hit a speed limit in hardware of about 80mm/sec because it can’t process the instructions fast enough.
A maximum segment length is one size fits all. It will be broadly applied to all moves, whether those moves are set to run at 500mm/sec or 5mm/sec. Limiting the maximum duration of a move, instead of maximum distance, gives more consistent pause performance.
With a 0.1mm segment, you hit a speed limit in hardware
0.2mm then, it’s going to vary from setup to setup. Still possible to stop in a few seconds or less. Or if you prefer, systems where you can’t stop in a few seconds aren’t common.
Limiting the maximum duration of a move, instead of maximum distance, gives more consistent pause performance.
That wouldn’t be too difficult to implement and give a try, if somebody wants to do it.
Lightburn is a host program that generates and sends Gcode. I was talking about adding time-based limits on the Smoothie/gcode interpreter side. How would lightburn implement per-block speed limits?
I’m having difficulties getting to a deep enough understanding of this, but I’ll just trust you, and wait to see feedback from the community on the feature.
If a user draws a line 100mm long, and applies a feed rate of 100mm/sec, that gcode instruction will take one second to execute (ignoring acceleration). If the duration limit is set to 0.1 sec, the software will automatically break the line into a sequence of G1 commands, each 10mm long, so the duration of each command is not more than 0.1 seconds (again, ignoring acceleration). If the user sets the feedrate on a different shape to 300mm/sec, the software will automatically break that into 30mm segments, and so on.
