Thing O Matic won't connect to Makerware

[Bence Blaske]

I have an issue with the latest Makerware (I had the same problem also with the previous one) that I cannot connect my Thing O Matic to Makerware.
I get the error seen in the screenshot.
I have a Replicator 1 dual which works fine with Makerware, and also ReplicatorG 40 Sailfish connects to my TOM without issues.
I tried updating the FTDI drivers, to no avail.
Any suggestions? Did someone get their TOM connect to MW? I know I could print off from SD card, but that's no the point. :)

Here is the log excerpt from the conveyor service:

2013-10-12 14:04:24,551 - INFO - port detached: COM5:1027:24577
2013-10-12 14:04:28,572 - INFO - port attached: COM5:1027:24577, 0403:6001:A9OFJ95DA
2013-10-12 14:04:30,852 - INFO - accepted TCP connection: 127.0.0.1:58831
2013-10-12 14:04:37,826 - ERROR - {"event":"machine_timeout"}
2013-10-12 14:04:39,229 - ERROR - {"event":"machine_timeout"}
2013-10-12 14:04:40,430 - ERROR - {"event":"machine_timeout"}
2013-10-12 14:04:41,631 - ERROR - {"event":"machine_timeout"}
2013-10-12 14:04:43,032 - ERROR - {"event":"machine_timeout"}
2013-10-12 14:04:43,232 - ERROR - {"event":"transmission_error"}
2013-10-12 14:04:43,232 - WARNING - uncaught exception
Traceback (most recent call last):
  File "python\conveyor-2.3.0-py2.7.egg\conveyor\jsonrpc.py", line 308, in _invokemethod
    result = func(*args, **kwargs)
  File "python\conveyor-2.3.0-py2.7.egg\conveyor\server\__init__.py", line 1147, in connect
    persistent)
  File "python\conveyor-2.3.0-py2.7.egg\conveyor\server\__init__.py", line 438, in connect
    machine_name, port_name, driver_name, profile_name)
  File "python\conveyor-2.3.0-py2.7.egg\conveyor\server\__init__.py", line 399, in _find_machine
    port, driver, profile)
  File "python\conveyor-2.3.0-py2.7.egg\conveyor\machine\__init__.py", line 215, in new_machine
    machine = driver.new_machine_from_port(port, profile)
  File "python\conveyor-2.3.0-py2.7.egg\conveyor\machine\s3g.py", line 86, in new_machine_from_port
    port.path, False)
  File "python\makerbot_driver-0.1.1-py2.7.egg\makerbot_driver\MachineFactory.py", line 49, in build_from_port
    s3gBot, machine_setup_dict = machineInquisitor.query(condition, leaveOpen)
  File "python\makerbot_driver-0.1.1-py2.7.egg\makerbot_driver\MachineFactory.py", line 152, in query
    firmware_version = s3gDriver.get_version()
  File "python\makerbot_driver-0.1.1-py2.7.egg\makerbot_driver\s3g.py", line 96, in get_version
    response = self.writer.send_query_payload(payload)
  File "python\makerbot_driver-0.1.1-py2.7.egg\makerbot_driver\Writer\StreamWriter.py", line 31, in send_query_payload
    return self.send_command(payload)
  File "python\makerbot_driver-0.1.1-py2.7.egg\makerbot_driver\Writer\StreamWriter.py", line 57, in send_command
    return self.send_packet(packet)
  File "python\makerbot_driver-0.1.1-py2.7.egg\makerbot_driver\Writer\StreamWriter.py", line 143, in send_packet
    raise makerbot_driver.TransmissionError(received_errors)
TransmissionError: ['TimeoutError', 'TimeoutError', 'TimeoutError', 'TimeoutError', 'TimeoutError']

[Bence Blaske]

I have Sailfish 4.5 BTW, with Extruder Controller FW 3.1.

[Jetguy]

Yes, my Ultimate Thing-O-Matic connects just fine using Sailfish and the latest Makerware.

[Dan Newman]

This is a clone ToM, correct? Is it also a clone Arduino board?
The Arduino board may not have a USB VID or PID that Conveyor
recognizes. Conveyor has a hard coded list of USB VID/PID pairs
which it will recognize as a USB device associated with a Makerbot.
If the USB device is not in that list, it will not connect with it.
Since Conveyor is interpreted Python you can go in and add to or
change the list, but you need to know the USB VID & PID of the
USB device you have. (You can likely figure that out by using
whatever operating system tools you have to display information
about attached USB devices.)

Dan

> --
> You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> <failed.PNG>

[Bence Blaske]

Yes, it's a clone.
How would I go about changing the list? I only see files with pyd, which are compiled already, aren't they?
Thanks!

