I’ve got v1.2 hardware. The X2 encoder cable isn’t used according to the documentation.
However, when checking v1.3 documentation it’s clear that all 4 motor encoder cables are used (albeit with Farmduino). This makes me think the firmware is capable of using the X2 encoder, even if the hardware (and documentation thereof) is v1.2.
To which pins on the RAMPS board do I connect the X2 encoder cable pins?
I’m sad to hear that.
The v1.2 hardware included an encoder on the X2 motor and a cable for it. That tells me you had plans to support it in the future (why else include them?). Is there any way I can use the X2 encoder?
Customize the firmware. I guess you’d need to be sure that there was enough CPU capacity to handle the 4th encoder.
Just to clarify, if I remember correctly, at the time I purchased the FarmBot, encoders weren’t supported at all yet. Maybe the reason X2 was left out was because they bumped into CPU limitations on RAMPS, which must’ve been another reason for them to move towards Farmduino.
@mdingena I still own a v1.2 that I use nearly every week to do product testing on. I also own a v1.5. They both work fine with their respective firmware and you can trust me when I say that your device is going to work fine with the firmware that exists today. It’s just Gabe and I working on the software, and there are 40 hours in a workweek and 52 weeks in a year. We need to be judicious about how we allocate our time and unfortunately, that means that we need to say “no” to some ideas. We don’t have the resources to add support for a second set of encoders on a platform that is almost 5 years old and works fine for its intended task.
This is not the first time we’ve preemptively added extra hardware that ended up not getting firmware support. Other examples include the AUX motor slot, a voltage sensor for the vacuum port (we have ambitions to someday add vacuum load sensing, but that’s not guaranteed), and a few more I can’t remember off the top off my head. Mentioning or including hardware is not a promise that we will add software support.
If you feel like experimenting, it might be possible to add second encoder support to the Arduino on your own by forking FBOS, but last time I checked there is very, very little memory left on the device once the standard firmware is flashed.
Hmmmm . . someone’s tired 
Not sure I follow. It’s been a while since I’ve been in that corner of the codebase, but I think you would need to fork FBOS (not just the firmware) since the firmware hex is hardcoded in the release and gets reflashed on boot. That is to say, it’s not an independent component from FBOS as it was in previous releases.
Another option would be to: remove the FBOS SD card and copy/paste over /srv/erlang/lib/farmbot_firmware-0.0.0/priv/arduino_firmware.hex in the root partition. I could write up some docs if there is interest.
Just being very pedantic 
The firmware changes would be done in a clone or fork of farmbot-arduino-firmware primarily.
I’m interested. Requires some “squash” tools (?)
I haven’t tried, but I would imagine. I wonder if I could add a special option to the none firmware to make this easier since working with SquashFS could be a hassle (and probably have some unintended consequences, come to think of it).
Perhaps we could add a “magic firmware file”, such as firmware.hex that lives in the /root partition and is used as an override to the default firmware. Alternatively, we could put the magic file in /root to prevent Windows users from needing to use special tools to read the EXT4 /root partition.
We went a very long time without any requests for special firmware, but it seems that as of late we are getting more people who are interested in writing custom firmware, especially at universities. This might be a quick solution
I didn’t find the process too onerous.
One-time steps
CRUD loop ( Code-RUn-Debug- ) 
.hex file over to correct FBOS dir^ Big endorsement for Frank Hunleth’s superb ssh_subsystem_fwup . . but Mix’s upload.sh does the job.