Its my understanding the MR1 uses grbl based controller. So has anyone tried Universal G-Code Sender instead of ControlCut? Then you can make your own macros etc. Some of the complaints I see about ControlCut in the other threads is just inherent to grbl. Which is probably why those gripes don’t get fixed. Langmuir would have to re-write their own version of grbl.
This would be a good reason for a LInuxCNC version of MR1. I haven’t used LinuxCNC but it seems to be a more customizable system. The control boards price wise are probably insignificant compared to a grbl control board. And then when someone creates a pull bar spindle setup for the MR1, LInuxCNC would win hands down for ATC options I think.
There is a MR1 branch on that github with the initial grbl firmware for MR1. I pushed for them to publish this so that we could see the recommended axis speeds and acceleration settings.
I’ve been running my MR1 on LinuxCNC for years. There is plenty of information on my conversion and others in threads on this forum.
Thanks Ill check it out. I was wondering if anyone has installed UGS and tried to connect. If it is grbl based then it should. And then you could look up the axis speeds and acceleration settings. And more.
I have seen your LinuxCNC. I would like to see Langmuir offer both options. I hate the idea of buying something and completely changing the controls. I think with LinuxCNC you would see more folks doing mods. Not that grbl is a large restriction but I think LinuxCNC would be better for mods.
My guess is that the price would only drop about $300-$500 if they didn’t include the power supply, stepper drives, steppers, and CutControl board. User’s wouldn’t have a way to validate the machine as working before they started customization. So I get why Langmuir only wants to offer a “complete” machine, it probably makes warranty issues easier to solve.
It would be great to see Langmuir follow in Tormach’s footsteps and just ship their machine based on LinuxCNC. Tormach’s PathPilot interface (based on LinuxCNC) is very nice and has a ton of features out of the box.
From my reading of the GRBL code the acceleration and speed parameters come from the GRBL firmware, not from the sender. I also don’t think that GRBL (even with UGS) supports any sort of scripting with hardware feedback (beyond the G38 probe command), which is also limiting.
So are you saying it’s possible to modify the firmware to increase the axis max speed and still use cut control? I’m very interested in this. With my new stepper motors I would love to try to move faster.
I have an Centroid Acorn board that I was going to use but I think I might save it for my DCM2 Mini that I’m building. I can’t afford to have my MR-1 down even for a little bit since I use it for Beck Tools production parts.
I run grbl 1.1h on my cnc router and I can change the accleration of X/Y/Z that would be $120 for X, $121 for Y and $122 for Z. I have a probing. And I have a tool change macro that automatically calculates tool offset so after I change tools, I click my tool change macro and it go to the tool setter and calculates the new tool offset and I continue on to my next op.
This is why I ask if anyone has installed UGS on there computer and tried to connect to the MR1. If it is grbl based I am pretty sure it would connect. And if so you can then type $$ in the console window and it will list out all the grbl settings. Everything from step pulse time to arc tolerance, to homing location and speed, axis acceleration and just about everything else you can thing of.
In grbl 1.1h, to change the axis maximum rate it would be $110, $111, $112, that is X/Y/Z respectively. But that is using UGS. IDK if cut control gives you a user interface to see the grbl settings and make changes.
It is highly likely that a firmware update is possible to unlock/overload whatever capability you would like.
Per my understanding, cut control is a pretty UX that flows premade Gcode into the machine and also digitally previews the Gcode. The various buttons feed special Gcode for particular functions.
To be perfectly honest, I can’t figure out why CutControl SW development takes so long, especially with how the whole platform is leveraged on open source control software and 3rd party CAM software for tool paths.
It’s not super straightforward… if you go mucking around, there is a risk that you brick your control board. Just need you to be aware.
If I were serious about this, I would be trying to buy or replicate a second main board so I have an intact board to study and use.
Langmuir’s documentation isn’t very good. They have either provided the bare minimum or they aren’t actually compliant with the open source license requirements.
Your first goal is to get to a point where you can compile code in the Arduino IDE that functionally matches the current code AND load it onto the machine. Doing this puts you into the drivers seat in terms of the machine’s functionality.
The below are a bunch of hodge podge thoughts from an armchair enthusiast. Langmuir may decide they don’t like me suggesting how to reverse engineer their machine and take my post down.
The first step is find out what microcontroller is on the main control board and assess the likely security measures in place.
Because over the wire updates are possible, it means there is a bootloader on board to load new FW. If the bootloader is unencrypted Arduino, you are in good shape. If it’s proprietary and encrypted, you’ll have to plan to eventually roll a standard open one.
There’s a bunch of work to sniff the USB connection (is it a plain serial port like GRBL or custom and encrypted) and verify what’s going across is clean GRBL protocol (or is new and contained within Langmuir’s repo).
GRBL is a generic and vast library with a ton of configuration parameters. You’ll need to either extract these from the repo if they are populated or if the chip security allows, you can copy out the flash/eeprom to learn what the parameters are.
In the absolute best case, the bootloader is standard Arduino, the chip is fully unprotected, and the repo is complete and easy to compile/load.
In the worst case, you’ll need a great deal of embedded hardware and firmware experience to analyze, configure, and get to a point where you might have something that appears functionally the same but you’ll never be able to fully verify it.
Of course, because Langmuir controls CutControl, they can update the software to intentionally break any known hack at any time for any reason.
I dont know that UGS will work/safely. If they locked the controller somehow UGS won’t connect.
UGS would let you change the grbl settings you want to change. Its not really a firmware issue. Cut control & UGS are interfaces. Ugs is not proprietary so you have access to everything. CutControl they hide things from you and have a nicer looking gui.
When you open UGS software, you select the com port the MR1 is connected to then click connect. If it connects you type $$ in the console wondow & it will list all the settings & the values. The those are what you can change WITHOUT a firmware change.
Or contact Langmuir & ask if UGS can be used. When i started this thread I thought they might chime in. Or more likely someone else has tried UGS.
It is a DIY project to figure out how to compile and install it, Langmuir didn’t provide instructions for that (nor are they required to by the GNU license). I don’t have a CutControl board anymore, so I’m not going to be able to help.
You’d need to be at least an experienced microcontroller developer (Arduino and similar) to do this.
The acceleration and speed parameters are at the bottom of defaults.h: #define DEFAULT_X_STEPS_PER_MM 320.0 #define DEFAULT_Y_STEPS_PER_MM 320.0 #define DEFAULT_Z_STEPS_PER_MM 533.333 #define DEFAULT_X_MAX_RATE 2540.0 // mm/min #define DEFAULT_Y_MAX_RATE 2540.0 // mm/min #define DEFAULT_Z_MAX_RATE 1016.0 // mm/min #define DEFAULT_X_ACCELERATION (300.06060) // 106060 mm/min^2 = 10 mm/sec^2 #define DEFAULT_Y_ACCELERATION (300.06060) // 106060 mm/min^2 = 10 mm/sec^2 #define DEFAULT_Z_ACCELERATION (50.06060) // 106060 mm/min^2 = 10 mm/sec^2 #define DEFAULT_X_MAX_TRAVEL 580.0 // mm NOTE: Must be a positive value. #define DEFAULT_Y_MAX_TRAVEL 550.0 // mm NOTE: Must be a positive value. #define DEFAULT_Z_MAX_TRAVEL 150.0 // mm NOTE: Must be a positive value.
This list looks like it is missing some settings. But it’s likely not complete list or out of date.
If someone has a board they aren’t using or are going to switch to something else. The easiest test is too download Universal Gcode Sender and try to connect to the mr1. Dont use CutControl. PERSONALLY I think it will connect. If it connects use UGS to list the settings &/or change the desired settings. Then continue to use UGS to run gcode or go back to CutControl after the desired changes are made. No compiling needed, no reverse engineering needed.
With my new stepper motors I would love to try to move faster.