[Dan Newman]

On 12 Oct 2013 , at 9:25 AM, Bence Blaske wrote:

> Yes, it's a clone.
> How would I go about changing the list? I only see files with pyd, which
> are compiled already, aren't they?

There's .py files which are the source. And then .pyc files which are
compiled on-the-fly and then only re-compiled when the source file
changes. Ordinarily, .pyc files are not distributed -- only .py files.

Now, .pyd files are unique to Python on Windows, I believe. (I don't
use Windows myself.) They are, as I understand it, shared libraries (DLLs).
Did they come with your MakerWare distro or did your MW distro just have
.py files which Python then auto-compiled into .pyc and .pyd files?

At any rate, it would be in some of the .py files where these tables
are. Worse comes to worse, you could try a genuine Arduino Mega 2560
board. You do need to cut the reset trace on it though. There's
a spot on the board where you can manually do that. Which, BTW, makes
me wonder if the clone-maker cut the reset trace on the Mega 2560 clone
board they put on your bot? Might be another explanation for why
the uprocessor seems to reset on you mid-print.

Dan

[Bence Blaske]

Thanks, just checked the VID and PID of the device and it matches those found in the py source files (I found them in the python subfolder as egg packages).
I also remember seeing that the whole electronics of this clone is original Makerbot branded, so probably also the Arduino (which I think is not a 2560). The vid is 0403 and pid is 6001.

[Dan Newman]

On 12 Oct 2013 , at 10:20 AM, Bence Blaske wrote:

> Thanks, just checked the VID and PID of the device and it matches those
> found in the py source files (I found them in the python subfolder as egg
> packages).
> I also remember seeing that the whole electronics of this clone is original
> Makerbot branded,

That doesn't mean much beyond they used MBI's public gerber files.

> so probably also the Arduino (which I think is not a
> 2560). The vid is 0403 and pid is 6001.

0403 is FTDI's VID which you end up with if you use their USB chip. And
6001 is FTDI's PID for "FT232 USB-Serial (UART) IC".

And yes, those are in Conveyor's serial.py,

_SERIAL_PORT_CATEGORIES = [
_SerialPortCategory(0x0403, 0x6001, 'FTDI', 's3g',),
_SerialPortCategory(0x2341, 0x0010, 'Arduino Mega', 's3g',),
_SerialPortCategory(0x23C1, 0xD314, 'Replicator', 's3g',),
_SerialPortCategory(0x23C1, 0xB015, 'Replicator 2', 's3g',),
_SerialPortCategory(0x23C1, 0xB016, 'Replicator 2', 's3g',),
_SerialPortCategory(0x23C1, 0xB017, 'Replicator 2X', 's3g',),
]

So, next you might check that the reset trace is cut. Also, you really do need
to be using a current makerware since older makerwares do not handle all of
MBI's own S3G specification. With Sailfish 4.5, we put back in support for
returning S3G errors (was commented out by MBI circa 3.0 or 2.8). MakerWare
didn't have support for that aspect of the S3G specification, but MBI put it
in a few months back.

Dan

[Bence Blaske]

Thanks a lot for the tip on the reset trace, I cut it and now Makerware connects at an instant. BTW, indeed the Arduino was a clone.
So does ReplicatorG, it connects much faster and right away.
Let's see whether this also has an influence on my randomly stopping prints. Could it have an influence theoretically?

[Dan Newman]

On 12 Oct 2013 , at 11:16 PM, Bence Blaske wrote:

> Thanks a lot for the tip on the reset trace, I cut it and now Makerware
> connects at an instant. BTW, indeed the Arduino was a clone.
> So does ReplicatorG, it connects much faster and right away.
> Let's see whether this also has an influence on my randomly stopping
> prints. Could it have an influence theoretically?

Yes, it could have had an influence: certain electrical activity on the USB
bus would make the AVR reset unless that trace was cut.

Dan

[Dan Newman]

On 13 Oct 2013 , at 8:00 AM, Dan Newman wrote:

>
> On 12 Oct 2013 , at 11:16 PM, Bence Blaske wrote:
>
>> Thanks a lot for the tip on the reset trace, I cut it and now Makerware
>> connects at an instant. BTW, indeed the Arduino was a clone.
>> So does ReplicatorG, it connects much faster and right away.
>> Let's see whether this also has an influence on my randomly stopping
>> prints. Could it have an influence theoretically?

