The extra clicking does not bother me at all
Like when some program comes on tv that I don’t like, I just click to another channel
We all get complacent after doing the same ole same and that’s when mistakes are made
Our trucks bleep like crazy if we turn them off and leave the keys in…… how many times have we all still locked our keys in the truck…. Be honest now
Personally I would like to see a graphic representation of what you are doing that shows tool paths and progress in real time, I know other programs do this and if CM did it then it would be fantastic
I have used a number of GCode senders and they all have their good-bad points but I use CM cause it’s written for the machine by the machine makers
Just wish it had that graphical representation
Now I do find the estimated time to be way off
This makes me hesitant to start some jobs and I go back to laptop to check my file
When a 3D carve shows “ Under a minute “ I second guess if it has all of the code ??
People need to understand that they shouldn’t change the tool unless prompted if they have the BitSetter.
Possibilities:
People who understand this already don’t need the prompt.
People who don’t understand this currently will eventually understand this.
People will never understand this.
You’ve bucketed all people in the “People will never understand this” category.
This seems a harsh flip from the previous version where there was an assumption that everybody would understand it. Perhaps you should aim for a middle ground where you acknowledge those who understand what’s happening?
Forcing the bitsetter measurement routine at machine initialization obscures the complexity of the machine’s state.
As I am one of the stupid users who later learned, I can speak authoritatively…
The problem for a lot of noob users is that the machine forces them to run the bitsetter routine when it boots up. And then all CC jobs also force the routine at start.
I understand why (now) but users see all this measuring happen, and they are inconvenienced by the time it takes, and so they feel justified to think “OK, after all that, if I just do my part, I put in my tool and set the zero, everything has GOT to be all set up and ready”
Considering this it’s as if the only time the bitsetter routine should run is: 1) Intentional explicit tool changes such as mid-job programmed tool changes or 2) clicking the “set Z zero” button.
Running at initialization does nothing for the user except trick people who don’t know what’s going on (read: me 6 months ago) into thinking the machine knows best and everything is ready.
Now it feels like CM design is trying to discipline the users in place of empathy for how the Z-crash mistakes happen. To the point that we are training them to constantly anticipate and rapidly dismiss an error message without reading it or reading the buttons… which… yikes
It may take half a day to work out the kinks in adapting my particular workflows to UGS, but it sounds like that’s the most “correct” path in a number of ways for anyone graduating from the “People will never understand this” category in @Gerry 's outline above.
This seems to be a real workflow / usability issue.
I have a bitsetter, sitting on my desk in the house, never been plugged into the machine. Every time I think “I should plug my bitsetter in” I then remember all the problem threads and think “I’ll do it another day”. The time it costs me to slap the bitzero on the spoilboard zero spot and probe Z for the new cutter vs. the apparent grief in letting the bitsetter do it…
In my case I’m running jobs which are one tool at a time from Fusion 360 anyway so it just doesn’t seem to be a good trade up.
Here’s hoping that a sensible workflow can be arrived at that doesn’t involve 10 more dialog boxes that I have to click through each time I run a job.
If you’re doing files which only have a single tool then no, a BitSetter is not a good fit — if I’m doing more than one file which has a single tool I’ll disable mine.
