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
