Suggestion: clarify SLB firmware vs GRBL version in Machine Information / docs

gSender đź’ˇ Suggestion
1

Hi all,

I wanted to share something that tripped me up while setting up my new SLB, in case it can help improve the docs and reduce confusion for others.

Context

  • Brand‑new SLB (replacing a failed X‑Controller), bought within the last month.

  • Using gSender, SLB firmware flashing guide here:
    https://resources.sienci.com/view/slb-firmware-flashing/

  • My $I output shows:

    • Firmware version: 20230917 at the top

    • BOARD:SuperLongBoard_B5.0.5b further down, along with the SLB‑specific plugins

So the board is clearly running a SuperLongBoard_B5.0.5b build.

Where the confusion came from

On the flashing guide, there’s a screenshot of the Machine Information popup that shows:

Firmware version: 20260318

In gSender, the same Machine Information popup on my SLB shows:

Firmware version: 20230917

Side‑by‑side, that really looks like “my brand‑new SLB is still running ancient 2023 firmware while the doc shows a 2026 build,” which is what led me to assume I must be out of date and start reflashing.

After a lot of investigation (including DFU/Zadig driver work and reflashing), it became clear that:

  • The “Firmware version: 20230917/20260318” value in Machine Information is actually the GRBL/grblHAL core version/date (the VER: line from $I),

  • While the true SLB firmware identity is the BOARD:SuperLongBoard_B5.0.5b string and related driver/plugins, which did not obviously tie back to that numeric date.

In other words, the SLB firmware package (e.g. 5.0.5b) can sit “on top of” a GRBL core build that still reports 20230917, so seeing an older date there does not necessarily mean the SLB firmware itself is out of date. But the UI and docs currently present that date as the “Firmware version”, which makes it very natural to think “mine is old; the screenshot is new.”

Why this matters

Because the flashing page and video say “flash, then check your firmware version,” and highlight that Machine Information field, I ended up:

  • Assuming my board shipped with outdated firmware because the date didn’t match the example,

  • Spending time chasing a “missing” update that may never have existed for my exact board,

  • Only later realizing that the BOARD:SuperLongBoard_B5.0.5b line in $I is the real indicator of which SLB image I’m running, and that the 2023 date is just the underlying GRBL core.

The DFU driver work was important anyway (flashing didn’t behave correctly until Zadig was sorted), but the reason I went down that path at all was the apparent mismatch between “Firmware version: 20260318” in the doc and “Firmware version: 20230917” on my brand‑new SLB.

Suggestions

A couple of small changes could make this much clearer:

  1. In gSender’s Machine Information popup for SLB/SLB‑EXT:

    • Either relabel that 8‑digit number as something like “GRBL core version”

    • Or add a separate line for “SLB firmware: SuperLongBoard_B5.0.5b” and clarify which one users should look at when checking they’re on the latest SLB build.

  2. In the SLB firmware flashing doc:

    • Explicitly state that on SLB, the board/firmware name (e.g. SuperLongBoard_B5.0.5b) is the authoritative “which firmware am I on?” value,

    • And that the 8‑digit date shown in Machine Information is the GRBL base version, which may not change with every SLB firmware release.

I’m attaching two screenshots:

  • The one from the flashing guide showing “Firmware version: 20260318”.

  • My Machine Information popup showing “Firmware version: 20230917” + $I showing BOARD:SuperLongBoard_B5.0.5b.

Hopefully this helps tighten up the docs/UI so that other new SLB owners don’t go chasing a phantom firmware update just because their GRBL core date doesn’t match an example screenshot.

Thanks for all the work on SLB and gSender—once I understood the layering (GRBL core vs SLB firmware), everything else made a lot more sense.

image
image1598Ă—1022 192 KB

image
image1088Ă—1020 156 KB

2 Likes
2

I don’t think that’s correct with how we’re doing things internally now/into the future when it comes to firmware/hardware releases but that’s changed since sienciHAL was originally released quite some time ago.

The [BOARD:…] report is now purely an indicator of the hardware itself, the semver is the indicator of the grblHAL firmware version, and we’ll be keeping these as 2 distinctive indicators of both your hardware and what’s running on it.

So on the latest firmware release for the EXT (publicly available), BOARD has no indication of version, it’s just the hardware indicator.

image

