How type your own limits in carbide motion?

Software Carbide Motion
1

Hi.
I just download the new gbrl and the new carbide motion 4.0. Working perfectly, but…
Due to my enclosure box , I “lose” 30mm of machining space in y direction. How I can type my own xxl table dimension? On the carbide motion 3.0 it was easy to find, because I don’t want to see my spindle hit the front of my enclosure during a job! Thanks!!

2

$130, $131, $132 – [X,Y,Z] Max travel, mm

This sets the maximum travel from end to end for each axis in mm. This is only useful if you have soft limits (and homing) enabled, as this is only used by Grbl’s soft limit feature to check if you have exceeded your machine limits with a motion command.

MDI and type
$131=820 and click send
$$ will bring up settings so you can confirm change. G/L Ray

2 Likes
3

I’m afraid that at this time, Carbide Motion 4 has the machine dimensions hard-coded into the app.

1 Like
4

so if i type the $131=820 It will not work?

5

It depends what gcode sender you are using. Carbide Motion does a lot of “extra thinking” around what gets sent to the machine and what doesn’t. Simpler gcode senders like UGS and grbl-panel are more direct.

If you want to customize your soft limits and dimensions, you’ll need to user something other than CarbideMotion.

1 Like
6

I am not enoght a geek to use an other software than carbidemotion…

1 Like
7

But now, if I want to keep the carbide motion v4 , how I can be sur to never hit the front of my sound enclosure?

8

It seem it will Not working with the 4.0 version of carbide motion …

9

Another option here would be to use a 3rd party communication / control program such as UGS or bCNC. See: https://www.shapeoko.com/wiki/index.php/Communication_/_Control

1 Like
10

Will,

As I think you saw in another thread regarding 3rd party z-axis options, this hard coding of limits is challenging for some.

While I appreciate that the hard-coded limits are “as designed” and are not a ‘bug’ per se, given the DIY nature of CNC at this level, it seems in Cabide3d’s interest to at least consider making changes in Carbide Motion to allow for an override of these hard-coded limits or put on a fix list for a future release, even if at a lower priority.

From a software perspective, this would seem like a fairly simple fix to implement (ie, add some code to allow for an override to the default limits so GRBL code is effective).

-Pat

2 Likes
11

Unfortunately, we’re a small, self-funded company — there’re only so many hours of development and testing time available, so we need to keep things manageable, and this seems to be one of the decisions which was made to do that.

Please check in w/ @robgrz and @edwardrford and @Jorge for anything further on this.

I’m not an official anything but part-time support guy and occasional freelancer and long-term volunteer on the opensource aspects of the product.

12

Whilst I’m a big fan of Carbide 3d, I do wonder why they develop a G code sender. Ages ago I invested in a Tiko 3d printer - the only kick starter project I will ever invest in. As many will know they squandered their backers money and the project went bust, part of what they did was develop their own slicer prior to have a working machine and production cycle. As the dust settled I wondered why spend money and time re-inventing the wheel when they could have saves thousands and made a different wheel fit.

Whilst Carbide 3D has nothing to do with tiko, and in my eyes one of the best companies I have ever dealt with (unlike those at tiko). I do wonder why build software that already exists. It would seem logical that they could save on development costs by partnering with the chaps at UGCS and help create a standard for GBRL senders that more companies adopt.

If one system was pushed by multiple companies, we might see faster and more uniform developments. Granted I have no concept of how Carbide 3d develop their software and appreciate many firms want to control their eco system, but they already support GBRL as an opensource project why not extend that and free up resource to develop tools/machines/services etc.

13

I’m not involved in the development, but the reasons for Carbide Motion which I can see:

  • total control — it also facilitates the Carbide 3D MeshCAM licensing for v7 — just tell that app you have a Nomad, and it output .egc which only Carbide Motion will decrypt and only when connected to a Nomad
  • branding — it looks nice to have Carbide Motion show in a video showcasing a machine
  • additional features — it enables add-ons such as the Probe
  • runs native on known machine configurations — support would be a lot harder if we also had to troubleshoot Java installs, or Python