Makerbase MKS Robin Nano and TFT 35

I have just brought 2 of the Makerbase MKS Robin Nano boards enticed by the TFT35 touch screen convenience and also that it is (I thought) easy to set up using only the touch screen and not having to be hooked up to a laptop or dismantling my MPCNC to take the RAMPS board to a pc for reprogramming. Also the appeal that I can just upload program changes to marlin through the SD card.

My RAMPS 1.6 started to reboot for no reason half way through jobs so I thought it was time to change and go with a 32 bit board. (Dragged into the 21st century) and touch screen convenience.

Everything was going swimmingly and my Primo working as it should very quickly…until I tried to get my Z touch probe to work. Than I hit a blank about how to set that up through the touch screen menus.
The manufacturers support has not been able to assist me except to say “try the Marlin Classic UI” which to me sort of defeats the point somewhat as I really like the way the touch screen is set up.

Also I can find no way to keep all the settings I have programmed thus far to get things going without having to do a complete upload of a new Marlin Build. I guess that sort of comes with the territory. Can’t have my cake and eat it.

I tried connecting probe to the Z min no problem, I set up auto level through the menu and it works to a point, i.e. sets the Z level, but then proceeds to try and move the X axis to a "home’ position which of course i don’t want. I cannot see anyway to stop that or to zero position.

Has anyone played with these boards and able to offer any advice. It says version 2.0.2

I have ready through all the documents and videos I can find but still none the wiser. if I cant work it out, then I guess I have to go with changing to the Marlin GUI.

The bad part of that screen is they have built in a bunch of their own routines, and gcode pings to the board it is connected to. Normally that would be awesome, but the firmware has that stuff scattered over hundreds of files so it is not easy to find and edit. so using that screen stock you will see all sorts of random errors pop up, but are mostly meaningless since we are not 3D printing.

So using the home Z button should kinda work, but really the better way to do it is just build it into your gocde. If you have a look at the milling basics page you will see how I do it. I home xy then move to the material, probe Z, offset Z, move Z, pause for probe removal and so you can turn on a router, and you can resume from the TFT Touch side. Once you have the routine you want/like you just add it to your CAM start gcode and tool change sections. I am pretty sure I show me using it in one of my latest youtube clips.

Thanks Ryan, The more I look at it, the more I think you are right.

Once I rescue another SD card from one of the Raspberries I am going to give it a try today.

Shoo, this is proving to be very frustrating. I just do not seem to be able to win. I have reverted to ‘classic’ UI reluctantly but even setting up the probe using the code that I got to work with Ramps, I am not succeeding.

I did not make it any easier on myself in mistaking the V2 software revision for the board revision so of course wasted most of the weekend panicking and wandering why I could not get the board to work after the first flash. Screen dead, I thought I had bricked it. Found out that I have the V1.2 board with V2.0.2 software. and not the V2 board which makes all the difference. Rookie mistake.



I am not giving up, going to try inverting the Z min next, waiting for it to compile. I got the extra menus to eventually work with the G38.2 code. I could not get it to do anything except go mad using G28 so at least now the Z starts to home, it just does not see the probe. Baby steps I guess.

Any one have any ideas what else to try? I am sure I am only one or two settings away from getting this to work.

My suggestion is get it working in Marlin mode first, leave the touch side alone for now. That takes more work.

Thanks Ryan, Yes that is what I am trying to get to work. Once I get that right then I will play with the UI. I am trying it with the classic UI which is the Marlin menu as we are used to with Ramps.

I am also trying to use the PlatformIO system rather than the Arduino compiler. Also trying ‘Auto Build Marlin’ but since changing to the Classic IO it takes forever to compile. Failed after 3453 seconds (1 hour almost) because it did not like one of the settings. I needed to invert Z_MIN_ENDSTOP_INVERTING as well as Z_MIN_PROBE_ENSTOP_INVERTING.

Left it to compile again. Will look in on it when I get back from work.

What a disaster. My poor old Computer completely crashed and refuses to reboot after the last compile.

