CM feature request: production workflows

Hi CM team, I’ve been using my Shapeoko 3 for production and prototyping for a few weeks now and have been very impressed with the machine. I can share more about that in another thread. For this thread, I wanted to share my use case and some feature ideas.

In my use case, I am cutting both tooling and doing trim-offs of a production part in a four-cavity configuration. I’ve divided the work area into four sections, each with their own local coordinate system. I’ve cut dowel pin holes to locate tooling precisely and repeatably at each location. Here’s a quick pick to give you the idea:

Each cavity is interchangeable, so I can put a variety of different parts in the machine (high mix production) and simply move the local offsets to each known position to do the work needed.

What this means is that I’m jogging around the work area and resetting zeroes regularly. I do this by doing a rapid to the local offset and using G0 commands in MDI. This is an error prone process that requires multiple context switches in CM. First I relocate the cutter to the local offset. I wait for the spindle to arrive, because closing the Jog context too quickly will stop the rapid movement prematurely. I then close out of the rapid menu, then the Jog context, and open MDI. I enter my G0 offset and switch back to Jog, where I reset the X or Y zero and am ready to begin cutting. I then context switch to Load, find my file, and context switch again to the Run context. After double checking the my cutter is at (0,0) I am ready to beg cutting. A number of errors are possible in this process, which I’m happy to enumerate if it would be helpful.

Today the CM interface works well for simple use cases and is clearly optimized for accessibility. While I know that my use case may not be one you are interested in specifically supporting, optimizing for a more pro workflow may help smooth what today is sometimes a clumsy (though beautiful) UI. I’ve got some ideas, hopefully some of which seem really simple:

  1. Allow the enter/return key to close out of the UI context (like pressing the “done” button). This would allow much faster context switching and would cut out about 50% of the mouse work I currently do.
  2. Allow me to turn off the tool switch popup after clicking run. It was a useful double check when I was starting out, but if I’m working quickly I’d like the machine to actually run when I click run.
  3. Allow direct editing of the G54 offset. This would mean I don’t need to jog to a local offset and then MDI - I would just change the numbers to the new position.
  4. Along the same lines (but less important), supporting multiple offsets such as G55, G56, etc. would be helpful because I could gang multiple programs more flexibly - more automation would be possible.
  5. Allow quick MDI presets (ala UGS) so I can pre-program MDI commands. This would eliminate the error that is currently possible if I mis-enter the G0 command, which I do about once/week, and end up 20mm off on one of the axes.
  6. Is there a secret button somewhere for re-homing the machine? In prototyping, I’m using pretty much the entire work envelope and I found myself causing the machine to skip steps by going over travel. Right now if I need to re-home I close out of CM completely and restart. It’s nice that it doesn’t lose my offsets, but it seems a little silly.

Hopefully this is helpful to you. I’d be happy to talk through my use case and observations if there is interest on your side.

Best,
Josh

4 Likes

Monday bump for the CM team.

While I don’t have the same use cases, since I learned about workoffsets I’ve really wished CM supported them. A few little changes would improve lots of things, such as a re-homing button and so on.

Have you checked out bcnc? Not sure I completely follow what you’re trying to accomplish but it has support for work coordinate systems which may be closer to what your after.

1 Like

Hadn’t seen that yet @farmer. Working on install but getting screwed up with Python 3 vs 2 and homebrew. Looks likely to really help me though. Thanks!

It works fine with 2, don’t think it fully supports 3 yet.

1 Like

While the tkinter graphics library should look the same on Mac, Windows and Linux I’ve found it looks better on Linux. I originally ran it on a raspberry pi, but after they started offering raspian desktop for x86 I run it on an old pc and it works great. The raspberry pi foundation also has really good python support, it runs great in the pi or the x86 distro.

1 Like

Ooh that makes me remember that I have a RPi and RPi touch screen collecting dust from another project. Worlds best pendant here I come.

1 Like

Hey Josh-

Thanks for the feedback. Over time we’d like to streamline the workflow and add shortcuts for power users. More offsets, or a named library of offsets is something we’ve talked about but you’e got some additional ideas that we hadn’t considered before (skipping the tool popup for instance). We’ll keep these in mind as we think about our next CM update.

2 Likes

Since you mentioned using UGS, there are some improvements to the DRO in the last few months that you might not have noticed in the nightly version of UGS Platform. The feature was requested by some power users, maybe it will get you part of the way towards what you’re looking for: http://winder.github.io/ugs_website/guide/platform/#controller-state-dro

2 Likes

Hey @robgrz glad to hear it! Right now I’ve moved to running bCNC on a Pi/Pi Touchscreen mounted onto the machine. Using Resilio Sync between my laptop and the Pi to keep my CAM folder in sync. It’s working beautifully and it has many of the features I was looking for already. Much, much worse UI but much faster for my use and I love the GCode preview.

@Winder UGS Platform looks really great but not sure how it would format for the 7" RPi touchscreen. Maybe I’ll give it a try if I am feeling adventurous one afternoon.

List of options for the Raspberry Pi, including some optimized for small touch screens at: https://www.shapeoko.com/wiki/index.php/Communication_/_Control#Raspberry_Pi