Smoothieware per-axis acceleration vs. default acceleration

Machine: FSLaser Muse

Board: LaserBoard

Firmware: Smoothie Cluster

It’s likely this question is more suited to the Smoothieware forums/etc., but since the Cluster firmware modifications look to be touching multi-axis acceleration management, I thought I’d start by asking here.

I replaced a Full Spectrum Laser Muse’s stock controller with a LaserBoard. This swap was a bit of a project in itself, but aside from some PWM quirks, I didn’t encounter any hardware, wiring or basic setup problems I couldn’t address. My problem, in a nutshell, is this: the Muse’s X and Y axis have drastically different acceleration capabilities, and Smoothieware consolidates them in a way that’s proving unintuitive and problematic. For some background, the Y axis can accelerate nearly an order of magnitude faster than the X axis. Let’s say (ballpark) 8,000 mm/s^2 vs. 1000 mm/s^2. Y’s maximum velocity is roughly three times that of X’s also.

When configured as default_acceleration = 8000, alpha_acceleration = 1000, beta_acceleration = 8000, Y is fast and can apparently (I haven’t tested this extensively) support a few hundred mm/s for engraving. However, the X axis acceleration limit doesn’t appear to be respected fully, and I can hear X missing steps occasionally when following complex paths when vector-cutting a test pattern (e.g. a Hello World text outline). This is with junction_deviation dialed down all the way.

When configured as default_acceleration = 1000, alpha_acceleration = 1000, beta_acceleration = 8000, X behaves as expected, and never misses any steps. However, Y is then limited to 1000 mm/s^2, which severely limits its engraving speed. Even straight, X-axis-only G0 moves are apparently limited to 1000 mm/s^2. I know Smoothieware does coordinated moves, but it’s unclear why it limits single-axis moves the way it does.

default_acceleration defaults to 100 mm/s^2, so if unset, that’s what both X and why are limited to. Basically, changes to default_acceleration govern machine motion, even though the acceleration is specified explicitly for X and Y. This has my stumped at the moment. I see the same behavior with stock Smoothieware firmware, so it doesn’t appear to be related to the Cluster firmware changes.

Does this ring any bells, and/or does anyone have suggestions for experiments to try?

Wait, you did a Muse controller swap? Did you take pics? I’ve wanted to see this happen for quite a while now. I did a FSL Hobby Gen 5 for a friend a while back, and that was “fun”, but not nearly as fun as what a Muse would be. Total lobotomy.

Here was my Gen 5 work:

I took a lot of pictures, perhaps I’ll put them in an album such as yours someday. I attached a few photos of what it looks like right now. Not visible here is the Ethernet daughter board, which is mounted on the back of the LaserBoard. I swapped the motor headers and the DC barrel connector on the LaserBoard also, but most of the heavy lifting is done by the interposer.

Sweet! I’d love to see and discuss more about this at some point.

In our stock config file, per axis acceleration values are defined. Can you try with very low values as a different test to see if it will respect them? For example, set acceleration to 2500 as we ship it, and set the alpha_acceleration to 500. You will notice when you try to jog just in X, if that accel value is being respected.

Also, what is this about a config line value for default_acceleration? There is simply the acceleration value and then the per axis one.

Sure, I’ll be happy to chat about the swap. The stock setup looks pretty daunting at first sight, but it’s all pretty straight forward with a few notable exceptions (e.g. the power supply).

As to the acceleration settings, I pushed alpha_acceleration down to something like 400 and still had problems. It seems that whenever default_acceleration is > alpha_acceleration, coordinated moves have the potential to violate X’s acceleration limit. I guess I’ll have to set up a serial console, enable debug prints, and dig deeper. Oh, and default_acceleration is what the unqualified acceleration setting is called in the code. I thought it’d be clearer to call it that.

Also, jogging does use the per-axis acceleration values. That’s how I established the initial numbers.

I took a look at the code, and it seems that default_acceleration (acceleration in the configuration file) is used as the starting point for the computation of the final acceleration. It is only ever adjusted down, never up. So if it is lower than the per-axis limits, it limits the final acceleration. So this behavior makes sense to me now.

The code in question also changed in the edge branch in May of last year, when a mixed primary/auxiliary axis acceleration bug was addressed. I don’t believe those changes affect my situation, but a number of debug print statements were added that I can enable to figure out what’s going on. I’ll try to make some time this weekend to get to the bottom of this.


To close the loop on this, with logging, I convinced myself that the primary axis velocity and acceleration adjustment works as intended. I ended up backing off more on the Y axis limits and while I’m sure the settings ended up a bit on the conservative side, the motion sounds right to me now. I may tweak it a bit more later on.

1 Like

This is fantastic - glad you were able to get the machine under control. Would you be willing to share your final settings for other folks to use as a starting point if they decide to go down the route of converting one of those machines themselves?

Sure. I’ll post a copy of the configuration file the next time I get a chance to open the machine. I should document some other more interesting aspects of the conversion. There are lots of little things (voltages for the LED strip and laser diode, pin-outs for the optical limit switches and the water flow sensor, PSU quirks, …) that add up to a fair amount of complexity. And I didn’t bother to replicate some of the stock functionality (such as relay-operated external control outputs for the fan/air).

I should also note that I’m more interested in vector scoring/cutting than in engraving, and that I haven’t spent a lot of time on the PWM tuning. Even so, I noticed that 200-400us for the PWM period aren’t sufficient to get a near-linear response out of the PSU (2-10mA). I have it set to 1ms at the moment, which seems high. The stock controller looked to be using PWM for both the laser fire and the current limit, and may use a combination of the two for engraving.

As an aside, the Muse has a camera module mount on its laser head that fits 1080p ELP modules. I installed one (with M2 stand-offs and screws), though with a 6mm lens to aid in accurate positioning, specifically locating drill holes and/or fiducials on PCBs and determining translation/rotation/scaling/skew. The stock Muse camera (on models that have a camera) is using a super wide-angle fisheye lens, I think. But even so, it can’t cover the entirety of the bed. Their software has a function to take something like 6 stills and stitch them together. That might be something for Lightburn to consider (if it doesn’t already have something similar).

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.