Cube3 BOM

I keep needing to look up the part #s of the different chips on the Cube3 controller board, and I figured it was about time to just make a bill-of-materials sheet for easier reference. (Now if only I could remember how to make a proper table in this thing...)


CPU:
   PIC32MX695F512L - Microchip

Oscillator:
    8 MHz

Wifi module:
    MRF24WG0MA - Microchip - SPI interface

Bluetooth module:
     VDBTLE24 - Viper Design - SPI interface

     Components:

• BTLE radio - NRF8001 - Nordic Semiconductor - https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF8001
• USB bridge - PIC24FJ32GB002-I/ML - Microchip - http://www.microchip.com/wwwproducts/en/PIC24FJ32GB002

Motor Drivers:
    TI DRV8811

Motor Driver DAC:
    U16 - MCP4728UN - Quad 12b i2c DAC - internal VREF 2.048V - http://www.microchip.com/wwwproducts/en/en541737

MOSFETs:
    ST VN5050AJ - single channel high side driver with analog current sense

LCD Module:
    RX024C-1 - Shenzhen Rogin Electronics
    320x240 - 2.4" - TFT - 262K colors (65k in SPI mode) - 4-wire resistive touchscreen

     Components:

• LCD Controller - SPFD5408B - https://www.crystalfontz.com/controllers/Orise%20Tech/SPFD5408B

Serial SRAM:
    U20 - 23K256 - 256Kbit (32KB) SPI SRAM - Microchip - http://www.microchip.com/wwwproducts/en/23K256

Fans:
    Extruder carriage - Sunon 12V 0.58W
    Nozzles (2x) - Sunon 5V 0.5W
    Motor blowers (2x) - Sunon MagLev MF50151VX-B000-A99 - 12V 2.04W

Stepper Motors:
    Extruders - Minebea 17PM-K374BN02CN (also 01CN)
    Axes - Minebea 17PM-K374BN02CN

Linear Rails:
    THK SRS9X

Extruder connector board: 
    U1 - AAHA - SOT23 (?) - 3.3V in, ? out
    U2 - GDX6 - SOT23 (?) - 12V in, 10V out
    U3 - 852 - SOT3 (?) - 12V in, 3.3V out
   
Extruders:
    Heater resistors - 15 Ohm
    Thermistors - 200k (?)
    Heater cutoff switch - Cantherm F20A

Filament Cartridge EEPROM:
    DS28E01-100 - Maxim - 1Kb Protected 1-Wire EEPROM
with SHA-1 Engine
    (very similar to DS2431, but with SHA-1)

DRV8825: nHOME, part 2

Continuing on with the nHOME investigation, I discovered that there is no pin on the carrier board that the nHOME pin can be broken out to easily.
I thought I could replace the nFAULT pin with it, but it ends up that pin is connected directly to the logic supply (5V) on most host boards (RAMPS, etc.) I next looked at the nSLEEP pin, but for some insane reason this pin is pulled down internally, so it *must* be pulled up externally, or your motor driver board will never turn on. At this point I gave up on bringing nHOME out to a pin on the carrier board... it would be mostly for physical security anyway, since it will need to be wired to a logic pin somewhere else on the board. So, blue wiring it is!

I tried some new stuff during the hookup: I've had an unused Arduino CNC shield for a while, and I figured that would be the easiest way to test a carrier board. It uses the standard Uno pin naming, and breaks out the pins from the carrier sockets to male headers, which is perfect if you want to sample those lines with an o-scope while a carrier board is plugged in.
I also found an interesting new stepper driver library (it's called StepperDriver) that can track the microstepping for you, and lets you move the motor by degrees instead of just steps. (I used neither of those features for this round of testing, but I might use them in the next one.)

Test setup
I made an Arduino sketch that steps 200 times in the forward direction, pausing for 500ms between each step. After 200 steps, it pauses for 1s and then repeats in the other direction. I pulled the nHOME pin up to Vcc via a 10k resistor. I hooked a scope probe to the step and nHOME pins. The microstepping was set to 1/1, or one full step per pulse.

Expected result
If I read the DRV8825 datasheet correctly, the nHOME pin should assert once per revolution at 45°. Being a standard 1.8°/step motor, 200 steps should be one full rotation. I expected to hit it once in the fwd direction, and a second time in reverse.

Actual result
My, was I surprised! The nHOME pin didn't just assert once per rev, but actually it was pulled down once for every four steps! The delay between pulses was too long; capturing a full rotation made my scope's screen refresh take forever. But I have no reason to think I wasn't getting normal behavior on that end (I measured stepping frequency at 1.25Hz). If this nHOME behavior is not due to an error on my part, that means not only is the assert count not 1/360°, but it's actually 1/7.2°, or 50 pulses per rev.

I bought these drivers off eBay, I believe, and I've always been curious if they were genuine TI parts. It's likely they are knock-offs and this nHOME behavior is either

an error, or due to a mis-translation of the datasheet (like the famous bug in nrf24 clones). I actually think it may be more useful this way, as I was thinking I'd need to physically align the steppers so that 45° would be near where the endstop hit. Hopefully a bit more investigation will determine if it's truly the driver or some error in my setup.

Next steps
I want to re-run what I just did, minus the delay between steps. I should be able to capture all the pulses for a full rotation more easily, at the same time eliminating the delay() function as a culprit for any timing weirdness.
I'd also like to try out larger microstepping values. If I understand the datasheet correctly (and I'm 0/1 so far), the nHOME pulses are related to the physical position of the stepper, which would mean it will assert at the same spots, regardless of how many steps it took to get there. My guess is changing the microstepping to 1/2 will make the nHOME assert once every 8 step pulses.

Time for more science!

TI DRV8825: There's no place like nHOME

I was comparing TI's DRV8825 and DRV8811 stepper motor drivers when I found a "hidden" feature I hadn't noticed before. Both drivers have an "nHOME" pin that goes active only when the stepper motor is at a specific angle (45°). I immediately thought of several uses for this pin.

The simplest application of the nHOME pin is as a check for your 3d printer's steps/mm settings. Calibrating that setting is critical for producing dimensionally accurate prints, but there's always a bit of guesswork involved. Most cal guides include a complicated function that multiplies step angle by microsteps, # of teeth, gear size, etc. I prefer to skip all that and just print 20mm calibration cubes and adjust the steps/mm with the error. Neither method is very precise, since there are many other factors involved in the final output, like filament diameter and flow rate. But I've found that if you calibrate the extruder motor first, and don't change filament between measurements, my method can result in less than 1% error (when you use a measurement tool with less than 1% error, of course). Regardless of which method you use, the motor parameter is always a constant. A stepper with a standard 1.8° step angle has 200 steps/revolution. It's set in stone. But when you enable microstepping, does a revolution still equal 200*mstep factor? If something is wrong with your driver setup, and your motor is skipping steps, you won't see it until you start printing, at which time there will be a bunch of other possible causes. (If it sounds like I am familiar with this problem, it's because I am. Intimately.)
Being able to verify how many step pulses equal a full revolution of the motor would be a very simple and handy tool in our toolboxes.

The other, and most interesting, application is for closed-loop motor feedback. With no additional components at all, the nHOME pin could be used to verify the motor hasn't skipped steps during printing. It wouldn't be very precise, since you would only be able to check it once per full revolution, but it's still better than no check at all.
Where this really starts to get interesting is when you couple the nHOME pin with an encoder. The most useful (and expensive) encoders report "absolute" positions, meaning they give you the exact position at any time, even at power-up. The cheapest encoders only report "relative" position. Relative encoders tell you how many pulses the motor has moved forwards or backwards. If you stop counting pulses, or power down the system, you don't know where the motor is, and you need to home the motor to get a "zero" position to start from. (This is how most 3d printers work, today, minus the encoder. The system counts how many step pulses it sends to the motor in each direction, so it knows where the motor "should" be, as long as it didn't skip any steps). I've also seen "hybrid" encoders that combine a relative one with a simple two-state detector. You can use the simple detector to give some context to the relative pulses; I've seen kinds that pulse once per revolution, and other types that are on for half the rev and off for the other half. The nHOME pin functions just like the former, meaning you could always correlate the physical position of the motor with the relative pulses. You could even use it to automatically calibrate the encoder, since a relative one still requires a "pulses per distance" number to be useful. (If you're repurposing encoders from other sources, you may not know that exact value.) Counting encoder pulses that occur between two nHOME toggles means you know exactly how many pulses occur for one full rev of the motor! Throw in a move to the endstop to get a zero postion and you'd be able to know the exact position of the motor carriage, (along with the exact angle) at any time! Good stuff!

Unfortunately the nHOME pin isn't broken out to a header on Pololu (or clone) DRV8825 boards, but there are several that nobody ever uses. I'll do some research and see if one of those pins can be swapped out for nHOME.

Filthy Treasures: Kindle 2

I scored this Kindle 2 for $10 from Value Village before the holidays! I've wanted to do a project with an e-ink screen for a while, but not enough to go out and buy one just to hack. This one works great, other than the battery not holding a charge (to be expected with something so old). I intend to use it tethered, so that's not a deal-breaker. The physical keyboard is actually preferrable for my intended use, (a portable serial terminal, if you were wondering).
While checking it out I even found a feature I've been wanting forever: text-to-speech! This model will actually read your ebooks to you! I've had a Kindle  Paperwhite for a few years, and I'm not sure newer models even have this feature.
I love a great thrift store score!