I just replaced my tablet that’s been running my machine for years. I downloaded the latest CM version and after setting up the machine, I was shocked to find that it moved to the front right after initializing. Effectively sweeping everything I had sitting on the table onto the floor. Including my new unopened HDZ box that I’m supposed to install this weekend.
Only after this did I start googling and found out this is the new normal and is not user settable behavior. I get that this may make sense for newer machines and for workflows with a bitsetter. But I don’t have a bittsetter. I have no desire for the machine to ever go into that front right corner. All my bit changes are done in the front left. And only when I want them to happen. I configured my workspace layout around this workflow. And I also don’t want the machine to move from its top right initialize position until I’m ready to run a job. Initialize isn’t the point where i want to prep the router. That’s after I load stock onto the table and load a job. But I still think this should be an extra intentional step commanded directly by the user.
I always turn on my machine and initialize before even loading stock onto the table. Having the gantry move to the front after initialization gives me an extra step to move it out of the way before i prep the stock.
It seems like it would be a quick and easy addition to add a checkbox in the settings screen to disable this behavior. Or even better allow for a user specified location. Then for the common workflows you’re designing for, it could just command that it go to this new spot when you start the job. If the machine is already there, no time is wasted.
In the meantime I’m going to try to figure out which version to go back to that doesn’t have this behavior. Not trying to complain. Just explaining my workflow and suggesting what should be a fairly easy addition for user flexibility.
If you really want your machine to operate in a particular way, I would suggest looking at other g-code sender softwares like gsender, UGS, etc.
C3D may implement more optional parameters in the future(who knows?), but their design philosphy with CM revolves around keeping things simple with as few buttons & optional parameters as possible. And it works. It may not be the most efficient workflow nor everyone’s preferred workflow, but it keeps users from making inadvertent mistakes when operating their machine for the most part.
I, for one, would love CM to have a Geek-Out-UI switch that exposes a plethora of optional parameters & advanced behaviors for CM - but I highly doubt C3D intends to take it there becuase other softwares already exist to do so. And if they did it themselves, then they have to provide support for it.
I get it. C3D is trying to be simple and straightforward for beginners. Just suggesting simple things that aren’t a hard lift. If this were open source, I’d probably have made the change myself in under and hour and submitted it.
I’d like to stay with CM as it has the cleanest UI and has the built-in settings that are known to work best with the machine. I wouldn’t even know where to begin to extract configuration settings to apply them to a 3rd party sender. Plus it’s easier to get help when something goes wrong. Some of the other options are likely more feature rich, but are a little lacking in the UI department. I may play around with them though.
Even if it won’t happen, it’s good to voice the concern here. I know the devs listen and make decisions based on user feedback and support volume.
Another less complex option would be to add another parameter switch in the shapeoko.json file right after the Bitsetter parameter switches such as: “init front move”: false,.
Obviously that would require some CM code change, but no UI changes. Then those of us with slight technical skills could edit the json file the way we desire. Of course that would probably open a flood of requests for additional similar changes and Rob might not like that.
Just my 2-cents.
Regards,
Allen
I’m listening…
Our general philosophy is that there is a fixed number of settings or options that we can surface before it looks like a Soviet missile control panel. That’s why we’ve been trying to move more settings, etc., into the Setup Wizard, so we have more space for the fun stuff.
I think Motion will get a development push in the near future, so we’ll keep this in mind.
I’m not opposed to this idea, so long settings like this are easily enough discovered and documented. I never knew there was a json file until you mentioned it. Upon inspection, it looks like it’s just the place to store the underlying data for the existing UI options. So it feels like a logical place to put it. Like you said, it wouldn’t necessarily need a UI object to set it. But I bet that that file is just the serialized output of the UI object state. So it’s likely easier to add the UI option and keep in the same code pattern.
The problem with switching to a new GCODE sender is that you then either have to buy CC PRO, or move to a completely different CAD program. CM is the only sender that works with CC free version.
You shouldn’t apologize…I was thinking the exact same thing! 
Even without the hyperbole, this is our (Siemens) controller. Most operators use 10-20% of it’s functionality. The Germans don’t get quite as carried away as the Soviets 
Well…you can also have problems going the other way…we had a Sony radio/alarm (remember those?) that had three buttons…just three buttons - and about 100 functions you could perform by pressing those three buttons in the correct sequence and length of time. Not particularly usable either.
Finding the balance is the key.
I agree, @Tod1d, you wouldn’t want to run a Shapeoko with that controller… 
In days of old Soviet Union, the East Germans did in many cases…
At present, is the Jog screen separate from the Rapid Motion screen? Maybe there is some efficiency gained by combining those screens since they are motion-related?
I would say you can also add the Zeroing screen to that, since Jogging and Zeroing are related, but please don’t accuse me of being a Communist.
You’re right- we could definitely make a Great Leap Forward on the jogging. One of the plans we’ve had is to eliminate the onscreen jogging if you have a jog pendant, and just have a single set zero / rapid position screen. It’s on the to-do list.
Jog screen is great as far as I’m concerned. Clean, straight forward, to the point. Has everything and only what is necessary. My Rii and the jog screen accomplish exactly what I need.
Then again it’s the only workflow I’ve ever known, soooo…
I Just made a post on similar topic but Ill chime in here as well. Using my Stream Deck really is only useful in the jogging. If Hot Keys were assigned to the functions it would be helpful for the DIY guys making use of devices to bridge this gap.
I do really like the idea of a single page consolidation.
Totally agree on the consolidation of the 3 related pages. Jog, Rapids, and Zeroing would all work well on a single page. With assignable hotkeys for each. It would also be handy to have a few user preset buttons there as well.
I think it would be nice to have the jog screen persistent. That way of you have a rii or similar, it’s the same. Put me in the camp for all 3 in one screen. Even a small tablet has the screen room.
If we’re here voicing requests, along side these changes I would love to be able to change the spindle speed dynamically during program run. I utilize the feedrate changes all the time, but find myself wishing the same for the spindle as I learn to dial in F&S.
OK, I’ll voice another one. Besides the first item above to add a switch to the Settings menu UI to switch off the initialization move to front right corner, would also be nice to have access to travelX and travelY setting on the Settings Menu.
So that those of us that have attachments, like lasers, can adjust the jog limit movements for safety to avoid crashing the attachment into the left rail accidentally (rather than manually editing the shapeoko.json file everytime) just as an added safety feature.
Or enable the ability in a QuickAction to modify travelX parameter in the “Do Laser” macro.
Regards,
Allen