Maslow Home Maslow Community Garden

Holey Triangular Calibration


I put “B10 L” and “B10 R” as macros named “Report Left Chain Length” and “Report Right Chain Length”. I am thinking I am missing something. I was able to run it once, and then it stopped working. It only reported the chain length one time. Do I need to add an M2 or M3 line? If so, how the newline captured in the macro? I apologize that these are very simple problems.



I found an example where @blurfl suggested a macro where it looks like the lines are space-separated.

So, for my application, the macro would be “B10L M02”, I think.


I was able to issue “B10 L” multiple times in webcontrol without using M02. You see multiple “B10 L” in the log with one the first getting a response, or do you only see one “B10 L” in the log?


I do not have it in front of me, so I will have to double-check to clarify. I only saw one returned chain length, and I was unable to do further work; GC apparently froze. I tried to run another *.nc file, but nothing happened.

Let me just double-check that I am looking at the correct log file. I only found one. It always logs to the same file, correct?

It turns out the error occurred somewhere between the chair and the keyboard. I tried again this morning and didn’t have any problems.

  • I removed the chains from the motors and ran the system with the motors attached to the shield, but no sled or chains. I had issues with “The Sled is not keeping up”.
    • I increased the threshold at which this message pops up to 200 mm, but it didn’t take effect until I restarted GC. Is this expected behavior, that this change requires a restart?
    • I remember seeing somewhere in the code where the position set point will pause or slow down when the z-axis is not keeping up. I think this makes sense for the x and y axes, too. Is there any ambition to implement this? This may be a good question for @blurfl.
    • When it did run, there were substantial position errors. Since the sled and chains were not attached, the motors were not loaded. The only limit was the maximum speed the motors could turn. I am wondering if this position error was caused by hardware limits (control board/motor speed limits), or the software position controller. How confident are we in the controller (PID) calibrations and implementation for the position/velocity controller?


Was wondering with you and checked if I could trigger the alarm in fake server mode and did with FW/GC 1.23
2 possible causes i’m following right now right now is:

    1. I set the feedrate to 2000 (Do not do this!) The Pos-err-lmt is unchanged at 2.
    1. I noticed a different behaviour with GC the second, third time and so on I started GC. 1st time today I started GC the port, position and FW/GC version is reported.
      Closing GC without ‘disturbances’ and opening again will also show all start reports.
      On some occasions however GC leaves the arduino in a ‘strange mood’. Directly noticeable that on a new start only the port is reported and no position and version numbers. Only disconnecting the mega (cable) and reconnecting will let it recover from that mood. No arrow buttons work, only the stop button gives me suddenly the positions every time I press it. Run/Play will only advance the number of gcode line, unless you press pause and then run. Here the sled not keeping up message appears.

Not sure how relevant the ‘fake server’ is for the workshop, but I got the popup :grimacing:


I am trying to think about what the cause could be if you were able to get the error in fake servo mode.

  • It could be due to some kind of diagnostics bug.
  • It could be due to some controller limitation that causes the sled to poorly track the setpoint, in the absence of hardware limitations
  • It could be due to the fake-servo being a poor representation of hardware.

Further consideration:

  • Since I am getting the same error not in fake-servo mode, it is likely not the fake-servo mode.
  • When I increased the bounds to 200 mm, I could clearly see the target deviating from the controlled sled position, via the picture shown in GC. So, we know the sled is not actually keeping up. In my case, the motors are connected, so it could be a hardware limit. In your case, there is no hardware. Do you know if there is some kind of velocity or power limit programmed in for fake-servo mode?


Now I’m starting to think that changing the setting (in my case feedrate) and not restarting is the issue. I can go backwards to 800 and run will still trigger the message.
If I still could read code I would look what happens after changing a setting.
Issues I see with keeping GC running without restart, but it could also be writing setting to eprom.


It is like one is the cause, and the other is the symptom. Do you agree?


I big like


Sadly no and not even know at what version it was implemented and how it’s keeping up with chain slag and tolerances. Fake server might be not compatible by now.


Firmware-1.23/cnc_ctrl_v1/Axis.cpp: #ifdef FAKE_SERVO


Fake servo mode is still compatible and quite useful, I use it all the time :grin:. It adds a little bit of random error (+ or - 10%) to calculate a fake motor rpm for the PID routine. This simulates the sled moving just a little roughly/realistically. Look around line 88 of Axis.cpp to see where this happens. It really is very simple and elegant.


10% error

Does that add up with feedrate? Is there a ‘if error bigger than X goto popup’?

That is so pleasing to know as also has a history discovering buffer overflows and does a wonderfull job in gcode forensics!


So, the randomness added to the signal could potentially cause the controller to deviate more than the 2 mm from the target. @Gero, I wonder what would happen if you eliminate this added error. Would you still get the popup?

