In that case, I don’t think the timeout is the issue. The Z-axis isn’t moving anywhere close to two minutes or longer.
We just pushed out an update to the entire software stack (firmware, OS, web app) that has some improvements and additions to the hardware widget that should help alleviate some of these problems. Can you update your OS and try things out with the new widget? If things are still not working, please share a screenshot of your widget so we can recreate your settings to try and replicate the bug.
1 Like
I was just on the web app looking at the new version and noticed that I cant turn the auto update switch to the ON position.
when I click on the switch the only response I get is the “Save” button has the check mark next to it.
I will be updating soon and I might make a new post specifically for 3.1.4 bugs and issues. 
1 Like
@roryaronson @Gabriel @RickCarlino @Tim
I just updated to the latest OS, 3.1.4, and am experiencing the same issue. Fairly frequently when there’s an z-axis movement, it will just stop prematurely and then reset it’s coordinate to 0,0,0 regardless of what the actual location is. I’m attaching a screenshot of my settings and there are logs earlier in this thread.
Any help is greatly appreciated! @Cjaramillogrowsare you still having similar issues?
With these settings, the only explanation I have is a sudden reboot of RPI or arduino. Is there a log of only arduino output? Do you see at the time of the ‘getting stuck’ the lights on arduino flashing?
That’s interesting and makes sense. It does seem like some type of reboot is happening which is why it stops and resets the coordinate system. I’ll do a few more runs and keep an eye on the lights.
How would I get a log of only arduino output? I’m a little green with this stuff.
1 Like
I do that by plugging the laptop directly into the arduino. It’s not on the web app itself. I tend to forget that.
3 Likes
I’ve connected to the arduino via USB and realize I have no idea what I’m doing. Could you walk me through getting to the logs?
Also as I continue to troubleshoot, I’ve noticed that the movement fails most frequently when I run the attached sequence. Every time I run this sequence, it entirely skips the second absolute movement command and then picks up at the third absolute movement command. Shortly there after, I experience what I’ve been describing in this thread - movement abruptly stops and the coordinate system is reset to 0,0,0.
I’m really stuck here…
1 Like
You could try to add Wait commands between your sequence steps. It is known that sometimes commands get skipped when they are chained without waiting time.
I don’t know if this is a solution to the 0,0,0 issue but for me, this happens anytime my farmbot makes a move command but doesn’t fully complete it. for example: get caught on the tool bay.
it will tell me I’m at 0,0,0 even though I just sent it a move command to go 42, 394, 12 when it had gotten stuck.
Whenever it tells me I’m at 0,0,0 and the farmbot isn’t actually in the 0,0,0 position I originally started with, I’ll just manually move the X,Y and Z axis to the correct position.
A bit tedious but it helps me be efficient with making sure my commands always start with a constant 0,0,0 position.
I started to realize that if your farmbot isn’t perfectly within whatever 0,0,0 position you started with as you determine the exact X,Y,Z locations of your tool-heads then your move commands will be off.
I hope I explained that properly but just in case here is a step by step example by using the “mount tool head sequence”
Conditions: tool-head 1’s location is X42, Y394, Z12. (these coordinates were determined by making sure the 0,0,0 is constant. Y axis all the way to the right, X-axis all the way one side of the rail and Z axis is exactly 25MM higher than the tool bays height which is represented by the Z coordinate. (Z12)
So I issue a move command to pick up tool-head 1. The farmbot begins to move but gets caught on the tool tray - it tries to finish move command and then stops and says it’s at the 0,0,0 position.
I manually move it back to the 0,0,0 position I initially started with and noticed that the farmbot was about 10MM lower than when I had initially established tool-head 1’s position.
as a result, everytime I establish a sequence or issue a move command to pick up the tools I must correct the Z axis’s 0 position so that it’s in the exact 0,0,0 position I used to establish the tools coordinates.
because the farmbot thinks it’s in the 0,0,0 position after the failed move I needed to make some kind of marker so that I can tell if the farmbot needs to be moved the original starting position.
I’ve added 2 pictures for reference.
So as long as my Z axis tool head mount is touching the zip tie taped (the thin black line extending to the tool head mount) to the X axis rail mounts then I know any sequence I execute that involves a movement of the Y and Z axis is going to constant.
and as long as the farmbots y-axis is all the way to the right and the X axis is where it is at within the picture. Than all of my move commands should be 100% constant.
this has severely helped me with progress on the sequences.
I do wish to pose a question to the Devs.
how can we establish something that allows the farmbot to recognize a preprogrammed 0,0,0 position giving to it.
would that be involved within the encoders and/or the “length” variable area within the hardware settings?
so that users wouldn’t have to always predetermine and establish that the farmbot is in the original 0,0,0 position used to establish coordinates within its range of movement.
Sorry if this is hard to understand, Been a bit rushed here at work.
I can clarify any details tomorrow morning!
Farm On!
-C
That would explain a few things if indeed encoders are used. In the previous and current version, if it gets caught on something when moving towards the home position, it assumes it’s already back home and sets the new 0 at that location. I’ve noticed that giving troubles sometimes in the big version (not my previous mini test machine) and removed the code in the version in development. I can tell you what lines to remove too if you want to update yourself directly to the arduino. Alternatively, you can increase the number of allowed missed steps so it doesn’t see a rough patch as getting stuck. That all assumes you enabled the encoders.
In our recent release however, we did improve homing using the encoder. It worked great on my machine. The bot will move back to the home position and move until it feels it can’t go any further. That becomes the 0 on that axis so the need to manually move back to 0 should be gone.
1 Like
For assuming direct control, it’s easiest to install the Arduino IDE. Open the IDE and plug in the cable between computer and arduino. Go to Tools - Port and set the port used. Go to Tools - Serial Monitor. Set Baud to 115200 and line ending to Both NL & CR.
Now you can type in the top line of the screen. G00 X100 Y200 Z300 will move to 100,200,300. F11 will home x axis, F12 the y axis, F13 the z axis.
1 Like
I’m going to try and test this out today.
I will definitely ask you what lines ill need to remove/add to make these changes later.
For the next few hours I’ll just increase the step count so I can prepare to show the farmbot off today to some of the school districts.
I’ve completed assembly and testing the controls. I’m playing with the axis and checking if motor settings are okay.
Testing the Z-Axis was a bit tricky at first. It only accepts negative positions, so using the web app I enabled positive positions. I have “bottomed out” the axis, then pressed “Zero” on the Z-Axis, and turned “negative only” back on.
I figured, that way I can always “bottom out” again by going to “zero”.
Then I told the bot to go to -400 on Z-Axis. While it’s moving, the web app updates the text box with its current position in transit. At -267 the arduino reported “stopped” but the Z-Axis kept moving to -400.
I heard some clicks, and now my farmbot thinks the Z-Axis is at 0 but actually it’s at the top. And since it won’t accept positive positions anymore, I can’t move it back down unless I re-do all the steps I wrote above.
This happened twice now doing the same things. It seems the arduino stops and starts during “long” travels.
As a note, I’ve noticed that sometimes I just hear some clicks of the motors, and the Z-Axis beeping noise (from being constantly powered) goes away, then about 10 seconds later it’s back.
I think the system power cycles or something. I have some horrid wifi coverage in my attic, where I’ve built the FarmBot.
Could it be that the bot reboots when it loses internet connectivity?
If so, is there a way to prevent the farmbot from re-zeroing all axes? This will be a problem in the future otherwise.
this has been a current issue I know some of us Farmbot users have been experiencing.
Sometimes the farmbot does get confused and thinks it’s at the 0,0,0 position after a failed move.
but it’s more than likely possible that the location of your FB is affecting the WiFi connections stability.
As a first step,t you could try to hook up an ethernet line to the FB and see if that helps the movement issues - If it fixed the issue then at least you know its the WiFi connection.
Here is a video of Z-Axis misbehaving. I can reproduce this issue reliably every time by doing these steps:
- Power off, position all axes as seen in start of video.
- Power on, bot is at 0,0,0
- Move absolute to -800, 800, 400
- Bot moves as seen in video
- Go back to 0,0,0 (NOT homing, because that makes each axis go individually)
The Z-Axis starts to spaz out when X and Y finish their travel. It looks like Z is missing a lot of steps, causing the Axis to slowly drop down again. When Z starts to decelerate, it picks up again and goes up slightly.
- Bot now thinks it’s at 0,0,0 but it’s more likely to 0,0,250.
Video: https://drive.google.com/file/d/0B8PVEtF0Y5mNQ2F3QUNxVC1JY0k/view?usp=sharing
So it’s the Z axis that’s making that sound at 0:33 within your video?
for some consistency, I always center it manually and then hit the “Zero X, Y and Z” buttons and a means of electronically letting the farmbot know its @ 0,0,0 now, instead of starting up the farmbot and letting the farmbot determine that its starting position is 0,0,0.
this may actually not have much of an effect but I feel like the farmbot respond’s better if you give it a home x,y,z input from the hardware settings page.
as a whole, whenever you are executing sequences make sure the farmbot Z axis has “negative coordinates only” toggled on.
whenever you are giving it a move absolute through the “controls” tab you may need to toggle the switch for specific input movements to get the proper response out of the farmbot.
good on ya with the video - that really helped get an understanding of what exactly is happening.
just in case let me see get @Gabriel - He has the hardware knowledge and know-how to possible better provide a solution to your problem.
Yes.
That depends how your wired the power cable. I have yellow on top, so that I can use positive coordinates to go down. Matter of preference I suppose, and it might have exposed an edge case.[quote=“Cjaramillogrows, post:40, topic:1760”]
whenever you are giving it a move absolute through the “controls” tab you may need to toggle the switch for specific input movements to get the proper response out of the farmbot.
[/quote]
I’m aware of this. That’s why my X is going negative at the moment, it’s just how I’ve set it up in this room now.