Help with stepper motors/arduino

My genesis came last week and I just finished getting everything wired up. I was able to connect to my.farmbot.io with the configurator, but the motors wonā€™t move from the Controls page. There was an update for the firmware when I checked from the Device tab and it seemed to succeed. Two things I noticed: all the toggle switches in the Hardware section are yellow and donā€™t change when I hit them, although sometimes it gives me a message that the toggle command has been sent to the farmbot:

Also, I saw in other posts about plugging in end-stops onto the Ramps board - but in the instructions here there was no mention: https://farmbot-genesis.readme.io/docs/plug-everything-in

Help?

Hey @bonanzajellydog

it seems like your Farmbot wont get any information about hardware parameters.
All those ā€œ---ā€ values and yellow toggle switches are like this as default until any parameters from Arduino are received.

Is your Arduino connected properly to your RaspberryPi (via USB)?
Also make sure that your Farmbot is connected properly with your Webpage.

Actually your Farmbot should move without those endstops. Obviously you can still plug and use them already to secure your hardware from damage. I would recommend this for sure, since sometimes the arrows in the Control page dont fit the actual moving direction and may cause a crash. Were mechanical endstops delivered in your Genesis Kit?

If you are using mechanical endstops, use the four pairs of pins that are marked with different colors in the picture below.

So if this works for you and there are endstops beeing shipped out with the kit, we should think about adding this to the docs.
If this does not work for you, or something is not clear, feel free to ask us :slight_smile:

Thanks, @Ascend

That is very helpful. I moved the USB cable coming from the arduino to a different USB port and I now have movement - although itā€™s only going a few centimeters in any one direction.

The Genesis kit did come with what I think are endstops

but when I installed them on the pins you point out I get no movement at all. They cover/connect two pins but your illustration shows 4 sets of 3 instead of 4 pairs, so maybe I picked the wrong pair? As you can tell, Iā€™m brand new to arduino, so what do I know :slight_smile:

Leaving aside the end stops, do you have any idea why Iā€™m not getting any distance? At least once I got log messages about missed steps, but again this was after a very short distance.

Thanks again for all your help!

Oh right, those are bridges. They are supposed to short-circuit the endstop pins :slight_smile:

So in fact you dont need real mechanical endstops since your kit includes Rotary Encoders. They are used to monitor the steps of your Motor.

Actually I am not sure if it those bridges are needed software-wise. Still I would recommend to connect them as seen on the picture below (In Picture they are blue).

This may not be your only problem. When there are error messages about missing steps, there is a problem with expected steps/real covered steps.
If this problem persists, check if you turned the options Enable Encoders in the Hardware section of Devices tab on (if you didnā€™t install encoders yet).
If your Encoders are Installed and connected, there may be an error somewhere.

You are welcome :grinning:

1 Like

Thanks! The Enable Encoders setting was the issue. I disabled those and enabled endstops after installing the jumpers and it moves now. I do have the encoders installed, but I read in another post that there might be an issue with the encoders in the current firmware (?)

I do think I also need to tighten up the belts on the X-axis because Iā€™m still getting stuck, but Iā€™m better than I was before.

Thanks for all the assistance!:smiley:

Those are great news! :tada: Unfortunately I do not use encoders yet, since they are hard to get here in Germany. But as far as I know the encoders should work soon.

Sure it takes some time to setup and adjust all the parts until they fit perfectly together. But this helps the user to learn how the parts work and how changes affect the performance and stuff.

If you run into any kind of trouble, feel free to ask us :slight_smile:

The end stops are in the latest updates disabled by default. The pins are ignored. It used to be an issue with the older versions, where for some reasons (moisture in the air or static electricity?), ungrounded pins would read as high, what is seen as the end stops being activated and the bot refusing to move.

1 Like

@Tim

Iā€™m afraid Iā€™m confused again. If I donā€™t have endstops or encoders enabled, how does it know to stop when it reaches the end of the line? What should my device settings be set to for optimal use with the genesis hardware?

Iā€™ve never been able to get it to calibrate successfully either - it just goes to the end and then spins until I issue an e-stop. Is there a way to set the axis lengths manually?

1 Like

With endstops and encoders disabled, FarmBot should be able to move around fine. Weā€™re still working on firmware-level encoder support, and you are correct, without either encoders or endstops enabled automatic calibration cannot get the information it needs to work. You can manually move FarmBot to zero before booting the device. You should never be telling FarmBot to move farther than an axis allows; setting the axis length is currently not necessary.

