gSender Edge 1.2.3

Hey guys,

We have a new edge release with a bunch of new features and improvements that you’ll be excited about!

There are a few more changes we would like to get out in the near future, but for now, we want to show off what we’ve been working on so far.

Big Features

1.2.3-EDGE Patch Notes

  • Updated out of date packages and dependencies
  • Various fixes and improvements to keyboard and gamepad shortcuts
  • Added category filter for shortcuts for quickly finding ones needed
  • Added new shortcuts
    • Open Probe
    • Probe Routine Scrolling
    • Cycle through visualizer camera angles
    • Visualizer zoom in/out of current camera angle
    • Visualizer zoom to fit loaded g-code
  • Fixed laser offset not allowing negative values
  • Fixed macros not being available as a keyboard/gamepad shortcut
  • Re-design of start from line popup
  • Remote mode is now more mobile responsive
  • Various UI updates and label renaming in Preferences and Surfacing
  • Re-ordered tools within Diagnostics
  • Fixed issue with CORS on remote mode
  • Fix for auto-updates on Linux
  • Fixed settings exports failing
  • Re-ordered feed-rate and spindle override buttons
  • Added feature for anonymously collecting basic app data within gSender, at the users consent
  • UI improvements to tool-change wizard

1.2.2-EDGE Patch Notes

New Features

  • New UI for configuring remote mode
  • Added new Wizard UI for tool-change
  • Support for gSender running on Firefox when in remote mode
  • Tool-path in the visualizer is now a different style when laser mode is on.
  • Can now customize laser mode color in the theme settings
  • Added pause option to surfacing for adding a delay of 4 seconds after any spindle command
  • Added job recovery functionality in instances where your machine disconnects from gSender

Improvements and Fixes

  • Improvements to G0 movement line visibility in the visualizer
  • Improvements to the job statistics chart in preferences
  • Improvements to the calibration tool
  • Visualization improvements to prevent lagging in some instances
  • Fixed app crashing for users who don’t have WebGL installed or are misconfigured
  • Codebase cleanup, removed unused files, components, and packages
  • Various UI bug fixes
  • Fixed bug with “Go to XY” shortcut not including safe Z height
  • Fixed styling for job override sliders
  • Fixed issue with continuous jogging when soft limits are enabled

Tried 1.2.2 and had trouble using/setting up MS Gamepad. Anybody else?

Toolchange wizard on Mac/Longmill 30x30 not working for me, can’t figure it out. both manual and semi-automatic attempted. Says running Gcode and I can’t go past first or second step. What Gcode is it trying to run? Nowhere to confirm operation. What happened to the custom code option?

Update #1: now working on manual after quitting and starting over. maybe aborting the semi-automatic left it confused…

Update #2: aborted job, then tried starting it again to see how tool change responded. After just the first step of tool change, the wizard goes away, and resume button is active

Update #3: Quit and started again, now I can’t even load a file Shutting down completely.

Had some features I wanted, but tool change is too inconsistent & unreliable. The custom code I used with v.1.1.7 is much preferable

I had gSender.Edge-1.2.1-EDGE-armv7l.AppImage on my pi4 and was able to remote in using Chrome. Saw this version supported Firefox, so downloaded the new appimage. No matter what I do, this still launches as 1.2.1 (displays in the header, no new features present, Firefox does not work). I deleted the prior appimages (1.2.1 and 1.2.2), re-downloaded the new 1.2.2, restarted, etc. Launching from CLI and GUI gives the same. The about section all says 1.2.1.

My assumption is maybe the arm file did not actually get updated to 1.2.2? Or am I missing something else I need to update?

Thank for the help!

1 Like

Hey all - pinging this one again. @KGN @walid_kayhan can you validate the arm version of 1.2.2 is correct. I tried again on a fresh Raspberry Pi OS install and it installed as 1.2.1.

We’ll look to have a new binary up today or tomorrow, it looks like the wrong tag got cloned during the build process :+1:

1 Like

Thank you @KGN - looking forward to testing that.