I have reinstalled everything on another computer and having to start again from scratch. At least it compiles in less than a minute now, so there must have been something going wrong on the other PC.

I am still battling to get either “G28 Z” or “G38.2” to work. It just does not seem to see the probe I suppose.

if I program “G28 Z” in a custom menu, it will lift Z then shoot X & Y axis across the bed. It should not be doing that, it should only be trying to home Z. It worked on the Ramps but not on the Robin Nano.

Also, “G38.2 Z10 F100” in a custom menu tries to home the Z but does not seem to see the probe. It drops 10mm then stops even though it is resting on the plate.

Tried Inverting Z_MIN and Z_MIN_ENDSTOP_INVERTING but I don’t seem to be making any progress.

Any clues what else to try? It worries me that the G28 Z is not doing what it should.

I am really not sure what it could be. I have never used that board. What I can say is the settings we use for all the other boards are exactly the same. So if your setting match what we do, maybe you just got a bad board.

M119 should show Z open, when probe is touching it should show, triggered. If those are true and it still doesn’t work I am pretty lost and maybe that is some sort of quirk with that board or something.

This can happen in Marlin if the “Z_SAFE_HOMING” is enabled, where it tries to move the carriage to a “safe” spot before homing it. In the event that X and Y are not homed, it should generate an error (Insufficient axes homed) because it doesn’t know where that safe spot is.

From the configuration.h for my old printer:


  #define Z_SAFE_HOMING_X_POINT X_CENTER  // X point for Z homing
  #define Z_SAFE_HOMING_Y_POINT Y_CENTER  // Y point for Z homing

Commenting out the #define Z_SAFE_HOMING will disable the homing point in the center of the defined bed, too.

For the Z endstop, you will need to enable the pullup resistor. This will bring the pin HIGH when the pin is not connected to ground, and set it to trigger LOW.

From my Primo configuration.h:

