Gigabot Electronics

General
1

Since we keep blowing the Gigabot’s Azteeg electronics, I thought I’d offer up another solution… I just built that other printer this past week and it came with a complete set of RAMPS 1.4 along with the Mega 2560 that I do not intend to use.

Since re:3D is moving to their own design based on RAMPS 1.4, I thought this might be a great time to upgrade. Their firmware will run just fine on it and it’s quite easy to get replacements as well. It’s a simple swap and replace and we can get it back up and running in no time. I’d also suggest we simplify everything… for example, go to a standard 5v z probe at the same time.

Thoughts?

Bill

2

As long as the board can handle the Gigabot’s larger steppers, I don’t see a downside here. We’d still be using a Marlin fork, so there would be no changes in machine operation for those already familiar with the Gigabot.

Are we losing any useful capabilities by moving away from the Azteeg? If a RAMPS board could drive the machine all along, I wonder why they went with the higher priced electronics in the first place.

  • Ry
3

How many amps are the motors on Gigabot? I bet they’re less than what I’ve been dealing with this week…
-D

4

The nice thing about the RAMPS, like the Azteeg, is that the controllers are swappable… so we can put in any controller we need to, but the standard controllers shouldn’t have any issues with the NEMA 17s on the Gigabot. If the controllers on the Azteeg were big enough, then we can just use them on the RAMPS board as well.

We’re also not loosing any capabilities except for using Thermocouples… but I thought we switched to Thermistors anyway. (Or at least we should, if we didn’t!)

Bill

5

First, I was the one who borked the azteeg, although it wasn’t my level shifter that did it.

I didn’t use the one on the wiki (after I discovered that I had followed a schematic that was just plain wrong – different azteeg revision that had an old school TTL high). It was just an NPN switch biased with a 10K resistor and a diode to protect from saturation. Simple switch to pull it down. The uC had a weak pull up enabled, so pull down was not necessary since current was limited to the sensor by a series resistor.

Yes, looking at Z sensors we should have just gotten the NPN sensor, not PNP. That would work. The PNP switch pulls up to high, whereas the NPN will simply close and pull down.

I did notice some anomalies in our azteeg the way it interacted with RE3D power supply.

1 - It was floating. This is often shitty for FET (see art of electronics). Some points were +14V relative to power supply ground.

2 - From uC ground off the regulator, my NIST cal. meter was measuring +6-+8V where we should have seen +5. I don’t have time to figure out if I was measuring from a floating ground or diode bias, or whatever, but that’s magic blue smoke material waiting to happen.

  1. I think that the azteeg was a poor match for this machine and not really well thought out by Re3D or azteeg V3 perhaps… Dunno.

So I would endorse any proposal for another controller, but we need to make sure we have a good star ground, and that chassis ground is corrrect. We were getting chassis ground in areas of the PCB where is was mounted to metal screws, and these may have been 10-14V away from +5 rails. It all seems kinda suspect to me, and others may be able to explain this better.

I did probably screw up a bit and tap my screwdriver somewhere wrong, but if GND was floating so high (and wasn’t supposed to be), even touching the damn thing could have blown it…

However, I want my magic blue smoke award, and deserve a place on the wall of fail now. I will gladly chip in for a new controller.

L