gen3 motherboard V1.2 isn't communicating with ReplicatorG

Hi,

i'm trying to get my Mendel run but i got stuck with testing the motherboard. It's not responding to the host software. RepG is sending a gcode every 30 seconds but the motherboard doesn't respond.
I'm running ReplicatorG25 and i could update the firmware from the motherboard to v2.4. The OS i'm using is windows7 64bits. I already searched on the wiki but the information i found there couldn't help me further. It's also unclear what the proper and stable version is for this motherboard. The intension that i have is to get it running with the standard Gen3 configuration but first i have to solve this issue. Anybody had the same problem? I should be a great help!

I've had a stable configuration of a Mendel with the original Gen3 electronics (not Techzone), using ReplicatorG. It took a bit to get working, and I'm not sure if you are having the same issues I did, but maybe this will help you out.

When you say that repG is sending a gcode but the motherboard isn't responding, does repG even connect at all? I mean, when I do it, the status bar at the top of the repG window turns green and says that I'm connected. Can you open the control panel and move the axes at all?

Anyway, here's my stable version:

---Hardware/Firmware---
- Sanguino Motherboard v1.2, running makerbot firmware v2.4
- an Extruder Controller v2.2, running makerbot firmware v2.6 (external stepper, no relay)
- MB connects to EC via two wires on the RS485 link, NOT the SDA/SCL wiring that the official Mendel wiring uses.
- a pololu stepper driver for the extruder, wired like this: [wiki.makerbot.com] (step/dir pins wired to Quardrature 7/8, and I modified the Pololu stripboard to have the Enable pin wired to the extruder controller's D10)

---Software---
- ReplicatorG 0022 on either Ubuntu or Win7 64bit (also tried 0025 on Win7 64bit, but only after I had a stable config in 0022)
- in machines.xml, using "Mendel with Gen3 Electronics", but I changed the driver name and rate like this:

 [driver name="sanguino3g"] <!-- was reprap5d -->
                        <!-- optional: COM1 -->
                        [rate]38400[/rate] <!-- was 19200 -->
                [/driver]
(note: change all square brackets to < or >, the forum was messing them up)

(I changed the driver name and the rate to 38400 to be consistent with an older machines.xml from a previous version of RepG that worked for me, though I can't find any other reference than this depricated version: [code.google.com] I recommend you verify the rate in the motherboard firmware source code if necessary. I think the sanguino chip uses 38400 by default anyway)

Let me know if this helps, or if you need any more info. I was sort of lost when I set mine up, since it was before the explosion in growth of all these different firmwares, so I'm glad to help others in the same situation!

Edited 1 time(s). Last edit at 09/27/2011 12:06PM by toomanyplugs.

Just a followup on the baud rate, for the record. I knew I had looked into this before when I had to set up the machines.xml.

This may be over your head, that's ok. I just wanted to have a reference so that I don't have to dig this up for myself again. I'm sure others are smarter than me about this, but I had to suss it out from the source code in order for my machine to work.

In the old v1.x versions of the motherboard firmware, the baud rate was set in the configuration.h.dist file (~line 46):
[github.com]

#define HOST_SERIAL_SPEED 38400

But in the v2.x rewrite of the motherboard firmware, the baud rate was hard coded into UART.cc (~line 55):
[github.com]

#define UBRR_VALUE 25

Note: UBRR is a calculation based on chip speed and baud rate, etc., see here: [winavr.scienceprog.com]

UBRR=((f_clk/(BaudRate*16))-1)

where f_clk – microcontroller clock speed(Hz); BaudRate – communication baud rate.

The Sanguino is 16 MHz, and assuming 38400 baud, this is

(16000000/(38400*16))-1 = 25

In any case, the Sanguino-based motherboards should be communicating at 38400 baud, which is what your machines.xml should be set to. This was more obvious in the older firmware but became obscured as the firmware evolved.

toomanyplugs Wrote:
-------------------------------------------------------
> ---Hardware/Firmware---
> - Sanguino Motherboard v1.2, running makerbot
> firmware v2.4
> - an Extruder Controller v2.2, running makerbot
> firmware v2.6 (external stepper, no relay)
> [...]
> ---Software---
> - in machines.xml, using "Mendel with Gen3
> Electronics", but I changed the driver name and ...

Since you have makerbot firmware then your machine is a cupcake, by all intents and purposes. The machine couldnt care less what physical setup it uses, as long as you have cupcake firmware on it then its a cupcake and not else. Really doesnt matter how it looks on the outside, but matters what firmware is like. For example, cupcake doesnt have firmware value for steps per mm and other settings (thermistor settings, etc), these are uploaded in the uC memory from the machine.xml file. Typically the other firmwares have the steps per mm and thermistors and all the other settings "hard-coded" in confing.h file and compiled at upload, so in these cases, the value of steps per mm in machine.xml file is irrelevant, it cant change how that firmware runs in any way. Also cupcake has some little different gcodes from the typical rep-rap ones. See gcodes listed on replicatorg and reprap sites for differences (e.g. check 140 for example).

So you have to set it up as a Cupcake, otherwise the makerbot firmware wont get what it needs to run, and then it cant possibly work. You cant run it using the machine.xml driver for gen3 mendel, or any other, because the replicatorg would expect that firmware, which does not have the "needs" of makerbot firmware, and has different commands/g-codes.

First immediate choices that i see:
1) run makerbot firmware & set it as cupcake, or
2) run teacup firmware (i could give you my gen3 config files although you cant expect it to fit 100%), & set it as such. Also this is able to use pronterface or repsnapper instead of replicatorg. Atm i use teacup and pronterface, hence i would recommend these.

