Can't control printer via USB

Question

I've recently purchased a Makerbot Replicator Dual clone made by CTC. I'm in the process of upgrading/adding a few parts to it, but noticed that I can't control or print via USB.

The machine prints perfectly from an SD card and I can see information in the terminal from the printer via USB in RepG and through OctoPrint - Such as M105 - but can't send any .x3g files to print or upgrade firmware (I wanted to flash Sailfish 7.7 eventually).

To clarify;

In Octoprint

• Temperature auto-reporting is working
• Can send M105, M27, etc.. & get response
• Can select .x3g files from the SD card to print & the printer starts
• Can upload files (.stl, .x3G, .gco etc..) to Octopi, but even the .x3g files wont actually start on the printer.
• Tried sending M140 T0 S200 & M106 T0 S100 which received OK response, but there was no change reported, or indeed actually happening with the tool

Terminal Output from OctoPrint at connection:

Changing monitoring state from "Offline" to "Opening serial port"
Connected to: <octoprint_GPX.gpxprinter.GpxPrinter instance at 0x6c9a02d8>, starting monitor
Starting baud rate detection...
Changing monitoring state from "Opening serial port" to "Detecting baudrate"
Trying baudrate: 115200
Recv: start
Send: N0 M110 N0*125
Changing monitoring state from "Detecting baudrate" to "Operational"
Recv:  Makerbot v7.4
Send: N0 M110 N0*125
Recv: echo: gcode to x3g translation by GPX
Recv: SD card ok
Recv:  T:27 /0 B:21 /0 T0:27 /0 T1:26 /0 @:0 B@:0
Recv:  T:27 /0 B:20 /0 T0:27 /0 T1:26 /0 @:0 B@:0
Recv:  T:27 /0 B:21 /0 T0:27 /0 T1:26 /0 @:0 B@:0
Recv: ok
Send: N1 M115*39
Recv: ok PROTOCOL_VERSION:0.1 FIRMWARE_NAME:Makerbot FIRMWARE_VERSION:7.4 FIRMWARE_URL:https://support.makerbot.com/learn/earlier-products/replicator-original/updating-firmware-for-the-makerbot-replicator-via-replicatorg_13302 MACHINE_TYPE:r1d EXTRUDER_COUNT:2
Send: M21
Recv: ok
Recv: SD card ok
Send: M20
Recv: ok
Recv: Begin file list
Recv: 2GB
Recv: System Volume Information
Recv: mesh_bed.stl
Recv: xyzCalibration_cube.x3g
Recv: CTCB_3DBenchy.x3g
Recv: 3DBenchy.x3g
Recv: ActiveCoolingDuct.x3g
Recv: CTCB_ActiveDuctD4_UN.x3g
Recv: UK_TROLLEY_TOKEN.x3g
Recv: mesh_bed.x3g
Recv: z-axis-support.x3g
Recv: bed-screws.x3g
Recv: spool_nut.x3g
Recv: 2016_spool.x3g
Recv: 2016_spool_no_raft.x3g
Recv: ActiveDuctD4_UN.x3g
Recv: Z_Axis_Support_Ends.x3g
Recv: End file list
Send: M105
Recv: ok T:27 /0 B:20 /0 T0:27 /0 T1:26 /0 @:0 B@:0
Send: M105

In ReplicatorG

• The software connects to the board via USB and recognises that it is a Mightyboard running f/w 7.4
• Reports that it is an unvarified board
• Cannot use the GUI control tab to send commands to the printer
• Cannot send sliced .x3g files over USB, console shows a time out error instantly
• Saving .x3g to SD card does work

Is my Mightyboard just a dud, or is there something I can do to try and fix it?

The reason I want to try and solve this now, is that I'm planning on adding active cooling and LED lighting control so don't really want to do all that just to find out that I need to replace the board soon.

---

Additional info

Some information meaning that the current firmware and board is reported, as well as current temperatures of the extruders and heat bed. I can print .x3g files from the SD card, but I can't send G-code commands or .x3g files through USB.

I have just tried a few G-code commands through OctoPrint terminal with mixed results. M105 works, M140 & M106 don't.

Answer 1

You can find gcode information at the RepRap wiki. The obvious other thing to try is G1 X10 for a move.

Octoprint prints by sending the individual file's gcode one line at a time over USB. It appears that the firmware on your printer might not respond to any 'action' commands over gcode, rather than any fault as such with your hardware/software setup.

Although your board reports a specific firmware version, it is impossible to know if that firmware was corrupted, or patched by the vendor (and no change reflected in the revision print). Thus, your best option to regain full control might be to flash your own firmware using low-level access. I'm guessing that will require an ICSP lead.

The fact that USB works, and the printer works, tends to suggest that the board is properly functional.

Answer 2

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.

Answer 3

It is possible that your board has a cloned FT232R USB-to-serial bridge chip, and FTDI drivers supplied via the Windows update channel will not work with cloned chips. Try using the Windows setup executable from the following page:

FTDI Chip: Virtual COM Port Drivers

Note that there are no known problems with MacOS and Linux drivers.