Here's one of the descriptions of auto-reset taken from arduino.cc. Key
take away is that there are actions which can happen from the Desktop
side of the system which can cause the AVR to reset. Avrdude actually takes
advantage of that to kick the AVR into its bootloader. MBI originally
set up the RevE mightyboard to have the reset trace active but then
backed off of that for some reason and omitted C20 from the board. (The
public schematics show "remove C20 to disable auto-reset". The circuitry
is pretty much straight from the Arduino Uno Rev2.) On the MightyBoard revG
they got things working which is why Rep 2 and 2X owners don't have a reset
button to press.

Dan

-----------


Automatic (Software) Reset

Rather than requiring a physical press of the reset button before an upload, the Arduino Uno is designed in a way that allows it to be reset by software running on a connected computer. One of the hardware flow control lines (DTR) of theATmega8U2/16U2 is connected to the reset line of the ATmega328 via a 100 nanofarad capacitor. When this line is asserted (taken low), the reset line drops long enough to reset the chip. The Arduino software uses this capability to allow you to upload code by simply pressing the upload button in the Arduino environment. This means that the bootloader can have a shorter timeout, as the lowering of DTR can be well-coordinated with the start of the upload.

This setup has other implications. When the Uno is connected to either a computer running Mac OS X or Linux, it resets each time a connection is made to it from software (via USB). For the following half-second or so, the bootloader is running on the Uno. While it is programmed to ignore malformed data (i.e. anything besides an upload of new code), it will intercept the first few bytes of data sent to the board after a connection is opened. If a sketch running on the board receives one-time configuration or other data when it first starts, make sure that the software with which it communicates waits a second after opening the connection and before sending this data.

The Uno contains a trace that can be cut to disable the auto-reset. The pads on either side of the trace can be soldered together to re-enable it. It's labeled "RESET-EN". You may also be able to disable the auto-reset by connecting a 110 ohm resistor from 5V to the reset line; see this forum thread for details.

-----------

[Bence Blaske]

Now that Makerware connects, I have another issue, which is quite strange: the bot is executing the extrusion commands quite strangely.

It moves in a way which is definetly wrong and very soon starts to ruin the whole print. It for example retracts the filament like 1cm very fast and so there is no material extrusion for a while.
Also the moves are sometimes strange, it extrudes over parts where there should be gaps, etc... So it's plainly just wrong. But many moves are actually correct, eg. the outline of the model is beeing "drawn" correctly, at least the moves look like that.

I attach the generated gcode and X3G of Mr. Jaws. I guess these are the commands that get sent to the bot when printing over USB.
I have Sailfish 4.5, Extruder Controller 3.1

In RepG, everything works perfectly.

[Dan Newman]

On 13 Oct 2013 , at 9:06 AM, Bence Blaske wrote:

> Now that Makerware connects, I have another issue, which is quite strange: the bot is executing the extrusion commands quite strangely.
>
> It moves in a way which is definetly wrong and very soon starts to ruin the whole print. It for example retracts the filament like 1cm very fast and so there is no material extrusion for a while.

Some makerware profiles call for a LARGE retraction. You may
be seeing that. However, also if you will use the slicer's retraction
mechanism, then you need to disable deprime in the firmware. Do that
by setting a value of 0 for deprime (for each extruder if you have two)
via RepG's Machine > Onboard Preferences.

> Also the moves are sometimes strange, it extrudes over parts where there should be gaps, etc…

I believe that is a known MakerWare issue with some older versions of MW. Also,
are you sure it's extruding or is it just ooze coming out of the extruder. That
said, on internal portions of the part, some versions of MW would extrude.

Dan

[Bence Blaske]

Hm, will check what difference it makes if I disable deprime for Sailfish.
But things look quite strange.
And I use the latest MW that can be downloaded.

[Bence Blaske]

I have just cheked the generated gcode in gcode.ws.
Very strange how it looks... Maybe MW is buggy for TOM profiles?

[Bence Blaske]

Setting deprime to 0 did the trick, now prints look fine. :)

Thanks for the help! (Again!)

2013. október 13., vasárnap 18:51:40 UTC+2 időpontban Bence Blaske a következőt írta:

[Dan Newman]

On 13 Oct 2013 , at 9:53 AM, Bence Blaske wrote:

> I have just cheked the generated gcode in gcode.ws.
> Very strange how it looks... Maybe MW is buggy for TOM profiles?

Jetguy uses it with his heavily modified ToM. However, he used the ToM
profiles as a starting point so he may have some insight.

Dan

[Adam Imberi]

Hey,

So I have the same issues with getting my makerbot to connect to makerware 2.4.0.14.  I was using a previous version with no real problems and now since the update I cannot connect.  My bot is a thing o matic from makerbot not a clone.  Do I have to cut a trace on my board also or is that an issue with clones only?

Thanks
Adam