That’s effectively what it comes down to and we’re a little hesitant to change the focus policy of all keys in the jog pane because of the potential for unintended consequences. We’ll poke around more and see if there are any options to get us there in a less heavy-handed way.
3 Likes
Fair enough, thanks.
So finally I have joined the forum. I really wanted to get in here an voice my opinions on a couple of things I’m not too fond of with CM. Don’t get me wrong, I absolutely love CM and how user friendly it is and the overall layout of the software, but there’s some things I’d really like to and hope to see changed.
#1- (Touch Probe) Add the ability to calibrate touch probe dimensions for any possible inconsistencies.
#2- (Bit Setter) And this one I’ve mentioned to Luke and had a little conversation with Vince about. With the bit setter tab enabled it automatically comes front & center asking for you to load a tool after machine initialization. I don’t know about other people, but sometimes I like to power on my machine and jog it around just to check on everything and see if all is working properly. Also I as well as maybe others may rapid to the center or front of the machine after the job is done to remove the bit and then power the machine down. So the next time I walk up to my machine I may just want to power it up, initialize it and have it stay in the back right corner while I load material onto the bed, but unfortunately with the bit setter enabled that’s not the case as it’s going to immediately come up front after you initialize it. At that point you can’t cancel out of it which is really annoying. I feel there should just be a tab up top where the RUN, JOG, MDI, and SETTINGS tabs are that say’s LOAD TOOL or TOOL CHANGE when you are ready to start a job. Makes more sense I think anyways. Hopefully you understand what I’m saying.
#3 (OPEN LOG) I noticed on this version 509 when I click “open log” there’s no way to stop or pause and review anything. I sent a $$ command and absolutely nothing showed up in the log for GRBL settings.
Just a couple things I wanted to put my 2 cents in on. Other than that I love CM. I wouldn’t want to use any other sender software because CM is just so user friendly in my opinion.
I had mentioned the second issue here in another thread, I think it should not go to the middle to change bits until you are ready to start the job. I also think that one needs to be able to check clearances, install the workpiece and get prepared before the spindle comes to the front. When you start the Shapeoko, it is impossible to jog the spindle until you home the machine but it should not be forcing you to insert a bit and go to the BitSetter before you can start jogging.
I’m not sure we’re ready to add a lot of configuration options right now.
The MDI screen is due for some improvements and once that’s done we’ll share the probing codes so you can have your own preset probing routines with custom values ready to go there.
With BitSetter, or the Nomad for that matter, we depend on having a valid tool offset all the time so if the machine has been off we assume that it’s changed and the tool needs to be checked again. This is both a safety issue and a potential for a lot of support problems so this behavior is not going to change for the foreseeable future.
I know there are a lot of workflows that people can come up with as a compromise. We understand them and we’re not going to implement them. This comes off much more harshly than I intend but I want to be very clear about this behavior in particular so that nobody is under the impression that we’re flexible on the topic. (My wife accuses me of hedging everything so at least she’d be happy about me being definitive on this one.)
You should try 511. The “Ignore Status Updates” option should be a win for you.
We appreciate that and welcome to the forum. Hopefully, CM will get a lot better in the near future.
4 Likes
[quote=“robgrz, post:65, topic:20279”]
With BitSetter, or the Nomad for that matter, we depend on having a valid tool offset all the time so if the machine has been off we assume that it’s changed and the tool needs to be checked again. This is both a safety issue and a potential for a lot of support problems so this behavior is not going to change for the foreseeable future.I know there are a lot of workflows that people can come up with as a compromise. We understand them and we’re not going to implement them. This comes off much more harshly than I intend but I want to be very clear about this behavior in particular so that nobody is under the impression that we’re flexible on the topic. (My wife accuses me of hedging everything so at least she’d be happy about me being definitive on this one.)
No-one said that this behavior or system function should not happen, we just want a pause where we can do our setup before having to install a bit. Once the machine is homed and we have done our setup, we would press a button to continue from that point, the spindle would come to the front and ask to install the bit then go to the BitSetter. I don’t see how it would compromise anything safety or otherwise.
3 Likes
I understand the need to always know how long the bit is; the process is already a bit fragile with humans just changing the bit without telling the tools
my “issue” is not so much that it measures the bit, but that at the end of the cycle, the router is exactly in the worst place for me to put work down/etc/etc…
current process
- initialize machine button
- machine homes
- machine asks for bit
- machine moves to bitsetter and measures
- machine moves back to the place for bit change
I think a reasonable other option is move to the middle-back rapid position, rather than super in front.
that way the space over the work area is vacated again for me to put my work down, do clamps etc etc… the “middle front” is somewhat arbitrary in a sense, and “middle back” is lot less intrusive in terms of being able to put the work on the wasteboard
1 Like
I agree it’s, unnerving at best to have the first thing be home, then tool change. But… And this is a Kardashian sized but, that’s the price you pay for reliable software that “just works” each time. I’m sure @robgrz could give us a little more detail but my understanding is dealing with the work offsets needs to be done in a robust and repeatable manner.
I typically just give it the good Ole ‘NE’ in the rapid window as soon as the tool change is done. Perhaps we might have more luck trying to convince Rob to add a home button on the main screen. Or failing that a button that will rapid z 0, then rapid to the ‘NE’ position.
6 Likes
I’m definitely not trying to create any kind of argument on the topic of the bit setter, but I’m just trying to wrap my head around why it needs to check the first tool length immediately after initializing. From my understanding it just needs to know the first tool length before you run a job. So by having a separate tab for “load new tool” would allow you to load a tool, measure its length, go zero your XYZ, and then load your file & run the job. Also why I feel this is beneficial is because maybe all I wanna do it some diamond engraving and I don’t want to use the bit setter since the bit is spring loaded.
I went through a similar thought process (I even went so far as to make a “poor man’s bitsetter” just to try out the workflow), and I think it boils down to “consistently handling gcode no matter where it comes from.” In my personal ideal world, the software would examine the loaded gcode to see if there is more than one toolchange command and only do the thing in that case - which would (I think) be fine when the gcode came from CC or a well-formed post-processor.
But what if it doesn’t? Suppose the gcode only has one toolchange command but uses two tools (depending on “whatever you’ve got in the machine” for the first one), or something like that? I have to imagine that folks sat there and thought about all the ways that things could go wrong like that, and this is how they address them. (I will note that anything which requires a separate user interaction - like a “load new tool” tab - is a potential support nightmare, for when people absolutely do not do it. 
)
Your diamond drag bit example is one that I share - I also have other cases where I’d like to not go through a “process” just to run a single-tool setup. In the end, I just concluded that this is not a product for me, which is fine - not everything has to be.
2 Likes
I have yet to actually run a job with the bit setter I have because I’ve been busy doing other upgrades to my XXL, but I’m fully aware of how it works and it’s work flow. I’m close to being finished with my upgrades and get back to cutting again, but with that being said I think I might just sell my bit setter. I’m not really fond of having to enable or disable it anytime I run a job that doesn’t need it because if I’m not mistaken if I disable the bit setter I’m going to have to go through the entire process of moving the center point XY coordinates of my spindle over the bit setter again, enable the bit setter, and then click “use current XY position”. It’s a hassle. Probably just going to go back to the old school way of doing things by either using machine bed as my Z zero or setting up every tool with stop collars at a predetermined length.
We just uploaded 512 to:
https://carbide3d.com/carbidemotion/beta/
Not a lot of big changes, just cleanup:
- (FIX) Update file info when changing UI units
- (FIX) Small settings dialog update for Nomad users
- (FIX) Transition from Jog to MDI
- (NEW) File not cleared on settings change if not required
- (NEW) Added “.tap” as an option for code files
1 Like
So I have bad news and good news about 512
the bad news is that I had the “the machine keeps moving even though I let the keys go” happen again
the good news is that I think I have enough information to help get this fixed; this time it happened while I was using a normal mouse to drive the GUI, not some wireless keyboard.
In the jog screen, I had it set to move 1mm at a time, and I was using the mouse to click the Z+ button to move the spindle up right after I zeroed, in order to put the dustboot on.
After a few clicks, a modal dialog box popped up with a GRBL error that that the machine was busy while a command was sent. BUT, and this is the key thing, I could see that the “Z+” button below on the jog screen behind the modal dialog was still looking pressed… and the machine kept moving up.
Only after I (quickly but still several seconds) closed the dialog and clicked on Z+ button again once did the machine stop moving and did the Z+ button look de-pressed
So it seems that the modal dialog box stole the “depress” event away from the Z+ button or something, and it stayed pressed and kept moving the Z axis…
(not wanting to go into solution space too much but likely if a modal grbl dialog pops up the jog screen should consider all UI elements as no longer pressed or something)
4 Likes
My machine did the same twice last night.
Once when in x-y zero position was setting z zero and after releasing the mouse button, the z axis kept jogging down and motor skipping. I let it go a few seconds to see if it would self correct, it will not. After shutting the machine off and restarting, during the initialize machine process, the machine went to the back right corner and then started the z axis descending again until I killed power and restarted again. The reboot of the machine did not correct the issue, The solution was to close Carbide Motion and restart that program, then things worked as they should again. Makes it look as the problem is in Carbide Motion and not the control module.
1 Like
Can’t hurt to ask:
@robgrz, you said that the code now exists in CM to turn off the dialogs that wait for the user to turn the router on and off at the start of a job, and that it just needs enabled in settings. Any plans to implement that very soon? I’m itching to use the newest version of CM, but I’m running hundreds of parts & these dialogs slow me down.
I’m liking changes made so far, how about making rapid jog adjustable for dust boot ears. HDZ with sucket dust boot or PWN dust boot.
build 512 also loses the location of the bit setter if you turn it off and later back on (I need that for my surfacing bit, the 1" bit is not compatible with bitsetter).
it has the coordinates on the screen until you enable the bitsetter again… it them somehow resets them to 0, 0 basically the homing position
2 Likes
That will be changed in 513
We’ll try to get that in 513 for release later today.
EDIT: I’m probably going to heavily prune this thread later today to get it back on topic, which is the CM betas.
5 Likes
any chance to get that “the machine keeps moving even if the user let go” bug fixed in 513 as well ?
We’re looking into that now. We’ll get something added and then see how it works in the field. I suspect this will take a combination of fixes to get all of the edge cases taken care of.
2 Likes