@blurfl, is there a speed-limit programmed into the Fake Servo?


Just confirmed that it’s the same with 1.24
Changing setting leaves the ardiuno in a strange mood and unless you disconnect it will not recover.
I believe I had success twice with giving time after closing the settings and time to close GC.
Can’t confirm that for sure.
Do we know how long it takes to make a setting ‘known’?

Edit: And here is where I give up for tonight:

maxfeedrate = 1460
is the limit where diagonal does trigger and horizontal and vertical runs. 2000 immediately triggers any move. Not in fake mode also triggers any move, even if the feedrate is 1 :+1:.

Edit2: Editing the GC.ini before restart does not leave the arduino with bad feelings like changing setting does.
Every time the popup showed up, a disconnecting was required on linux. Changing ports from ttyACM0 and back was also done in the .ini to save time.


I looked into the GC code. I found one location that looks suspicious.

If the property, connectionStatus is not 1, it will not write to the board. So, if for any reason this happens, it will stop updating the firmware settings. What we would like to know is where and why connectionStatus is being modified.


Somewhere here I guess, a ‘grep’ did not find in FW and GC is here:

whoareyou4@dexter:~/Maslow/fw-test/Firmware-1.24$ grep -r “connectionStatus” ~/Maslow/fw-test/GroundControl-1.24/
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/UIElements/ connectionStatus = StringProperty(“Not Connected”)
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/UIElements/ = self.updateConnectionStatus)
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/UIElements/ self.connectionStatus = “Connected”
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/UIElements/ self.connectionStatus = “Connection Lost”
Binary file /home/whoareyou4/Maslow/fw-test/GroundControl-1.24/UIElements/frontPage.pyc matches
Binary file /home/whoareyou4/Maslow/fw-test/GroundControl-1.24/Connection/serialPort.pyc matches
Binary file /home/whoareyou4/Maslow/fw-test/GroundControl-1.24/Connection/serialPortThread.pyc matches
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/Connection/ if not
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/Connection/ = 1
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/Connection/ = 0
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/CalibrationWidgets/ if == False:
Binary file /home/whoareyou4/Maslow/fw-test/GroundControl-1.24/CalibrationWidgets/intro.pyc matches
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/ = self.requestMachineSettings)
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/ if != 1:
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/ if == 1:
Binary file /home/whoareyou4/Maslow/fw-test/GroundControl-1.24/DataStructures/data.pyc matches
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/DataStructures/ connectionStatus = BooleanProperty(0)
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: #disabled: not
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: #disabled: not
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: #disabled: not
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: #disabled: not
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: text: root.connectionStatus
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: #disabled: not
/home/whoareyou4/Maslow/fw-test/GroundControl-1.24/groundcontrol.kv: #disabled: not


Looking back at your original problem, it is like the connectionStatus is being held across GC close/restart. That means it is reading it from the firmware somehow.


I checked GC.ini and that is updated on the fly in near real-time before closing the menu. That’s why I changed from changing in GC settings to editing the .ini

Edit for myself as a recap (state again as a summary; recapitulate):

  • editing the setting via GC leaves my china arduino in a strange state until disconnected
  • editing the same values in the GC.ini does not
  • raising feed rate at 2000 triggers ‘can’t keep up’ in FAKE_SERVO despite if changed in GC or in the .ini on using arrows in any direction (never seen before and using long time)
  • setting maxfeedrate = 1460 lets me use the arrow horizontal and vertical but diagonal will trigger the message
  • it’s ~ 8 seconds from GC start until the rx starts flashing, it’s ~the same from closing GC until it stops
  • i might or might not have seen differences in ‘arduino dementia’ with waiting longer to close a menu, before giving a command and/or before closing GC.
  • not setting FAKE_SERVO triggers the popup with feedrate set to 1. (expected if no values from encoder)

None of this is true unless replicated somewhere else on the globe.

~ unrelated addition to compensate for my memory before i go to bed:

  • only once observed was sled position not x0,y0 after wiping eprom from within GC and deleting CG.ini.
    The position of the sled was clearly where i ‘parked’ it before.
    Other popups showed like ‘cannot determine position’ or so. Should not be with the standard settings loaded if no .ini is available. Needs more research like using the ‘internet arduino wipe’ to see if any difference.


Was wondering with you and checked if I could trigger the alarm in fake server mode and did with FW/GC 1.23

the ‘unable to keep up’ will not happen in fake mode, it only happens when the
position recorded by the encoders gets too far away from where it should be.

Since we don’t have acceleration calculations, this is very easy to trigger at
the start of a move. As such, we need to set it to such a large value that it’s
almost useless currently. Once we have acceleration calculations, it will be
worth a lot more.

David Lang