Weā€™re working on the hardware settings widget right now, and will have some updates soon that will fix some issues, clarify some of the settings, and add some new options.

Thanks, @Gabriel! Looking forward to the new widget.

We have recently released an update to the firmware and the web app, adding many new features including a new hardware settings widget. You may enable encoders and use the homing buttons to have the bot automatically find home for each axis.

The latest FarmBot OS image can be downloaded here, with the new features available at my.farmbot.io.

??? More likely just leakage current in the micro input. If you donā€™t terminate the input signal then the input state can be either high or low (or mid-level taking lots of current), the data sheet specifically cautions you against using high impedance inputs. Ideally, none of the microcontroller pins should ever leave the board without ESD and EMC protection. Are the internal pull-downs enabled on these inputs? (they should be)

FYI, an ā€˜end-stopā€™ switch should have a wetting current ([Wetting current - Wikipedia]) to stop it failing, that is a high voltage (>=12V) and a current of at least 10mA (this serves to clean the contacts when they make). You then interface that into the micro using a buffer/transistor. In industry weā€™d galvanically isolate as well, but thatā€™s probably unnecessary in this application.

The same is true of the encoder inputs, the encoder manufacturers have gone to the trouble of providing a nice differential signal for you, which is great for noise immunity when running the cable parallel to the noisy stepper drive current switching. But thatā€™s all to no avail if you connect the inputs directly to the micro! A differential receiver is required to convert the differential signal back to single ended, before connecting to the micro. Presumably youā€™ll be doing this when/if you do your own electronics?

Iā€™ve just ordered some UA9637ACP chips to interface the encoders, proper cable termination is also important (the cable has an impedance around 150R, so needs terminating similarly). If this goes well I might consider getting some PCBs made with these interface enhancements, anyone else interested?

Yes, itā€™s leakage current on the not connected pins. The hardware design got changed for using encoder instead of end stop during development so that ended up reading unconnected pins. It does get influenced by environmental factors. Indoor on the test system there was never an issue. Outdoor it depends on the time of day and weather. Using pull down inputs doesnā€™t change the solution of ignoring the pins in the software as that pull-down results in an always one on an unconnected pin.

Encoders also has some history. Originally the testing and development was done with a non-differential encoder but for noise immunity indeed a differential encoder was used on the hardware, although without decoding hardware. The differential check can be emulated a bit in software. But @roryaronson and @Gabriel have plans to add the decorder chip to the new design with a shield and/or custom PCB. If youā€™re willing to cooperate with them, please do

Hi Tim,
Thanks for the reply. Yes thereā€™s always history and backwards compatibility to cause problems! Just to clear up the differential signal; this is electrical, nothing to do with logic/function, so no the software canā€™t do anything to help. Itā€™s the same signalling as used in RS485/RS422 and USB. Really good that the encoders are differential, but as I said, not much help without the ā€˜other endā€™. Iā€™ve just added differential receivers to my build, but I seem to have plenty of other issues too, just badly performing home/calibration and movement. I might put the logic analyser on tomorrow and see whatā€™s really happening (itā€™s outside, so Iā€™m reluctant to take the expensive test equipment outā€¦).

I think the concept is great, and I realise youā€™re still in the relatively early stages of development, so Iā€™m keen to help. I have plenty of experience in stepper motor control (although I last used an AVR for it more than 8 years ago, all ARM cortex these days). Interestingly, many of the STM32F devices have plenty of timers, all of which handle encoders directly, so they would be ideal if you were prepared to change micro (and/or use a co-processor).

The other area which doesnā€™t seem to have had any thought, is EMI compliance. If you want to sell a product you need to be compliant with FCC regulations (in America) and CE requirements (in Europe). Youā€™re probably fine with a ā€˜prototypeā€™, but once you move past that stage then youā€™ll need to demonstrate compliance (and indeed be compliant!).

Should I contact @roryaronson directly with an offer of help, or are you guys overwhelmed with input at the moment? :wink:
Jon

1 Like

I think itā€™s best to contact Rory directly.

Encoder handling seems more to be more a matter of timing. Iā€™m improving speed of encoder sampling with some tricks as weā€™re hitting the limits of the arduino hardware.

@Loveny my email is rory@farmbot.io. Regarding certification, yes the custom electronics board weā€™re developing will undergo testing to get the needed certifications prior to being sent to anyone.