X-Axis Movement Erratic

I have a Genesis system running v1.3 at a local middle school. We have been running the system for many months with little issue. The system has suddenly begun having issues with the X-Axis movements.

Specifically, movement in the negative X-axis direction no longer functions, regardless of whether the distance is manually entered into the Move box or entered using a jog arrow. Movement in the positive X-axis direction occurs properly, and all negative/positive movements along the Z and Y axes as well.

I have done incremental troubleshooting making single changes in Devices for Homing, Motors, and Encoders, as well as belt tension, wheels, etc. Images attached to show our current settings.
2-25-19_BMS-ImagesSystemConfiguration.docx (472.2 KB)

At a loss for what next to do. Critical we get the system operating quickly as students are scheduled for a demonstration/PR event end of the week.

Does it even start moving? Usually it should try 3 times to move to the position. If all tries fail, an error message should pop up. I guess your axis stutters or even completely blocks when moving backwards right?

Your Hardware settings are looking good to me, but I noticed that there are no AXIS LENGTH values. But that should not cause the issues that you experience.

Try to observe the gantry wheel plates while moving, they might tilt if the wheels are not properly adjusted. Also keep an eye on the gantry main beam. If one motor stutters, it will skew until the motors are stalled.

Good questions. When a command to move in the negative X direction is sent, absolutely nothing happens. No attempt, no stutter, and no sound. This does not occur if commanded to move in the positive X direction, or for any other Y or Z movement.

Also observed that when positioned at Home, the negative jog arrow is often “not” active (greyed out) in the Move panel (all other jog arrows are active). I am baffled.

Oh great, thats a really important information. So this sounds like your issue is based on software side.

This is an intentional function which should provide the user to send the bot over the rail limitations. There is a setting in the hardware settings where you activated this.

This also prevents your bot to move in any negative position except the Z-axis. This behavior is the same for moving to the other end of an axis. But since your axes are not calibrated yet, it would run endlessly in max direction.

So you don’t receive an error message when the issue appears? Just the message that was seen in your documentation file, similar to this one:

Interesting outcome regarding “error message.” We actually don’t get an error message, but instead a Success message for the negative X movement.

In other words, we send the command to move -100, the system does NOT move, but we get a Success message indicating it did move -100.

If a software issue, what corrections are necessary?

These are my logs, when I try to move beyond the 0 point. The software prevents reliably from moving to the given position.

You can deactivate the setting, which prevents you from moving to a negative position by toggling the switch STOP AT HOME, but I cant find a reason why this would be needed. Why would you even try to move in negative?

We use our system for design based teaching/learning purposes (as opposed to simply growing plants), part of which is teaching 3-dimentional thinking.

Our system is constructed with Home for the UTM in the right-hand corner of the raised bed. In Cartesian coordinates, as our system is constructed, moving left from Home along the X-axis from this point is negative. This is in line with our teaching students to design within the coordinate system.

I will try deactivating the setting by toggling the STOP AT HOME later today when I am back on the middle school campus.

Many thanks for the feedback on troubleshooting the X-movement issue. Your suggestion for deactivating the STOP AT HOME did the trick - system now moving normally.

1 Like

You might want to invert the motor and encoder direction to get your homing position on the right end, as this was discussed in this thread: Problems with farm bot's coordinate systems

Maybe I’ve got your intention wrong, but this sounds pretty much the same.

Good luck farming! :seedling: