2.1.5 Override manager dialogue

[bLouChip]

constructive feedback...

• the new dialogue footprint is significantly larger than the old style version, which makes it less convenient to keep visible having to share it as tab in another window frame. I use overrides with enough frequency that this UI is less desirable, IMHO.
• the toggle buttons Spindle, Mist, and Flood don't consistently change color shade to show state. Running on Win 11. Also, I really liked the v2.1.4 old style where the buttons changed from red to green to show state. That was very nice.
• I'm missing Rapid feed scale. running grbl v1.1i. it worked in previous ugs ver so it shouldn't be excluded as an unsupported feature in the new override manager logic.

[breiler]

Sorry for the late reply and thanks for the feedback!

the new dialogue footprint is significantly larger than the old style version, which makes it less convenient to keep visible having to share it as tab in another window frame. I use overrides with enough frequency that this UI is less desirable, IMHO.

Yeah it requires a bit more space, I'll see if I can shrink it down a bit. Do you mind sharing a screen shot so that I can see the layout you are using?

the toggle buttons Spindle, Mist, and Flood don't consistently change color shade to show state. Running on Win 11. Also, I really liked the v2.1.4 old style where the buttons changed from red to green to show state. That was very nice.

I am not able to reproduce this problem, they consistently change state in the same way as before. I'll see if I can add another color to better signal if the feature is active.

I'm missing Rapid feed scale. running grbl v1.1i. it worked in previous ugs ver so it shouldn't be excluded as an unsupported feature in the new override manager logic.

The old features were practically hard coded for how GRBL deals with overrides. With the latest work I was trying to make an abstraction layer that could work for other controllers such as g2Core. Unfortunately the rapid rate overrides worked completely different than the feed/spindle overrides and was more difficult to implement.

When looking at a couple of other senders I decided that the rapid rates overrides could wait. Have you ever used the rapid overrides?

[bLouChip]

re. use of Rapid Override - yes, I use it on occasion, usual use case is diagnosing or testing a setup condition. My CNC serves 3 cutting processes (tri-CAM); milling, plasma, and laser. The max XY speeds for the machine electronics vs. mechanical load is 16,000mm/m, however this is only useful when raster scanning during low load cutting with laser and 3D carving of shallow passes due to mechanical resonance in my beefy machine. Most all other cutting processes are either higher load (milling) or are very sensitive to mechanical resonance (laser non-raster and plasma) so I have to dial down the max XY speed to 8,000mm/m, as well as change acceleration; btw-, UGS makes it easy for me to do this via Machine->Firmware Settings->Import menu, I only import the $nn settings that I need to change, so a I keep 2 .settings files readily available for this purpose, one is Fast Max Spd+Accel, the other is Slow.... Sometimes a Rapid Override can help me fine tune a specific table fixture setup or situation in addition to these adjustments.

re. Spindle, Mist, and Flood buttons in 2.1.5- Since the override commands don't post to the console log anymore (sorry, another undesired changed IMHO) and the button shades of color don't always change, I don't know the override state at times unless I take other measures like checking the DRO or #G. They may always toggle state, but I'm not getting that visual feedback and often times I'm testing or "dry running" a gcode job in my office on a grbl board with no physical machine attached.

There are many use cases for UGS, and perhaps I'm an outlier :( But I love it more than the competition.
Thanks for looking into this and making a great shared product.

btw- Run From... feature is awesome, I use it often in plasma cutting where the probability of a torch collision with tipped up metal cutout parts is fairly high, there is never enough physical Z retract clearance height that I can program it seems (not a UGS issue). UGS does an excellent job of back-scanning the gcode to get the modal conditions in the correct state depending on the starting point in the file. Also, I run in G90 absolute mode when plasma cutting, and that gives me confidence that the coordinates are going to be correct.

[breiler]

I have made some adjustments to the dialog, adding the rapid speeds back. I have also adjusted so that it the window can become much more compact. It is available in the latest nightly build.

#2489

[Monberg75]

How does this work?

Fusion (free version) set the rapid movement rate as the same as feed rate, Then it would be nice to be able to override the rapid movement with something faster, but I can't set it higher than 100% is that 100% of normal, or is it the same as normal. Maybe it would be possible to set it to like 150% og maybe up to 200% in future, so that we would have the 'correct' behaviour of the machine making jobs faster?

[breiler]

The "free for hobbiest" version of Fusion does not use rapid movement commands. So there is nothing that can be overridden.

Normally CAM programs generate rapid commands (G0) for non cutting operations. This will try to move the machine at the max speed (configured with $110-$112 in GRBL). The default override value for rapids is 100%, which means that it will move at the max speed and the machine should not be able to move faster than that.

If you want your jobs to go faster, you unfortunately need to buy a license for Fusion or switch to another CAD/CAM package.

[Monberg75]

Thank you very much for clarifying. I didn't know it was like that. I'll live with it as is. :) søn. 9. jun. 2024 07.10 skrev Joacim Breiler ***@***.***>:

…

The "free for hobbiest" version of Fusion does not use rapid movement commands. So there is nothing that can be overridden. Normally CAM programs generate rapid commands (G0) for non cutting operations. This will try to move the machine at the max speed (configured with $110-$112 in GRBL). The default override value for rapids is 100%, which means that it will move at the max speed and the machine should not be able to move faster than that. If you want your jobs to go faster, you unfortunately need to buy a license for Fusion or switch to another CAD/CAM package. — Reply to this email directly, view it on GitHub <#2468 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFLYUNI664YITKNZIWRYIZDZGPPTDAVCNFSM6AAAAABDOJLNR2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TOMJXGQZTQ> . You are receiving this because you commented.Message ID: <winder/Universal-G-Code-Sender/repo-discussions/2468/comments/9717438@ github.com>

[bLouChip]

@breiler , after several months of using the new Overrides window/layout with sliders, I'm finding it less practical than the previous layout at v2.1.4 and earlier. There are two nagging issues that I have with the new layout

1. it takes up too much precious screen real-estate
2. it hard to make 'on the fly' adjustments which I desire to do often. Rather, what I'm forced to do given the new slider UI, I have to wait until my CNC is not cutting (plasma process) and in motion between shape cuts, then Pause the machine, then adjust Override sliders. The Pause is necessary due to the precise UI/mouse motion needed to adjust the sliders. In the previous Override UI, I could easily adjust 'on the fly' while cutting because its a simple button click to increment 10%, decrement 10%, and reset to 100%.

Is there any consideration being given to regressing the Override UI ? Any feedback from other users one way or the other ?

[breiler]

Thanks for the feedback, again. =)

I would like to know a bit more about your first issue on how it is taking up to much space. Can you post a screen shot of how you are using it today?

The only feedback I have seen so far about these changes have been positive (except for the issues that you have brought up).

It should be possible to add an option with alternative UI with buttons instead of sliders if they aren't exact enough for some people.

I can also mention that there are actions in the menu for changing the overrides which can be mapped to shortcuts until there are buttons for this in place:

[bLouChip]

well dang, I didn't know there were menu actions available ! That solves the problem, I'd rather have a keyboard assignment anyway ! I like to keep my eyes on the cutting process as much as possible. No need to consider a change, cancel my request. thank you.