Home and reference position issues

After spending all day ‘enhancing’ my unit with signal termination and adding end stops (for accurate homing reference points), I tried to home the machine. This is consistent:-

  1. Home the Y axis, which moves slowly towards the sensor, and stops when it’s activated.
  2. Via the controls move the Y axis to position say 500.
  3. Back into device page, and home the X axis… which homes, but the Y axis moves back to zero! What’s going on? If I home/move an axis no other axis should move, ever.

Also, when homing the X axis it gives two speed surges before settling down to the crawl speed.

Here’s a suggestion (based on what other CNC machines do); move at a modest speed towards the home sensor, stop when it is activated. Then move away at a crawl until it is de-activated. That then is the accurate reference position.

I could go on, but I realise you guys are working hard to address these problems with limited resources. I could help but I’m not sure what the process is. Maybe I’ll just keep testing things and feeding back the information/suggestions. It’s not meant to be a complaint so please don’t take it that way :slight_smile:

The movement of other axis while homing another is fixed for the next firmware release.

The speed burst thing I have never seen myself. Is that only with X axis? Does it happens always or in some circumstances?

The way with backing up after hitting the end stop is good. But currently encoder is highest priority.

I am currently stuck with similar problems. Farmbot is up and running but I really do not about the homing philosophy.
If I try to calibrate an axis, it moves until the end of the axis, runs into slipping of the motor and then sets whatever
point for zero.

I did not find any axis systems, zero descriptions, calibration philosphy with the currently shipped and supported
encoders etc… This way one cannot carry on with bot because everything in this system needs realiable positions.

Should I wait, are you working on the software to address these big issues, what is the way forward?

Thanks, Best

I believe that the farmbot team is working on this issue pretty hard and have recently released some much needed improvements to the software in this area.

With that being said, in another thread Rorary has indicated the road map is for them to move to their own arduino ramps replacement board and then to add hardware counters to that board – over a couple of releases. I don’t think they will be able to use the counters for positioning until that new board is available, but you might want to ask them to be certain. I’m just trying to related what I thought I read.

Additionally, they are adding some sequence commands to allow you to ‘reset’ the home position during a sequence of steps -> so that you can account for slippage and be able to more reliably change tools in a longer sequence.

Finally, I think the system really needs home/stop sensors. Some of the builders have added “end stops” to their machines. Without them, it will be pretty hard to get reliable homing with just the steppers are there are a lot of variables that steppers alone might not be able to overcome.

Final issue is that the encoders have “differential” drivers, but the current setup only uses one end of the differential pair. At least one builder has built his own board to terminate the differential pair and then drive the RAMPS board with that output. With longer cable runs and higher EM noise environments it will be hard to sample the encoders fast enough to debounce the noise without both ends of the differential pins being used --> until they move to hardware counters.

1 Like

My biggest concern at the moment is really that this topic seems to be (I would be very happy to be
convinced in the opposite direction) THE flaw in the system architecture.
Momentarily it seems as the encoder homing option itself is not reliable to use the farmbot at all.

Moreover it is a big pain today to home the farmbot again after each power cycle. That just takes ages when trying out
things, debugging etc…

If the things need to drive into a physical hard end stop, this is completely useless. You´ve got mm readings which are off
when doing this. Especially on the x axis, x1 and x2 are behaving differently… You need to at least have one explicit and
very precise zero point, like with endstops… The flex coupling on the Z axis is enlongated if you drive into the end stop, this is some mm of distance which is completely off afterwards…

Just imagine having something hitting the bot in normal operation while it is standing still. Bird, Wind Gust (?)… This could shift e.g. the gantry for some mm. This is not noticed by the encoder at the moment and I don´t know if it would be possible?! If you then trigger an autonomous tool pick up sequence unsupervised you can break many things by driving
into the tools bay with an edge or the camera or or or… :frowning:

The software concept side does not reflect the whole situation at all at the moment - from what I know…
nor is there any concept which creates kind of prohibited areas in 3D space. Just imagine that it plays a very important role which axis you move in which order in the sequencer to grab the tools. Otherwise you would hit the tool bay first, or some restrictions from the raised bed, or or or… If you could set up a prohibited 3D space, the system could be intelligent
and not run into any sort of obstacles… this would be needed if that system should operate autonomously at some point I believe…

I don´t want to be negative and rather trigger conversations on this very very important topic. Maybe I do something completely wrong, which I don´t believe at the moment…

Edit: I do wonder how @roryaronson is using his farmbot all the years?! Do you only water autonomously and do not change tools at all?


