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?
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.
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.
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
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.
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.
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.
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.
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.