Homing Strings

Home Forums DIY Sand Table Homing Strings

Viewing 25 posts - 1 through 25 (of 28 total)
  • Author
  • #635
    Matt G

    I’ll explain my string, and how it works.

    You can look at this file to get an understanding of what is parsed. https://github.com/robdobsn/RBotFirmware/blob/master/PlatformIO/src/RobotMotion/MotionControl/MotionHoming.cpp

    My Homing String

    FR10; sets the feed rate to 10. I think I just copied this from Rob. I think you can alter the homing speed with a different feed rate.

    A+10000N;B-10000; rotates the center arm clockwise for 10000 steps (9600 is one rotation) until the end stop is first triggered (N). My center arm is A – you need to home the center arm first – yours may be B depending on what stepper is hooked up to what pins. B is spinning in the opposite direction here just to keep the angle between the arms the same.

    A+5000n;B-5000; Rotate in the same direction until the sensor stops triggering (n). For me, this puts the lower center arm directly in line with the center line of the robot. At the end of this, the center arm should be rotated and stopped so the end of it (the elbow) is near the 2nd sensor

    B+10000N; Rotates the top arm at the elbow for one full rotation until it triggers (N) the 2nd sensor.

    B+5000n; Keeps rotating in the same direction until the sensor stops triggering (n). With sand – this puts me just about dead center.

    A=h;B=h; – set the home position

    Homing will be slightly different with sand than without due to the friction and bending of the arms. You should never have to have one arm rotate more than a full rotation, and you need to make sure your 2nd elbow sensor can be triggered once the first lower center arm is done with its homing – or the top arm will never be able to be homed since it can’t make it to the sensor. I played around with the little sensor arms quite a bit – so you may need to tweak them or distances to the sensor.


    Hello Matt, I have a few questions about homing
    1. when you turn on the table does it start homing?
    2. is there a homing code or file?
    3. does it automatically start with a pattern after homing?
    4. If I switch off the table during a sample, does it continue to move after switching on or does it start with a new one?
    excuse the many questions 🙂 Thank you Geri

    Matt G

    Hi Geri

    1. The table does not automatically home when you start it up. There is a section of the JSON config called “cmdsAtStart”, which is blank in my config. You can add “g28” to this value to home on startup. g28 is the gcode command for home.
    2. The homing string is also located inside the JSON config at the key “homingSeq”. The firmware code file that processes this string is at https://github.com/robdobsn/RBotFirmware/blob/master/PlatformIO/src/RobotMotion/MotionControl/MotionHoming.cpp if you can understand c++ and how it processes that string.
    3. No – you need to start a pattern after homing.
    4. Once you shut the table off – if you have nothing in “cmdsAtStart” in the JSON config, the table will do nothing when you turn it back on, so you will need to re-home and re-start the pattern. Once the stepper drivers lose power, there is no way for them to know what position they are at, so you can not restart the drawing process.


    Hi guys, I’m really struggling with the homing function of the bot. So, what happens is the following:

    I start the unit by pressing the ‘home all’ button.

    The main arm (upper arm) starts to rotate until the optical limit switch at the bottom is made – the green light turns on and the arms stops rotating, therefore confirming it is in the ‘home’ position

    The second arm (lower arm) automatically then starts to rotate and when it makes the optical switch (the green light of the switch turns on) it keeps on rotating. Therefore missing the home position. I have also changed the switch with another switch and is still skipping the homing position when the light goes on….

    Here is the part that tickles my brain….

    When I start the homing process and use a piece of plastic arm to trigger the lower arm optical limit switch, all arms stops to rotate. This confirms that the electronics is picking up the lower arm optical switch and therefore something else is causing the problem.

    Is there someone that experienced the same problem or can guide me in rectifying this?


    Hi all,

    so I want back to the drawing board….

    1. Deleted all files from my computer
    2. downloaded the latest version of the RBotFirmware from github
    3. reloaded software into the Visual Studio platform
    4. upload new RBotFirmware onto the CPU

    I’m still getting the same issue…. The first step of the homing function works great, the arm rotates and as soon as the optical light has made contact the second arms start to rotate. however, it keeps on kssing the homing position – even though the optical switch is activated (green light comes on).

    I tested the switcha again by activating the homing function and manually activating the second opticl switch with a piece of plastic – Both arms stops to rotate as if it recognises that it is at the home position – confirming that the switch is working….

    Is there someone that can assist me on the programming on where to find the function of the second limit switch? I do not have preally programming skills (apart from REALLY basic Arduino programming)?

    Matt G

    If you look in the first post in this thread, there is a link to the actual firmware code that is processing the homing string.

    I’m struggling to figure out how you can get into a situation where manually tripping the optical endstop works, but the arm triggereing it doesn’t.

    Are you waiting until the 2nd arm starts homing before triggering the endstop manually when testing? You would need to make sure the homing is in the same state when the 2nd arm is rotating to properly test.

    Another tip is you could remove the “duplicate” movements in the first portion of the homing string to keep the arms aligned. For example in my example above:

    and so on – just to be sure that A is mapped to the first arm like you expect, and you just don’t happen to be tripping A’s sensor with the B movement.

    You need to make sure that in your string the A commands are moving the bottom arm. It sounds like they are since you mentioned only the top arm moves in the 2nd portion of homing.

    Can you post your homing string here?


    Hi @Matt G,

    Thank you for the prompt response. It is much appreciated. Ok, so let’s start from the top:

    1. I reviewed your comments and made the changes to the code as recommended to ensure that A is moving the bottom arm and B is moving the top arm. This has been tested and the motors is connected and working accordingly.

    2. I turned the power off from the unit and restarted everything (the “Have you tried to switch it on OFF and On again” sequence).

    3. On startup, everything seems to be booting up nicely. On the terminal screen I see I’m connected to the WIFI and through the browser I can access the Robot configurator (UI). I can see that the memory card is reading accordingly (32Gb card) and can upload/delete paterns onto the bot. Under the “RobotConfig” row I can see the corresponding code I uploaded as stipulated in the “DIY Kinetic Sand Table Art” as described by you.

    4. I have then set the arms to be at the “11:00” clock position to test whether both the Bottom and Upper arm can be homed automatically.

    5. After that, I pressed the “Home All” button.

    6. The Bottom arms starts to home and as soon as the optical limit switch is activated (the sensor located at the bottom of the bot) the bottom arm stops to move and the Upper arms starts to move.

    7. However, the Upper arms keeps on rotating through the optical sensor even when the sensor is activated (The light of the sensor comes on).

    8. I then thought the sensor is broken and replaced it with a new sensor. However, on activating the homing position again, the Upper arm once again ignored the sensor and keeps on rotating.

    9. I then thought it may be that the signal wire of the sensor is damaged and that the signal is not getting through to the processor. How I tested this was the following:
    * I positioned the arms again to the 11:00 position and activated the homing sequence.
    * Before the Bottom arm could activate the bottom sensor, I manually activcated the upper arm sensor with a piece of plastic – The result was that the Bottom arm stopped moving and the Upper arm did not start to move. According to my understanding is that this is correct. The reason being is that the only possible reason for the Upper sensor to be activated through the auto homing sequence, both the Upper and Bottom arms should be in the home position. Therefore, confirming that both the sensors are working and that the software is picking it up.

    What I do not understand is why the second sensor is ignored when the homing sequence is activated, the Bottom arm gets it auto home position but the Upper arms keeps on rotating….

    I made a video to show what is happening and stored it under the following dropbox link – If you could please have a look and see if something is wrong? I would appreciate it.


    Otherwise, If you have another way for me sharing info to you which might help assist in finding the problem I would gladly do so.

    Kind Regards


    Hi Matt,

    sorry I forgot to include the homing string, but as mentioned the homing string is the one that was posted on the forum as per your description. Also, the software that was loaded onto the bot was the version from Github.

    Kind Regards

    Matt G

    So if you’re using the same homing string.. I don’t think that interrupting the upper arm sensor while the lower is homing is supposed to stop it. I’m not positive.. I’ll open my table when I have time tomorrow and check.

    Can you try swapping sensor pins? Wondering if the sensor signal pins are swapped.

    Also – I have never tried the home all button on cncUi.html. I always use the home command from sandUi.html – which I believe sends a g28 gcode command. So it’s possible the home all button is doing the same.

    Matt G

    So I can confirm that triggering the “elbow” sensor during homing of the bottom arm should not stop homing:

    I have annotated this picture, that goes along with my robot configuration to show which connections go to which motor/sensor for motor A/B and sensor 0/1 alignment

    • This reply was modified 2 years, 12 months ago by Matt G.

    Hi Matt,

    Thanks for the information. It is much appreciated.

    so I compared the setup according your setup and yes, it is the same which is comforting to know.

    I did find the root cuase for the problem but not sure how to remediate it.

    So, what causes arm B from ingnoring its corresponding sensor and keeps on rotating? IT IS ARM A OPTICAL SENSOR THAT IS STILL ACTIVATED!

    So, How I tested this was the following:

    1. I activated the homing position.
    2. Before Arm A could reach the home position, I manually activated its sensor. This causes Arm A to stop and arm B started to rotate (with the first optical sensor for Arm A not acivated anymore).
    3. I activated arm B optical senos manually and it stopped. Which was great to experience.

    4. Then I resetted the whole system and rotated the arms to the 11:00 position.
    5. I activated the homing sequence and waited until Arm A activated the optical switch. It did, arm A automatically stopped and Arm B automatically started to rotaed. HOWEVER, Arm A’s optical switch is still Activated (green light still on). while the optical switch is still activated, the second optical switch for Arm B is ignored….

    So, what I believe would be the solution is the rotate Arm A for x amount further once optical switch is activated before it is stopped (so that optical switch for arm A is deactivated) before proceding to the next homing sequence for Arm B.

    I have played with the A+5000n;B-5000; Settings but it seems that I’m doing something wrong… I’m not getting the additional split second rotation after the switch is activated.

    Will you be able to assist please?

    Kind Regards

    Matt G

    Interesting that you found that out. I would start building the homing string up piece by piece. The A+5000n should be rotating an additional amount until the sensor is un-triggered.

    What type of sensor do you have? It is possible that the sensor’s signal is opposite of mine, so the first big “N” is always tripped, and then the small “n” in the A+5000n is actually being hit when the sensor triggers on.

    So what I would try is start here:


    Make sure that the bottom arm will stop as soon as the sensor is tripped in this scenario. Once verified, you can add on some more…


    To verify that the lower arm the proceeds the additional steps until the sensor un-triggers.

    If the first step fails – then you know that big “N” is not happening when your sensor is triggered.

    To debug that further you can play around with the robot configuration for the endstop in the cncUi.html’s settings area.

    			"endStop0": {
    				"sensePin": "36",
    				"actLvl": 0,
    				"inputType": "INPUT_PULLUP"

    You can try changing the active level to see if your sensor’s “default” state is 0, instead of 1 like mine…

    So start out small with the initial steps and build up until you get a string that works for you.

    You could also try


    with a small “n” if the initial big “N” isn’t working in this initial test too.. Let me know how it progresses!


    Hi Matt,

    Thank you for the great assistance. I must say, this forum is the first where prompt responses are experienced and help is given.

    The final end result was… Yes… It was the signals from the sensors that were inverted. So I had to change the N and n in the string. After changing it, arm A stopped after the optical switch was deactivated and arm B could home properly.

    I couldn’t find the exact optical sensors which you used, so ordered through banggood the optical switches. Also, for the rest of the people on the forum, I also ordered the Anet A8 plus printer through banggood for this project and all parts were printed with it. Quite happy with the quality compared to the price paid for it.

    Now that I know the bot is working 100% I’m ready to start building the table.

    Now I’m truly excited!

    Thank you again.

    Kind regards

    Matt G

    Excellent news.

    I wish everything was standardized to make stuff like this easier to track down, but glad you were able to solve the problem!


    I’m struggling with this. I have purchased optical endstops from Amazon but I cannot get them to work. I have tried all combinations with the N & n and with actval set at 0 and 1. I have tested the signal on the board and this is jumping to 4.8v when the sensor is activated/triggered.

    I seem to be getting the correct movement from the motors while trying to home which iss a Pluss on the first attempt.

    These are the sensors I purchased.

    Any help appreciated


    After some more tinkering and testing I think I have found the problem but not sure how to fix it. The sensors are now working but 1 sensor will trigger both axis. If I trigger the sensor on pin 36 it reads 4.8v but pin 39 will read 1.8 and the same if I do this the other way around. This is causing both pins to pick up enough voltage from 1 sensor to trigger both axis So I’m now I’m totally confused.


    Hey MattyP,
    Unfortunately, the link you posted to the limit switches that you bought broke, and I fear I may have ran into a problem similar to what you had.

    HESAI CNC 3D Printer Mechanical Optical Limit Switch Endstop with Cable

    These are the switches I am trying to get work, I’m hoping you can shed some light on how you worked past your problem?

    This is what I’m dealing with:
    ~I already switched the config to have ‘actLvl: 1’ for both switches, which gives me “HIT” when blocked, as desired
    ~The lights on both switches turn off when blocked, as desired
    ~The signal voltage for SENSE1 is 4.3 when unblocked, and shows the desired drop when blocked
    ~The signal voltage for SENSE2 is 4.6 when unblocked, and shows the desired drop when blocked

    What really confuses me is that
    ~ SENSE1, which corresponds to axis0 and sensePin36, triggers both the X&Y MinStop
    ~ SENSE2, which corresponds to axis1 aand sensePin39, triggers neither the X or Y MinStop

    You said that the voltage for the other pin seemed to fluctuate when triggering, but thats not happening for me. Really hoping you have some insight!



    Was able to solve the problem above. I think my sense pin 39 was faulty, as well as the signal voltage being simply too high for the pins. I saw here that the logic pins are 3.3v

    Huzzah32 Pinouts

    What I ended up doing is
    1. Reroute SENSE2 to pin 34/A2
    2. Add a 330 ohm resistor between the sensors Signal wire and the sense pin its connected to

    Everything works well now



    I still have roubles to get the homing properly done. It seems that only Motor A is homing:

    Video of my homing

    and this is my homing string:



    Hello bram
    First of all cool design. Your Scara is the aluminum?

    I think that your 2nd motor is not controlled, check all outputs and the driver. I’ve had several broken exits on my esp


    Hi Geri,

    Yes, I made my Scara in aluminium 🙂 The thing is: I can control both motors separately (e.g. X+10, Y+10, Y-1, …) but just the homing process is a struggle, as you see on the video I made, the second motor isn’t moving at all..


    hi bram
    is the lower arm milled?

    do both motors move separately in both directions?


    Hi Geri,

    yes, all the parts are CNC milled @ my work 🙂

    As you see in the video, both arms are moving (you see the angle between both arms changing). If I use a “B-10000n” in my homing string, the upper arm is moving in the other direction.

    I just don’t understand the whole homing process. You should think the main arm should move clockwise or counter-clockwise max 1 full rotation (9600 steps > 10000) until he hits the end-stop sensor. Than the upper arm should move maximum a full rotation (9600 steps > 10000) so he also hits the end-stop sensor.

    Does anyone have a homing string that actually works with their scara so I can try this on mine?


    Hi bram

    i think you are wrong, if you unplug the upper motor it still rotates because it is dragged over the belt, try to send in ip/cnc… a g code that moves each arm separately in both directions


    Hi Geri,

    I made a video where you can see:

    – if I push “X-100”, both motors are turning
    – if I push “Y-100”, both motors are turning

    this is the same if I run a pattern

    BUT if I push “Home all”, motor B isn’t turning…

    video movements

Viewing 25 posts - 1 through 25 (of 28 total)
  • You must be logged in to reply to this topic.