One quick release before the holiday break. I’ve included the patch notes for 1.3.9 (which was not officially posteD) and 1.3.10 here but as always you only need the latest version.
Hope everyone has a happy holiday season and I look forward to interacting with you all in the new year!
1.3.9
Improved initial job run estimation and during run time estimation
M0 pause now allows probing
Fixed issue with toolchange or M0 choking in some situations
Fixed issue where macro keybinds weren’t persisting
Reduced timeout on ethernet connection from 20 seconds to 4 seconds
Errors that don’t occur during job runs no longer hold the controller
Active modals displayed in diagnostics tool
Can now hold motors in diagnostic tool
Diagnostic report now sources errors/alarms from the correct new location
Removed outline on some elements that should not be occuring
Fixed issue with rotary jog movement being converted incorrectly when $13 enabled
Firmware categories for HAL should no longer display as null in some situations
Visualizer position should now always render final location frame when jogging or using go to buttons
Fixed issue where attempting to unlock the e-stop while estop still engaged would error the controller
Fixed issue with error occuring on HAL connection in some situations
Various Gamepad and keyboard shortcut fixes
1.3.10
Added option to enable/disable soft limits toggling rotary mode
Removed length and width input in probe tab settings
Updated rotary mode toggle, when not in rotary mode and are using grblHAL, you have access to all the tools in the rotary tab, including A-axis position reporting and jogging
Fixed issue with spindle delay option not applying if S command came before M command on a line
Several updates to job status UI and labels
Fix for firmware tool crashing on HAL in some situations
Tool change wizard no longer pops up when check mode is enabled
Fix issue with jog commands sent twice when tapping on jog buttons on the UI when using a touchscreen device
Fixed issue with the console not resizing properly in some situations
Updated machine firmware profiles, adding several BlueCarve options
Fixed issue with editing gamepad profile button labels not persisting
Rapid corner position should check homing sets machine 0 to determine which corner to move to
Sure I could but also every other user of a Vectric product that has a spindle would have to make the same edits to the post processor and would have to understand what changes need to be made to account for the way gSender processes the spindle speed/direction command. I’ve got a couple hundred gcode files now that would have to be reformatted to account for this.
It’s a simple regex update in the .js file to account for the formatting and a bit of error correction to make sure the dwell command isn’t doubled in case it already exists…
Just a quick look at the source code and I see this line in GblController.js (and also the HAL equivalent)
Would become gcode = gcode.replace(/(S[0-9]* M[3-4])|(S[0-9]*M[3-4])|(M[3-4] S[0-9]*)|(M[3-4]S[0-9]*)/g, '$& G4 P1');
All this does is include provisions for M & S commands to be in either order without a space. That still leaves the potential for duplicate G4 commands (Trying to cover all bases)
I understand. It’s hard to cover every user with software. I appreciate your effort in finding a solution too. An added note while I let you back to it, G4P1 should be a one second delay rather than a one millisecond delay. Are you seeing different?
It’s hard to tell honestly, it doesn’t seem like a delay at all but it could be one second. The movement of going to zero and spinning up all happens so fast. It’s not enough of a delay to let a 1/16” bit spin up to 24000 but that’s hard to work out for everyone what would be best without adding another parameter for users to set.
Too many VFD models to try to read the current spindle speed before moving so setting a known delay is about the only sane way to work it out. I’m up for testing anything out