And same with the (yet unreleased) internal SLB firmware image that’s more recent - no versioning, just “what board is this”

image

This makes a bit more sense than the original strings which included board and version - we can use BOARD to determine specifically which hardware you’re running on in cases there might be EEPROM profile differences between board types and lets us
change behaviour. Useful now and into the future since we’ll be supporting multiple board types, like the SLB, SLB-EXT, and soon SLB-Lite and SLB-EXT2 (plus any future board developments).

Semver is the correct grbl version, both now and for the 5.0.5B firmware. This is used internally for handling changes that have occurred since SienciHAL was released (for example, the $spindles command on the 2023 firmware version is now $spindlesh in modern grblHAL with a different reporting structure, so we can gracefully handle that on the backend without the user having to be aware of the distinctions). It’s also the most useful thing for support to be able to see at a glance to help diagnose issues - not the board string.

It’s also more useful for compatibility for non-Sienci boards running grblHAL - where they could have any version of grblHAL running on their board so tying behaviours to our specific strings is not useful, but grblHAL core version is.

The flashing resources does link to the latest firmware version for each regardless of what the image shows, and all board ships with the latest firmware release. While having a different version shown in the screenshot I can agree is a bit confusing, these docs are shared between the SLB and SLB-ext sections so it’d always be wrong for one of them.

We could maybe consider including BOARD in the machine status info as well, but that’s also maybe a bit redundant, since your hardware will theoretically not change, but firmware updates have a higher chance of occuring, especially now that we’ve re-merged with core grblHAL with the latest EXT firmware releases.

1 Like
3

Thanks for the detailed explanation, that helps me understand the internal model a lot better.

I do still want to highlight the user‑side confusion though, just so it’s on your radar for future polish.

From an end‑user perspective, the normal workflow is:

  • Go to the firmware page, download something like SuperLongBoard_B5.0.5b.hex.

  • Flash it with gSender.

  • Then want to confirm: “My board is now running that exact firmware.”

Right now, the only obvious place to look is the Machine Information → “Firmware version: …” field, which shows the grblHAL core version/date (e.g. 20230917), and the docs use a screenshot with a different value (20260318) as the example. It’s easy to read that as “I’m still on old firmware,” even if the board is actually running the correct SLB image, because there’s no direct match between that number and the name of the file I just flashed.

Yes, $I exposes more detail (including BOARD and plugins), but you need to know what to look for and it’s not labeled in the same way the downloadable firmware is.

I totally get why you key behaviour and compatibility off the grblHAL semver/core version and not the BOARD string—that makes a lot of sense for support and for non‑Sienci boards. I just think there’s still room for a small UX/docs improvement that would save both users and support some time, for example:

  • In Machine Information, add a line like “SLB firmware package: SuperLongBoard_B5.0.5b” (or whatever metadata is appropriate), so users have a 1:1 label that matches the file they flashed, while keeping the core/semver field for your internal logic.

  • Or in the flashing docs, explicitly call out that the “Firmware version” field is the grblHAL core version and may not match the example screenshot, and that boards are shipping with the current release even if the date differs.

I was able to work through this myself, but only because I’m fairly comfortable digging into details and had time to experiment. A less technical customer might not get there on their own and would likely need to contact support. My sense is that small clarifications like this end up saving Sienci more time (and money) in the long run than they save any one user, so I offer this feedback in the spirit of helping reduce those future support loops.

1 Like
4

Thanks - firmware hex naming is probably something we could make more consistent for sure.

5

We’ve made changes to the firmware flashing page based on your feedback, to make it more clear on determining whether you need to upgrade. Let us know what you think!

Cheers

6

Excellent!!!

Thanks so much for acting on this so quickly – the changes to the firmware flashing page are much appreciated.

For folks running a full Sienci stack (LongMill, SLB, etc.), these tools and docs might only be needed occasionally. For those of us in the DIY camp, keeping older machines alive with Sienci hardware and software (gSender, gController, SuperLongBoard on a legacy X‑Carve in my case) depends heavily on this kind of detail and clarity.

Your willingness to listen, adjust, and explain not only improves the experience for customers like me, it also reduces confusion and future support load on your side. It’s a real win‑win.

Please keep up the great work – being able to modernize an existing machine with your ecosystem is exactly what’s kept my setup fresh and useful.

4 Likes