New guy making the announcement (and I’m late already), so be kind, ladies and gentlemen.
The elves at Sienci have been burning the midnight LEDs, taking care of the ever-decreasing list of bugs and necessary fixes. Version 1.0 is clearly visible on the horizon.
Here is the official list of fixes/improvments in 0.7.4:
Minimize render mode for visualizer to improve performance
Visualizer improvements to render speed
Fix render worker being started if visualizer disabled
Probe dimensions correctly update if changed in preferences
Can once again copy from console
Redesigned probe module
Fix for quick-movement buttons if home set to back-left
Fix for T commands on the same line as M6 commands
Fixed firmware tool values occasionally not reflecting actual EEPROM settings
Style changes
What are you having issues with? What would you like to see?
It’s from feedback from all of you that we can continue to make gSender (and by extension the LongMill) better and easier to use for everyone. If you’ve given us feedback before and you feel we haven’t yet addressed it, then post it again (maybe we misplaced your comment). We want to get to the point that everyone using it is happy with what it offers to them
Here is a link to the location of the installation files:
I installed 7.4 and there appears to be an issue with the return to zero command. X & Y are set to zero. I move X 10 inches so that I can set Z, I then set Z zero, raise it .120 and hit return to zero. The X axis travels Bach 10 inches to zero but Z remains at +.120. It did this 2 times in a row so I used UGS to complete my job.
Hi @JRich63,
I think two versions ago, the button changed from “Go XYZ0” to “Go XY0”
In my point of view, it’s good, since i often Zero from the SpoilBoard.
If i was to Hit the “Go XYZ0”, it would crash into the Material.
Of course, Your Workflow may differ.
I will have a look at that. For me that will be an small issue as I often hit return to zero and then reset zero before I run the gcode. If Z has not returned to zero everything will be off.
Seems version 0.7.4 is also now managing the M0 Commands coming from Carbide Create GCode Files (seen mostly on line 5).
I did not have to RESUME after START as it was before. (And then clearing the Information panel (Toast?))
Are the M0 Commands simply ignored, or is there any logic there?
USB on OSX 10.11.6 (most recent operating system that can run on this machine); ,lightweight mode with all options off - Goes to idle after about every 50 lines of gCode, pause and resume gets a few more lines done, repeat until end of job (not useable)
OSX 10.10.5 (not supported according to your posted system requirements): appears to work properly during my initial tests: Regular mode, with Force Minimal Renders enabled and screen sharing so I can watch the progress remotely
I found this note for USB sharing software VirtualHere Client: support for “OSX 10.9.5 / 10.10 / 10.12 / 10.13 / 10.14* / 10.15* / Not 11”, so the USB in OSX 10.11 may be problematic for some purposes.
The text “Lightweight mode” could be to the right of its switch so that it is pointed to when the switch is active. The present position was counter-intuitive for me
We ignore M0 within the first ~10 lines since a) that’s where carbide puts them and there’s generally not a good reason to have a program pause at the start of the program b) M0 after that point are probably genuine pause commands and should halt execution
They put them anywhere a toolchange command might be (if the generic Grbl post processor is selected). The first one will be within the first 10 lines, but the others won’t.
Are there plans for a GUI resume after the M0 pause? Is there one that I missed?
Are M1 pauses just intercepted and ignored?
The issue largely stems from the fact that Carbide uses M0 (pause) as a toolchange indicator rather than M6 (standard toolchange command). Since gSender is meant to handle standard g-code, we have to assume that M0 is meant to pause the program rather than act as a toolchange and act accordingly by pausing the workflow. The problem is we’ve had enough feedback from users using Carbide post-processed files that they’re frustrated that the job always pauses at the start that we had to add a workaround (ignoring early M0 commands).
Could you clarify what you mean by GUI resume on M0? The expected response to a M0/M1 pause is that the user would press the “Resume” button in workflow controls to continue sending the file.
What about outside the scope of running a job? I am testing toolchange macros which use M0 pause and the machine enters a hold state, but there is no way to resume/cycle start without sending a ~ or wiring a switch to the controller.
M1 does not cause a hold state. I just tested by sending through the console.
They should use a different post processor. I think it may become a management nightmare if you guys try to code around bad gcode. Someone may have a legit reason for an early M0 pause.
You’re right - it looks like M1 is pausing workflow during job run (sender) but not entering hold state during console/macro input (feeder). We’ll make this behaviour more consistent during a later build (M1 should also enter hold state if it’s in a macro/console input vs just inside a program).
I understand your point about the UI resume now - we’ll look at adding a more obvious way to unlock hold state on the UI without a job loaded.
