I know I had a thread previously for this but this world is all about learning and I quickly discovered that combining a post on issues as well as suggestions quickly became mostly issues which I feel are better left to the release threads.
As we’re slowly working our way towards a stable release of gSender, me and the team are trying to make considerations as to what remaining features we want to fit into the first stable version, and then what to prioritize afterwards.
Using voting, I hope this will be a good central location to summarize the feedback that I’m seeing from everyone in addition to features that I myself have come up.
gSender Wish list
Improved handling of reliability & slowness (Lightweight mode)
In-app counter that informs you on hours of machine operation (actual running jobs) to help time upkeep, maintenance, and just for fun
Jogging on machine pause (e.g. for tool changing)
Highly accurate time estimation
Ability to reload the same file if it’s being iterated on
Headless Pi operation
“First Run” / Configuration Wizard
Beginner mode: checks up on you and walks you through things
Make visible all currently active modal states
Surface / heightmap probing tool
Advanced probing tool for centre-finding, hole probing, etc.
Code splitting feature
G-code realignment
Job arraying
Job management / scheduling
G-code editor
Pendant
Full 3D cutting visualization
0voters
Please vote if you see anything here that you’d like to see implemented. Also, please reply in this thread if you have other ideas that aren’t mentioned or would like to add onto the ideas currently posted
I’ll add in a picture of the previous poll results:
I personally would like to see a little description for each line just so that I know what I’m voting on some of them are clear as day other or not so much
And I’d like to be able to vote on multiple of these items maybe a sign a number I mean it’s I understand it’s a pole but there’s a few of that I really really want
That would be the ability to rotate to move around your imported g-code in relation to its starting point. This is handy if, for instance, you set your material size incorrectly when you make the g-code in CAM, because then you can tweak the starting point in gSender
I’m looking for it in calibration only . Calibration is not somthing you use daily , so I’m willing to go slow when calibtatin the machine. The same speed as I have for precise in the jogger for using the touch plate.
PS . my calibration is only 1.1mm of f.
Hi Saskia, yes I still have our other conversation open here to keep it at the top of my mind: Redirecting...
I have yet to understand still your situation, alongside another gentleman’s situation of gSender lagging behind quite significantly for them: Redirecting...
The commonality is not having an adequate testing option, as well as not hearing about these issues anywhere else yet. Thanks for posting here as well though, sometimes I can forget these things
Note my recent remarks under 0.74 build. No change, but I find it appears to be OK under OSX 10.10.5 on the same machine. OSX 10.11 is your stated minimum. I wiped the machine clean and did fresh installs of 10.10.5 and 10.11.6 for latest tests. So add to Wishlist: support for Mac OSX 10.10
@saskia , one thing I can’t recall about your situation, did you say you were connecting to the machine just fine with another g-code sender but then with gSender it wasn’t working?
With my MacBook Pro, everything is OK with gSender or UGS, but it is a fast machine with a more recent operating system. With the 2008 iMac8,1, neither software worked properly under OSX 10.11. A few days ago, I did clean installs on two bootable partitions and found that gSender actually works with OSX 10.10, but still not with 10.11. Today I bought a unpowered USB hub and put it between the iMac and the longboard and finally gSender works under 10.11. The intermediary solves the communication problem with 10.11. No longer does gSender keep reverting to idle after 50 or so lines of Gcode. Likely UGS is now also useable, but gSender is much nicer.
Be able to adjust speed of visualisation of Test Run and run forwards and backwards though particular sections. The Test Run function seems to run at 20x normal speed, and is over before I can blink and see what it is doing.
Be able to use the Test Run to get to a particular part of your GCode, instead of guessing which line it is to start from.
Sounds good Trevor. There’s a lot of how ‘test run’ works that’s tied into GRBL so we’ll be looking to see if it’s even possible to change but if we can I can see how it would be helpful
