Re-Naming Axis for grblHAL

Hello! I’ve been using GrblGru for my 3 axis CNC and loving it. I just finished restoring a old Denso 6 Axis Robot and setting it up with grblHAL. It works well but right now I can’t drive it with GrblGru as the Axis names don’t line up with the AR3 type. I tried changing the axis mapping in machine manager but GrblGru gives me a dictionary not found error.

grblHAL only has 2 options for axis names: XYZABC or XYZUVW and unfortunately they cannot be changed even before compiling (I’m using XYZABC). Right now I’m programming the code using GrblGru, manually changing the axis names in notepad++, then driving the robot with IOsender but I would love to be able to do it all with GrblGru. Any ideas?

Did I miss something because I can’t see where you say what you want for naming, only see you post what 2 naming options grblHAL offers.

I am glad that you like GrblGru. :slight_smile:
We should also be able to solve the renaming problem. Please try the following:

First we check the name of the axes and determine the order in which the controller sends its axis positions. I have made the following screenshot with a GrblHAL on an Arduino DUE controller with only XYZAB for 5 axes. You should have an additional column for C.

  • Select your COM port and Controller = GrblHAL

  • Open the two controller windows. You can enlarge the window with the left mouse at the top edge. See pic 1

  • Set ‘Comman line’. Now you can send commands directly to the controller in the left window.

  • If you have flashed GrblHAL with ‘XYZABC’, enter the following in the left window:
    g1 g90 f1000
    x1
    y2
    z3
    a4
    b5
    c6
    The controller then moves the axes and sends the current axis positions in the right window. In my case, the sequence is XYZAB. See Right window

    • Enter this sequence under ‘Order of axes’.
    • Then change the mapping in the MachineManager as required. See pic 2
      Note that only the designations in the interface are changed. The displays in the interface remain unchanged.

In pic 3 you can see in the left window what is sent to the controller when you successively the marked buttons one after the other. For example, X-36000 is sent when you press the C button.

Let me know if you have any questions.

2 Likes

Thanks for the response! I tried what you’re showing and still get the same error. I also tried upgrading to v6 but that didn’t help. I was able to flash the mega-5X hex file you provide with GrblGru to a spare mega I had which does work, but it’s limited in how fast it can run so I’m back to trying GrblHal. here’s a screenshot of the error I get. The error happens when I try to load the STL files now. I used the same STLs for the mega-5x which work, and tried leaving them named ABCDEH and XYZABC but neither work. Any more ideas to try?

(error text)

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
at System.ThrowHelper.ThrowKeyNotFoundException()
at GrblGru.Form1.GetToolMatrix()
at GrblGru.Form1.DrawFraese3D()
at GrblGru.Form1.Draw(Int32 nMode)
at GrblGru.Form1.StartNcProgSegment(List1 NcProg, Boolean bWaitForControllerIsReady) at GrblGru.Form1.StartNcProg(List1 NcProg, Boolean bWaitForControllerIsReady)
at GrblGru.Form1.SetzeRefPkt(v4 vNewRefPkt, v4 Anzeige)
at GrblGru.Form1.OpenController()
at toe.Controls.CtrlButton.xButton_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9290.0 built by: NET481REL1LAST_C
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll

GrblGru
Assembly Version: 6.0.0.0
Win32 Version: 6.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/toe/GrblGru_v6/GrblGru.exe

System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9251.0 built by: NET481REL1LAST_C
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9282.0 built by: NET481REL1LAST_C
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9037.0 built by: NET481REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

toe.Lib
Assembly Version: 1.3.0.0
Win32 Version: 1.3.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/toe/GrblGru_v6/toe.Lib.DLL

toe.Cad
Assembly Version: 11.3.0.0
Win32 Version: 11.3.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/toe/GrblGru_v6/toe.Cad.DLL

toe.Props
Assembly Version: 1.0.9138.38472
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/toe/GrblGru_v6/toe.Props.DLL

toe.Tree
Assembly Version: 1.9.0.0
Win32 Version: 1.9.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/toe/GrblGru_v6/toe.Tree.DLL

System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9037.0 built by: NET481REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9277.0 built by: NET481REL1LAST_B
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9037.0 built by: NET481REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

Accessibility
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9037.0 built by: NET481REL1
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll

System.Data
Assembly Version: 4.0.0.0
Win32 Version: 4.8.9214.0 built by: NET481REL1LAST_B
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.



I got it sort of working! I had to uninstall all versions of GrblGru, then go to the Program Data folders and delete the toe folder in each. doing a re-install wasn’t enough. That cleared the dictionary error, and now I can drive the robot around!