Next question - should gSender-Edge-1.2.2-EDGE-arm64.AppImage run on Raspberry Pi OS 64b?

I have a Raspberry Pi 4 Model B Rev 1.2 BCM2711 and I reinstalled with RPi OS 64b to see if I could get that version to work. The arm64.AppImage creates a “gSender” folder and some files in the .config folder and the gSender splash screen launches, but the program never becomes active.

I also tried the arm7l version, but it does not launch at all on the 64b OS. (I thought 64b OSs would generally run 32b programs, but maybe the RPi OS 64b needs something else I am not aware of.)

We don’t have a 64 bit PI environment at the moment since Bullseye is still a relatively new offering and a low portion of Pis in general. We compile only for the ARM7L architecture.

You can take a look at the application logs and see if there’s a specific error being logged as to why it hangs on splash screen.

1 Like

Following up on this - binaries have been updated with the correct tag version, both in appImage and .deb.

1 Like

Greetings - new gSender user here - my primary sending computer is an older Linux machine running Debian Bullseye.

osh@DebSender:~$ hostnamectl
   Static hostname: DebSender
  Operating System: Debian GNU/Linux 11 (bullseye)
            Kernel: Linux 5.10.0-20-amd64
      Architecture: x86-64

I can confirm that version 1.1.7 seems to work just fine.
With Edge 1.2.2, I can load one GCODE file, and test it, but if I close and attempt to open another, the application seems to die. I can quit and restart the application OK.

This is installed from the .deb file from December 9th: gSender_1.2.2-EDGE_arm64.deb




The Mac ARM EDGE gSender App bundle within the Mac ARM DMG from December 9th is damaged and won’t launch.

The Intel version seems to work fine.

Greetings All - Sorry for the 3 separate message replies, but assumed in a thread like this, it might be easier to catch replies separately.

I’m a new user of gSender, with the bulk of my previous sender experience with OpenBuilds CONTROL. I often do an initial check of my GCODE on my Macintosh, which is my development machine, and not the machine that I use with my BlackBox controller. OpenBuilds Control allows me to load in my GRBL configuration and run a job simulation (similar to the gSender Test Run). I’m curious if gSender does (or could) support this sort of disconnected Test Run/Simulation.



Hi, the ARM build is Linux ARM, not Mac ARM. We do not currently build for ARM Mac on any version.

Test Run uses a built-in firmware feature called Check Mode that validates GCode without moving the motors. As such, it’s not possible for us to do it without being connected to the firmware itself.

I’m unfamiliar with the feature in OpenBuilds, but if it’s not using the $C flag the behaviour is likely different.

1 Like

I’ve tried my hand at making a g-code sender in C and Rust (separate projects). I used the $C to check the code as well. I don’t know if this is applicable to gSender or how much work it would be if it is, but I had to basically write a g-code parser/validator from scratch in order to display a preview. So if I had/wanted to add an offline check that’s the code I would start with.

Anyway just a thought, I know nothing about how gSender is built except that it’s in JavaScript and I don’t know JavaScript… yet.

Yeah, writing a parser and validator is the alternative option without using Firmware - it’s just not something we’ve explored since we’re happy with using the $C option for the time being.

1 Like

Perhaps the OpenBuilds team did write their own parser/validator. It’s a nice feature, but the other nice features of sSender outweighs that feature for me.

Thanks for the info.


Turns out – whether intentional or not, you’ve got a nearly functional Mac arm build out on GitHub.

But the issue was just code-signing:

Executable=/Users/osh/Downloads/gSender Edge
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20400 size=513 flags=0x20002(adhoc,linker-signed) hashes=13+0 location=embedded
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

From what I understand, it’s a mismatch between signing the binary and signing the App bundle. But with a little work to re-sign it as adhoc and then stripping off the the quarantine bit with xattr it was good to go!

Here’s a screen shot of the Mac Activity viewer showing gSender Edge running as type “Apple” which is native Arm, not translated Intel.

Very Cool!