-other choices would need more or less other things, like 3) spend tones of times fixing the bloated "official" fived to compile for gen3 and then use machine.xml as mendel gen 3 only to have it run with tones of comm errors or 4) hack into MB12 and add 2 temp boards on 2 adc pins, and 2 fets to other 2 gio pins, and then use firmwares like spriter or any of the single uC firmwares out there.

Its not about baud rates or something like that, or better said, thats the least of it. Again, cupcake (makerbot) firmare for gen 3 again, will use flash mem to upload settings like termistor beta and steps per mm, and so on. See makerbot cupcake tutorials how to tweak the firmware settings for termistors and such. And some g-codes are different, but that could be easier to change. And to use stepper extruder i think it needs the S value outputted by skeinforge specified in RPM and not in PWM... etc. For makerbot firmware, the makerbot site should list the tips and tricks and all that is needed to make it run.

That being said, maybe replicatorg has a routine to check if the firmare requires some config data via usb/rs232 connection, so if thats the case it might deliver it. That doesnt mean the firmware is run as mendel, it just means its run as a "true" cupcake which "name" is mendel. But whats the point to do that, isnt easier to use the cupcake config in machine.xml in the first place, its what its meant for.

Edited 7 time(s). Last edit at 09/28/2011 07:07AM by NoobMan.

I think i also replied to this in some other thread? I just remembered now .... woah.

here it was ... just a little different putted there someone tried reprap host software with makerbot firmware, or smth like that.
[forums.reprap.org]

Edited 1 time(s). Last edit at 09/28/2011 07:05AM by NoobMan.

You're right NoobMan, thanks for the clarification! As far as RepG is concerned, my machine *is* a cupcake, albeit "Mendel-shaped", since I am using the sanguino3g driver. When I built my bot, I chose the cupcake/RepG toolchain over the Reprap host.

Since the OP mentioned loading motherboard v2.4 on their board, I wanted to describe a stable config that I have been using to print. I think the key takeaway is that if you are using the makerbot firmware (v2.x) with Gen3 boards, then you have to select the "cupcake" driver in RepG, regardless of what your bot looks like, and NOT the "Mendel w/ Gen3 Electronics".

True, the cupcake firmware doesn't have the latest cool features like acceleration, but it works well enough for starting out on a Mendel(-shape). I had to change the steps/mm in machines.xml for my bot, and then I added rpmify to skeinforge (35), and now I can print with a stepper extruder with no issues about gcode (skeinforge creates an M113 code, but RepG ignores it and there doesn't seem to be an issues with that).

However, I think RepG and the makerbot team aren't really supporting Gen3 boards anymore (or cupcakes for that matter!), so it would probably be better to forget the cupcake firmware and use teacup.

Yup i think thats correct way to do it, select cupcake and change whatever is needed in there, like working distances, steps per mm, etc. If your system does work with mendel i guess there is a check somewhere in replicatorg so if the firmware requests these values it can get it, otherwise it couldnt possibly work without, so its still a cupcake more or less since it acts like that. As far as i know sanguino3d (if it refers to official 5d or alike, not rly sure which) should have no reason to upload these settings and touch memory at all, my understanding is that it should expect these settings to come from a config.h file, compiled at upload, thus being kinda fixed values, and only another upload could change them. This is why i wondered how it even works, from what i know it shouldnt.

I guess that as a result, replicatorg is mandatory since is the only sender i know able to work with the makerbot firmware, knowing how to upload these values (steps per mm, thermistor beta, axes sizes, etc), from the machine.xml into the microcontroller's memory, which i think it does each time the machine is started up. The other senders that i know dont do that, as the rest of firmwares use config.h to specify these values, and then these wont be changed later on except with another upload.

With teacup firmware on the other hand, you can use replicatorg, repsnapper, pronterface, terminals, etc, and probably many others, including the future ones that will appear later on.

I dont think makerbot has skipped on gen3 support, in general, just the product wont suffer many / or no future changes and most of the bugs should of been ironed out by now, so having less firmware updates makes sense as the product is both pretty old and also replaced by tom ~ gen4. But i think its a good firmware piece.

I wonder if you can tell me how the sd card support is for you. I tried it but to upload a file it needed like 20% or more time compared with that piece print time. So i got really bored with that way. Maybe using the card in another usb device to load the file, then putting it in mb12 would work but i dont know how much that would take before the sd card or the slot would worn off.

Edited 3 time(s). Last edit at 09/28/2011 12:37PM by NoobMan.

Ah, well as for SD support, I also found it took a long time to load the card if I left it in the motherboard and copied the file through RepG. Instead, I used "build to file" and saved the gcode locally on my computer (a netbook with an SD slot), then plugged the SD card into my netbook and copied the gcode file over that way. Much faster!

I don't know if using the SD card through a camera interface would work, or if there's some weird protocol difference that makes the file unreadable.

In general, though, I haven't used the SD card very much. I haven't been doing any prints over about 90 minutes yet, so I haven't had any problems with messed up builds. I did notice however that the makerbot firmware v2.x (as opposed to the old v1.x) seemed a bit more reliable for building from the computer without aborting, so I mainly use that.

I haven't used the SD card enough to see if the contacts wear out, but I imagine at some point they would.