ATMEGA644P arrived

ATMEGA644P arrived on Friday, used a mini drill with auger bit & very small/thin cutting disc to remove the 644, cleaned up pads with a soldering iron & solder wick, tagged new 644P in place (checking polarity, spot in corner) and soldered all legs of 644P in place, bridged a few in the process but not to worry a little solder wick applied with a hot iron removed the bridges.

Bleep tested everything before powering up, flashed boot loader (644P.hex) downloaded from random web location (properly this time) I am assuming that a bootloader is a bootloader and there are not many different types of bootloader (this could be a poor assumption on my part) but if it loads firmware then it must be correct?

Loaded firmware using Arduino IDE worked first time no (644) tweaks necessary, did notice some different behaviour with the new 644P chip, firmware loads fine, repeatable, but no debug light flashing? This seems odd considering the firmware was supposedly designed for a 644P.

But I still get no RS485 comms to my extruder board! (same old brick wall then!) oh well at least I have eliminated the possibility that the chip type is part of this or any future issues (I hope)

So I am now back where I was before the chip upgrade wondering how best to test for RS 485 comms without needing to purchase a RS 485 transceiver.

One thing I did notice earlier today when reading on the original Gen3 RepRap setup guide is that the testing page

http://reprap.org/wiki/Testing_RepRap_Electronics

shows the extruder connected to J4 not J1 as I would have expected (I seem to remember that the firmware is supposed to poll all possible connected extruders so this “should” not be a problem) I will retest everything with extruder on J4 and see if it makes any difference. (I have tried other J ports for the RS485 connection to the extruder with no success as yet)

I really need to get some other software working rather than just trying RepG (which is my preferred option) I was using only RepRap Host when I was running PIC based electronics but this was half the reason to upgrade to give me more software options.

I am currently having no success at all in getting my motherboard to talk GCodes with RepRap Host software, GCodes are sent but never received.

RepG only works when I use the “sanguino3G” driver set in the Machines.xml file of RepG, if I try and use the “reprap5d” driver I get no comms with motherboard same issue as RepRap host I think.

Am I barking up the wrong tree here by using the “sanguino3g” driver does this prevent me from using any “fived” firmware?

Bought ATMEGA644P today

Found this today which suggests that I could tweak the firmware, but I am not sure if the second UART is a requirement for communication with the extruder.

http://forums.reprap.org/read.php?4,81914,81931,quote=1

purchased ATMEGA644P microcontroller today, at least this should eliminate the chance of my EC comms issues being anything to do with the mobo’s chip type.

ATMEGA644 or ATMEGA644P that is the question!

Spent several hours web reading last night (06-Feb-2012), and stumbled across a page I had seen before when trying to get the bootloader working on the mobo, it suggested that the 644P chip has 2 UARTS and the 644 only has one, the author of this thread came to the conclusion that he would need to replace the chip for a 644P as the second serial port is used to communicate with the EC.
This is definitely ringing alarm bells and could be the source of my troubles as I have tweaked my config to allow me to load the 644.hex bootloader rather than the 644P I am guessing that the lack of the second UART may be why I am getting no EC comms, no way to test this other than replacing the chip and trying again!

A brief history so far (Part 4)

OK so now I can load firmware (yey) tested this by loading ReplicatorG (RepG) latest Version (27 at the time) and uploading basic cupcake profile to see what happened, loads fine talks to firmware (Version number of firmware reported in RepG console) opened control panel and tried to move things +X & +Y work -X & -Y don’t, Z does nothing but whistle.

Played with loading different firmware combinations, discovered That Cupcake profile running from RepG 21 (yes I had downloaded several version by this point) and using Firmware V2.4 for RepRap Mobo V1.2 worked a treat could move both X & Y in Positive and Negative directions, homing also worked a treat (once I had wired up the old Darwin style end stops) Z still did nothing but whistle.

After looking into why Z would do nothing I discovered a dead stepper board (simple swap around proved this) on closer examination I found 1 pin of the SMD chip on the stepper driver was not soldered at all, Bleep tested this to prove that the leg was not connected to the board (it wasn’t) soldered it up & voila it now works a treat.

Now were really flying I thought (yep straight into a brick wall) so now all I have to do is get the extruder talking, tried to flash firmware onto extruder board from RepG, no joy at all just won’t flash (and yes I do know the reset timing trick), checked that I could flash firmware to extruder using Arduino worked fine once I had set the correct board type Mega168 Decimilia and got the hang of the reset button timing trick, so I am able to use Arduino to flash extruder.

But no matter which firmware version I try I cannot get the firmware on mobo (various versions tried albeit randomly) to talk to the extruder controller (EC).

To complicate matters when I bought my G3 set I could not get the standard EC anywhere, so I settled on the Techzone version as I thought (and still think) that this is electronically identical to the G3 RepRap EC version 2.2.

After emailing the Techzone, they responded with this:-

