Can't control printer via USB
Good morning, and welcome to 3D Printing SE.

You said: "I can see information from the printer via USB in RepG and through OctoPrint, but can't send any prints, commands or upgrade firmware (I wanted to flash Sailfish 7.7 eventually)."  This means that the USB communication is working fine.  It isn't a question of drivers or the FTDI interface chip.  That must be working fine or you wouldn't have any USB communication.

I would look toward a problem with slight dialect differences in the firmware that is flashed compared with the expectations of the host software.

I am not an expert regarding the differences in firmware G-code dialects, but there are at least: Marlin, Repetier, Mach3, LinuxCNC, Machinekit, Smoothie, Makerware, Sailfish.  I got this list from the "about" page for Slic3r.

I would start by trying to slice files with different dialects and seeing if one of the resulting G-code files prints.  You may also find a description of the firmware you have flashed with references one of these names, which would save a lot of time.

For flashing, you could try dropping back to the Arduino level and use those flashing tools.



More answer in response to the information you have added to the question.

X3G files are not G-code files.  If you are using a control program that expects G-code, it will not be able to handle X3G code.  Similarly, if the printer expects X3G, it may not understand G-code.

Octoprint has an adapter layer that seems to interconvert between g-code and GPX.  You are running this layer.  At about line 11 of the log file you added to the question:


  Recv: echo: gcode to x3g translation by GPX


The GPX add-in may be perfect, and it may cover all version of firmware and all functions.  I don't use it and am unfamiliar with it.

To flash your board, I would be reluctant to assume that Octoprint/GPX new how to run that protocol.  I would use the host software supplied by the vendor.  Flashing is an infrequent operation, and add-on software is less likely to have it 100% correct.  If I were writing GPX, I would intentionally make flashing be out-of-scope, since the consequences of doing it wrong could easily be to brick the printer.

Since Octoprint/GPX claims to be able to print to the printer, I would being all software up the respective current versions.  Flash current Sailfish firmware using the supplied host tools.  Update to the current/best version of Octoprint/GPX.  Read the release notes of Octoprint/GPX for known issues.

It seems that X3D files are fairly limited in their use, which will constrain your options to be within the scope of the community that uses X3D files.  I tried to add the X3D tag to your question, but so far no one has created the X3D tag.

Makerbot is part of Stratasys, and should be well supported.  It may be well supported mostly within its ecosystem.  You have a clone of a Makerbot machine, so, even though most or all of the printer parts are open source, you may not be able to use the genuine Makerbot host control software.

Your question asked if your controller board was working.  It almost certainly is.  I think you have a software/firmware compatibility problem.