First the small bug: the software appears to be doing a find and replace to rename the axis which does work but also means if you remap the “X” axis the unlock command no longer works as it will be replaced with whatever you put in that first box. I set it back to X (so there is a duplicate) and it works fine after that. See the first screenshot

  1. Right now the virtual robot only moves when GrblGru is in simulation mode, when I connect it to grblHal I can jog it but the representation stays still.

  2. For some reason the gcode isn’t being executed on the right axis, I’ve doubled checked that my axis are in the right order and everything is moving the right direction when I manually jog, but it seems to only want to work behind the robot at a 45 deg angle. This happens in simulation and on the real thing.

Thank you so much for adding the ability to remap the axis names! I like saving old salvage CNCs and robots and GrblGru is giving me great way to do it!


At the moment it is difficult for me to understand what you have done and what is not working at the moment.

My suggestion would be to try a Mega, Mega-5X and the AR3 model first. If that works, you can make changes step by step.
For example, use your model and then use GrblHAL and then etc…
This would have the advantage that I can follow the steps in parallel.

Here are a few more comments:

  • Actually, Mega-5X and GrblHAL should be approximately the same speed if they run on the same controller. The Mega is relatively slow because, like the UNO, it only runs at 16MHz.

  • The mapping only takes place in the interface.
    If you send commands directly to the controller in the left window, they will not be changed (mapped).

  • If your real axes move correctly when you move them manually and the 3D model remains stationary, please check whether actual positions are sent in the right-hand controller window.

  • Please provide me with the STL files of your model.

Thanks for replying again!

I have uploaded all my data including STLs and machine.dat as well as some screen recordings as I worked through in case something jumps out at you to this google drive link:
https://drive.google.com/drive/folders/1KuznjfJWtl209j0b9hb-bsb55xmwpEjp?usp=sharing

For clarity, I have 2 separate control boards, a Mega running Mega 5x (ABCDEH) and a BTT Octopus Max running GrblHal (XYZABC). I do not have them plugged in to the pc or robot at the same time

For the simulator not moving when connected issue. I tried again with the mega and ar3 like you recommended and that worked which led me to resolve it for the Octopus by setting the “Axis Order” to ABCDEH.

With that fixed the simulated robot now moves in sync with the real robot using the Mega or Octopus.

Fixing the Axis Names did seem to make the off-axis issue better, but not perfect. Even in simulation the gcode generated is offset from where the work zero is. This does not happen with the AR3 model so it must be something with my setup.

Thank you for the files and pictures you have made available to us.
I like your powerful robot ! Once all the problems are fixed, you must make us a video of how it works. :slight_smile:

It’s great that now the real robot moves like the 3D model.

I added your Denso model to the programme and I noticed 3 things.

  • Normally the origin is under the first rotation axis (A-axis).
    In the MachineManager, the position is then (0,0,0). This is not the case with you. It should actually also work this way. At the moment, however, I’m not sure what influence this has on everything else.
    I will investigate this in more detail when I have a bit more time. In principle, however, it would be nice to change this, even if it involves a lot of effort.

  • The A-axis rotates off-centre. I don’t know if this is intended.

  • There are 2 Denso chapters in the Machine.dat. What is the difference?

Maybe a hint that you can install several GrblGru versions in parallel and use them at the same time. This may offer the advantage of being able to compare changes more easily. You just have to enter a different name during installation.

Much success

1 Like

Thanks for the advice!

I fixed the model so that the origin is directly under A. This didn’t fix the offset issue so I re-installed 6.0 fresh again and noticed that the aLFA and JacksArm have similar issues with the default Elch program. This seems to be some kind of bug in 6.0 and the current beta. :face_with_diagonal_mouth:

Thanks for the feedback. A mistake crept in at some point. :frowning:
Please download the new beta version V1.3 and it should work again.
I also noticed during testing that you have to make sure that the geometry is within reach. If any points cannot be reached due to the geometry of the robot, this sometimes results in nonsensical movements.
The easiest way to do this is with the ‘graphical editor’. This allows you to set the size and position the geometry in a suitable place.

I have also checked again. The base of the 1st rotation axis should be (0,0,0), otherwise the path will be moved with an offset. This is the case in the current version with your ‘Denso’ model. Please provide me with the corrected STLs and the Machine.dat. Then I can also correct this in the next version.

If everything works for you now, we would be very happy to see a short video of a robot painting a moose. :slight_smile:

3 Likes

Thank you! I’ll try your suggestions this weekend, and will be sure to provide you with a video!

I have uploaded the corrected model to the same google drive link above. In the machine DAT file there are 2 variants. Both have the A axis centered at 0,0,0 but I found the offset error goes away when I moved the tool itself to be centered on the X axis so I saved it as a separate model named Denso_centered.

I sent you a few dollars on paypal, thanks so much for your time and making this awesome software!

1 Like