Any firmware that is configured for the Gen 3 electronics should work just fine.  The main reprap firmware doesn't come configured by default for gen 3.  Most people who want to use RepG use the RepG firmware for gen3, but that doesn't work with the thermocouple.  I haven't looked through that firmware to see what it would take to get the thermocouple working.  The original firmware that was on the board can be found here http://www.reprap.org/mediawiki/images/c/c1/TechZone_gen_3_firmware.zip .  It works with the standard 5D gcode controllers and should work with RepG if set up to use its 5D gcode libraries (you have to select the correct machine type).  They might have it fixed now, but the last time I tried RepG with 5D firmware it had a bug in manual control, but worked to send a file to print.  You have to use the same firmware type on the motherboard as the extruder or it can't talk.  The cupcake firmware sends commands differently to the extruder than the standard 5D gcode.  If you aren't stuck on RepG I highly recommend repsnapper for communicating with a 5D gcode firmware.  Also, since you mention you are upgrading a Darwin, the 5D gcode is set to use a stepper motor for the extruder, not the DC motor that if I remember right was standard on the Darwin.  If you use 5D gcode you need a stepper for the extruder.

Thanks Kurt Bidstrup 

Thank you Kurt for this very informative response, this might explain why I can get the Mobo & Steppers working perfectly using the cupcake profile in RepG but with no EC comms.

But I have tried following Kurts suggestions as to using RepRap 5D firmware flashed using Arduino IDE and although I can connect to the Mobo (RepG complains about the old version number but this is expected) I am unable to control the axis properly, I would be happy that this is just a configuration issue and I could fix it by doing more web research on this exact issue, but I still have no connection to the extruder board at all despite making sure the mobo firmware revision (revision not version) is the same one as the extruder.

A brief history so far (Part 3)

My first frustrations with the new G3 Electronics set were the hefty customs charge that the UK pays on good from the states (rip-off!) and the realisation that in order to use it you need to purchase at least a serial controller and possibly a device to load the bootloader onto the board (http://www.ladyada.net/make/usbtinyisp/)!

Two more purchases later (This G3 set was starting to look expensive already) and I was ready to begin.

Built serial board as described here (http://reprap.org/wiki/Mendel_USB_and_power_connector) connected to RepRap Motherboard V1.2 as described and began trying to get comms with Motherboard, Nothing not a dickybird.

Guessing that my board had been supplied with no bootloader loaded I switched to building the USBTinyISP programmer (comes in kit form with PIC preloaded thankfully) preying that my soldering skills would not let me down.

Attempted to load bootloader, more web research required, using AVRDude tried several times eventually got the success message, Great (I thought) still no life from the board though, no lights, nothing. (beginning to wonder if board is a dud) more web research later and I discover that the chip on my board is a 644 not a 644P maybe I am using the wrong bootloader, check bootloader file, Sure enough its wrong and not only that I had copied the bootloader hex directly out of a webpage rather than downloading the file (shoddy!) and inadvertently the whole file was full of return carriage’s (extra characters at end of each line) guessing that this was probably going to upset things a little, I searched the web for a 644 (non 'P') bootloader hex file, found one downloaded correctly this time and flashed using AVRdude and voila "it’s alive" (yes I was leaping around shouting "it's alive" in my best Frankenstein voice) as denoted by the flashing debug led on start-up (flashes 3 times pause and then 4th flash)

Great (I Thought) surely now the serial comms issue would be solved (NOT) same message as before!

"avrdude: stk500_getsync(): not in sync: resp=0x00 avrdude: stk500_disable(): protocol error"

Still no comms!

During one of the many web research's required to get me to this point I had done some reading on using AVRdude to flash bootloaders and seemed to remember something about setting fuses, found a relevant webpage

http://forums.reprap.org/read.php?4,91699

It mentions that out the box the Mega644 chip runs at 1mhz and to get it to use the on-board crystal you need to “set the fuses”, not knowing much about setting fuses (and worrying that I might accidentally set something that I can’t unset) I thought that now I have serial comms established I may now be able to use Arduino IDE to flash the bootloader (hoping that Arduino IDE might set the fuses correctly automatically without me having to get technical with the command line) first try worked like a treat, same 3 flashes pause and 4th flash but this time a lot faster.

Bootloader DONE, hurrah!

A brief history so far (Part 2)

It appeared to be a legacy Darwin model sporting V1.0(ish) Pic based electronics and after finding a spare PC with serial port, building a serial cable & loading software It did nothing at all!

Not to be disheartened I read up on this format of RepRap and discovered to my dismay that it used Snap codes and not GCodes to communicate and it was about as old a Darwin as you could get without being one of the initial developers of the RepRap project (one of the very first purchasable RepRaps ever) it had been bought direct from Adrian Boyers group and therefore was a fairly standard Darwin (if there was ever such a thing) after spending a weekend tweaking the mechanics to make it a cube rather than a rhombus, and a few days of head wrangling (and a lot more web reading) I discovered the Snap Code issue (I had been trying to use the RepRap host software set to GCode rather than Snap code mode) a simple software switch later and it leapt into life (well it flashed some LED’s at me at least).

I had stripped the boards in an attempt to find out why the serial board did not seem to want to talk to the universal controller boards, that evening I wired it all back up to fire it up for the first time, initial impressions were good it seemed to be moving all axes and I was able to get the hotend "hotish" and melt some of the supplied albeit aged PLA.

My first extrusion

Time for a test print, went  straight for the Mendel corner bracket, and this is where things started to look not quite right.

After studying the plastic deposit closely it seemed like the machine was incapable of doing a diagonal line (i.e. it could only move 1 motor at a time) Much more web reading later (I was beginning to understand that this was going to be a trait of this project) and I discovered a hint of something to do with a missing sync wire! That evening I confirmed that the Darwin was indeed missing the sync wire, bodged one together and voila it "began printing" a very promising looking Mendel shaped part.

Failed Mendel Vertex (printed on generation 1 PIC based electronics)

 

Around the 5th or 6th layer I noticed that extrusion had thinned too much and the part failed.

Tried again, and again (each time tweaking the preferences file to see if I could improve the reliability) another few failed prints later and I was beginning to understand just how difficult it was going to be to make this beast reliable enough to do any useful work at all.

I seem to remember stopping when I broke the thermistor on the hot end after the umpteenth strip down to unclog the extrusion head again.

Bodged it back together, more failed prints later broke the nichrome, another hotend strip down, bodged back together again, more failed prints broke the Y axis (This was a temporary showstopper) after trying several ways of bodging this one I settled on a 1 inch piece of heavy duty petrol hose held on with 2 heavy duty hose clips as an impromptu Z motor coupling, this is working nicely and has remained there ever since.

So Z axis fixed (bodged) I continued with more failed prints, tweak settings, failed print (OK now this is starting to get boring) STOP and reassess!

The main flaws with the Darwin were as follows

1) Snap codes (outdated, new electronics set required)
2) New Z axis belt required (has been bodged/super glued after breaking)
3) Belt tensioner required
4) Very unreliable hot end (regular failures with both nichrome and thermistor wire's)
5) Very early and poor dc motor extruder design (geared stepper extruder required)

