4
$\begingroup$

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.

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ It appears you may have been correct in your conclusion of either patched or corrupted firmware. Flashing the ATMega1280 via ICSP lead with the latest sailfish .hex file has resolved the issue. I can now use OctoPrint / GPX to upload G-Code from any slicer and convert to the printers X3G on the fly. $\endgroup$ – AvieRose Jul 5 at 14:10
  • $\begingroup$ Thanks for the confirmation. Its useful data for others. $\endgroup$ – Sean Houlihane Jul 5 at 15:17
5
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Thanks for the input, but I know the printer reads .x3g files (makerware) already & have indeed managed to print several sucessful models via an SD card, just not through the USB interface. I have updatedmy question with more information. $\endgroup$ – AvieRose Jun 26 at 14:26
  • $\begingroup$ tag added. Please provide a description for it. $\endgroup$ – Sean Houlihane Jun 26 at 15:07
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ This doesn't seem to be the case since some aspects of the interface are reported to work. $\endgroup$ – Sean Houlihane Jun 25 at 14:28
  • $\begingroup$ I'll give anything a shot at this point, but I don't think this is likely to be the issue as I run into the same problem when using my OctoPi set-up which is running on a linux distro. $\endgroup$ – AvieRose Jun 26 at 14:31
  • $\begingroup$ Also, generally make sure to buy products without (cloned or legitimate) FTDI chips. From what I could find online, it seems to be ATmega8U2-based though. $\endgroup$ – towe Jul 5 at 10:10
  • $\begingroup$ @towe - FTDI chips are OK, aren't they? What's wrong with them? Although I must admit that I prefer 16U2 ICs for the USB (better than the awful CH340[G]) $\endgroup$ – Greenonline Jul 5 at 15:28
  • $\begingroup$ @Greenonline Genuine FTDI chips are fine, but you will find clones on many Chinese products that are not as performant, and that will not work with some FTDI drivers. Google "FTDI driver fiasco" for background information. AFAIK, drivers distributed through the Windows update channel will not work with cloned chips (although they no longer brick them). $\endgroup$ – Mick Jul 5 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.