(Some stuff that doesn't matter)
// Enable pulldown for all endstops to prevent a floating state
(More stuff)
// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).

This should deine the X and Y endstops to trigger HIGH (IE: connected to a NC switch. The switch grounds the pin when the endstop is NOT triggered, and opens it, allowing hte pullup resistor to raise it to HIGH when it is triggered. The Z_MIN stop, however is set to trigger LOW, so it will trigger when the touch plate connects to ground.

If your pullup resistor is weak (Seems to happen sometimes, as it happened on my MKS Gen L board) then you might see a Z probe trigger from you touching the touch plate. If it is broken, it might just trigger for no reason. I resolved this with a 1k ohm resistor between the 5V pin and the “S” pin on the endstop. This is less resistance than the normal resistor, but is more than enough to be safe for the board, and will definitely require contact to trigger the endstop state.

Thanks Dan & Ryan.

I cannot issue a M119 as it does not give me a display of the results. I do not have a laptop hooked up.

Dan, Thanks for the tips.; I reprogrammed the Z_SAFE_HOMING to


and that took care of the moving of the X & Y axis.

I still do not seem to be able to get the touch plate to work though. I have tried inverting everything and changing the settings of the Pullups and pull downs, but dont seem to be getting anywhere. I have double double checked continuity of the wiring with a meter and that it is correctly plugged into Z MIN.

Any point in trying to make it work with Z_MAX? Is that even possible?

If I issue a Gcode from the SD Card now I get the following if it gives any clues.

G28 now drops the Z axis about 10mm, X about 5mm + and Y about 5mm + then drops the Z axis towards the probe plate, stops before it gets there then lifts the Z axis until it cannot lift any further and i have to kill the power. This worries me as I would have thought logically, the Z would lift to start before moving the X & Y. I tried inverting the Z axis to see if that helps but just adds a new problem and still does not see the touch probe.

G38.2 Z-20 F100 just creeps the Z axis downwards really slowly, like you have to put your hand on it to even tell if its moving but still ignores the touch plate.

I fear now that I have changed so many things I have tied myself up in knots.

I would suggest that you comment out the Z_SAFE_HOMING definition. That way, when you home Z it will just do so from wherever it is.

Maybe upload a .zip of your configuration.h and configuration_adv.h

Without connecting something to get you feedback from the firmware, it will be difficult to troubleshoot what the firmware thinks is going on.

You could use a multimeter to see if the pullup resistor is working. Test the voltage of the touchplate and the ground clip. It should be higher than 3V if the pullup resistor is working.

Thanks Dan, I did come to that conclusion as well last night and have commented it out of the sanity.h part of Marlin to allow it to compile with out it. so have taken that out of the equation. I cant though remember what it was preventing me from doing having to include it. i know I had to include it for something else to be selected.

It might be time to get my mind around Pronterface and pull out the laptop.

I think I have probably hacked so many different bits now, I may have to get a fresh download and start again. I know from experience that you only need one wrong setting to stop it working.

I think I will try the pronterface route first though to see if that offers any clues. I guess I need confirmation that the probe is in fact being read even though the meter says it is.

Thanks for the assistance thus far.

Removing the sanity checks is probably not a great solution. They usually save me from myself. That said, I don’t really understand what is the root issue you’re facing, so maybe it is ok in this case.

I agree Jeff, but having spent so many hours trying everything else, I figured i did not have a lot to lose. It still did not help though.

I am going to try Pronterface and see if that offers any clues before resorting back to Ramps.

Well Pronterface helped me right a few wrongs from all the changes I just got myself all confused. It confirmed that the touch plate was at least working, but inverted AND I had the Z axis inverted as well so that combination has been resolved.

G28 will now work and sees the probe. G38.2 still refuses to work but I can live without that.

G28 Z\nG92 Z3\nG0 Z5 now successfully finds the touch plate, and lifts to Z5 and position is then correctly reported back as Z5 above work piece. Same as it was working with the Ramps 1.4

Oh joy and bliss.

I also also tried changing from the TFT_Classic_UI back to the Graphics TFT_LVGL_UI that the manufacturers did not think would work but everything so far seems to work as it should. If I go to the “more” icon there is my custom user menu to run my probe Gcode and it works. Then I jog my X & Y to where I want it, use the custom menu to zero X&Y and Hey Hey, we are cooking with gas. All ready to start cutting.

Now going to try and see if it will actually run a job.

Thanks everyone for the pointers that has helped, and anyone that wanted to try out the Robin Nano with touch screen, yes it can be made to work with the MPCNC and probe.


Plus now just discovered that my home made probe had a loose wire sticking out of the solder on the plug and was making an intermittent short as soon as the cable sat a certain way so that would also have contributed to the fault finding.

Just another curve ball to make it all interesting. Luckily Prontoprint made that one easy to diagnose.

I suppose the lesson learned here is that I must hook up pronterprint when trouble shooting and setting up for visual feedback and the ability to send Gcode commands that give a feedback that you dont get on the Ramps or the Robin display. Like results of G119.

I am SO close I can almost taste it. Hopefully the last issue if anyone can please give guidance.

X & Y Cutting speed is PAINFULLY slow. Like, I can go and make a cup of coffee and it has maybe travelled 10mm.

Jogging speed and distance is correct. If I issue a move X 10mm from the screen it moves 10mm briskly but when I run a Gcode program, it cuts SLOWLY.

Estlcam is giving the instruction to cut at 20mm/s so that looks correct - G01 X200 F20 but takes 5 minutes and 30 seconds in stead of 5 seconds to do the 100mm.

So distance is correct, just takes too long.

Your gcode needs to be in MM/min. If you look at the estlcam basics page you will see two different settings. One is for what your “program” in, and the other is what gets sent to the board.

20mm/s is F1200

Aha, Thanks Ryan, I lost all that info on the other PC when it crashed. Still not been able to get it to work, waiting for a new PC so I can move the hardware across and rescue all my settings.

Thank you., will give it a bash.

Thank you Ryan, you are a genuine Hero. That sorted it.

1 Like