My attempted solutions to above issues

1) After much web reading (albeit not enough) I settled on a G3 based Sanguino set thinking that this would be the most likely compatible set for an old Darwin like this one. Bought 1.2 motherboard (discovered later that this was probably meant for a cupcake design and was prepped as so with ATX connector, RJ45 connectors, ATMEGA644 “not P” etc.)

2) Bodged Z axis belt with superglue after breakages.

3) Bodged the z axis with a solder sucker zip fastened to a lump of wood and zip fastened to Darwin frame to provide a very crude belt tensioner, the solder sucker is just serving as a nicely polished aluminium tube that I had handy.



4) After much more web reading, purchased Parcans hot end (nice looking design, and available on eBay)

5) My plan is to use the bits I have already purchased to get the Darwin printing and then as a matter of urgency print a geared extruder design.

I carried on with yet more failed prints in an attempt to get it going well enough to print an upgrade (geared extruder) but alas it was not going to happen.

By this point I had finally come to the conclusion that this beast was never constructed as a production machine but more a proof of concept (which makes sense as the students who built it were mainly interested in passing their degree’s).

So sadly the Darwin was switched off for around a month whilst I investigated what I needed to do to get the new G3 electronics set I had purchased to work.

A brief history so far (Part 1)

I joined the RepRap community around mid-2011 following a Click article on the BBC about the current state of rapid prototyping technology, at the end of which there was short sound bite about RepRap.

I took a look on the web and was immediately hooked, I work at the University of Sussex (UOS) and the next day I spoke to the head of the Cad Lab about the rapid prototyping facility at UOS, I was fishing to find out how much it would cost me to get a set of Mendel parts printed.

It turned out the only type of rapid prototyping the university could offer was resin printed and this would not be strong enough for actual use.

The following day however I got a call from the head of the Cad Lab who informed me that I should go an speak to the head of the rapid prototyping department as they have a RepRap sitting in a cupboard collecting dust and that I may be able to commandeer it! less than 10 minutes later I was standing in front of an aging and sorry looking Darwin that had seen better days.

It was explained to me that a few years ago a group of MSC students had built it as there final year project and that it had managed to print a "couple" of example components before being retired.

It was supplied as is with no software, or serial cable, but other than those omissions it all seemed to be present and correct (electronics wise) the guy at the rapid prototyping facility said that he would be happy for me to take it away but I would have to confirm this with the resident professor who had run the course on which it was built, and as a complete stroke of luck I happened to know who this was.

So to cut a long story short, after meeting the professor expressing an extreme interest in the project he was happy for me to "take it to the next level" Later that same day I took the Darwin home for a much closer look.