IMO crashing the gantry into the frame will not produce an accurate home position, so you must use an endstop. You only need one per axis for the home position, and ignore the calibration (just make sure you know the dimensions of your farmbot). But it still isn’t that simple, the endstop must be used correctly as I’ve alluded to previously. In fact, once the zero position is found it is recommended to then move 1 or 2mm away from the sensor so that the actual zero point is definitely off the sensor.

In testing, I’ve noticed that the end stops aren’t always honoured in the software, I’ve had the machine move through a sensor into the frame :frowning:

The FarmDuino upgrade is good in that it is completely compatible with the RAMPS, and adds the correct electrical termination for the encoder signals. But again, that’s only part of the problem; you still need to sample the encoder at a faster rate than the fastest pulse… and that’s only barely possible with the AVR. Adding a hardware counter… that’ll be better, but really why not just engineer the board to fix all of the problems (the stepper drivers are also a problem, but I’ll save that for another time), some modern microcontrollers have encoder counting support built in.

I’m making some modifications to my machine (including getting it under cover because it’s not really weatherproof). I’ll post the results when I make more progress.

This appears to be exactly the same problem we have with our Farmbot, it won’t calibrate with encoders. In fact it seems the problem is that it won’t set a home position to begin with.

Moving everything to the centre of Farmbot and setting as home, once the home button is used all motors merrily travel off to the extremes of Farmbot and don’t even turn off at the end of travel, which requires either switching Farmbot off or using e-stop. Either of which dump you into a 15-20 min (sometimes even half hour wait) for a system reboot and reconnection - which isn’t good when trying to debug.

It’s all well and good saying ‘used end-stops’, but the kit doesn’t include end stops and even if it it, as far as I understand it, using encoders would enable Farmbot to turn the motors off wherever it gets stopped by an obstruction, which is the better alternative.

I assume the ‘time out’ option should stop the motors if they aren’t moving after the time-out in seconds? But that doesn’t work either.

I hope the Farmbot software guru’s get a solution rapidly, because as shipped Farmbot just doesn’t work properly. But I just can’t believe it would have shipper without the shipping set up being tested, or if the encoders are still in Alpha, at least including a set of end stops with instructions.

Another area which could do with urgent consideration is documentation concerning set up, calibration and general Farmbot commissioning. At the moment it’s threadbare and woefully inadequate, at least compared with building instructions which are on the whole adequate - although we’ve already discovered a few better ways of putting things together :slight_smile:

Did someone manage to solve the issue of homing/calibration of the Farmbot with the encoders?

Hi @Diogo,

I am using encoders and it worked for watering more or less so far. I did not bear to use it for tools pickup, as I have to rework my toolbay anyhow (only on wooden beam which is not properly attached).

However, all the other topics which popped up kept me busy in not getting to the point to have time for the tools pickup thingi. At first the Raspi WiFI was disconnecting itself regularly, at the moment this seems to be stable, maybe something changed in 5.0.1. or 5.0.2. At the meantime with the new version 5 they improved encoder functionality (whatever that means) but in my case the bot was then stuttering… Now they completely mixed up the web frontend (I believe, nobody is answering) which prevents the bot from operation as well…

What´s the background of your question?

Having similar issues with homing and calibration (Y and Z axes will not stop after arriving at home and continue to spin unless we E-Stop and start all over). I’ve had this thing for 7 months now and haven’t been able to get a simple watering sequence to work reliably, super frustrating.

1 Like

could you please share a screenshot of your settings?

I’m in the process of defining the reference point of the machine. The encoders should make the motors stop when the structure reaching the physical limit but it just keeps bumping against the ends. I have the latest Farmbot OS, encoders are enabled but I’m still having all these problems with homing/calibrating.

Getting a solid reference point is mandatory for any CNC machine and without it I cannot use Farmbot properly. I would assume that this would be of extreme importance to fix but in the forums I don’t see any solutions… Also the vacuum pump is on all the time, even if I turn it off using the peripheral ON/OFF option but that’s a minor issue.

Thanks for looking Klimbim. Again, having trouble getting Y and Z to stop while homing, they just keep trying to move past the end cap.

If you send a command to move an axis in one direction from about the middle of the axis, then push it back manually in the opposite direction while it’s moving, how does it respond? Does it stop moving, or continue trying to move?

Hey @Gabriel, the motor continues trying to move even if i manually try to stop it. Is there a setting to tick that on that I’m missing?

It sounds like the signals aren’t being received from the encoders. Check your encoder wiring (part of this topic may help). You should be able to see the positions of the encoders if you enable the views in the Move widget settings (screenshot) on the Controls page.