Welcome! Log In Create A New Profile

Advanced

Ramps 1.4 not heating up

Posted by oierlauzi 
Ramps 1.4 not heating up
January 07, 2016 03:26PM
Hello everyone;
I recently started building my first 3D printer (I do not have any previus experience). My printer is a Prusa i3 Steel that uses a Ramps 1.4 with Marlin 1.1.0 RC3. My problem is that when I try to heat up the bed and/or the extrusor, the board doesn't send any voltage to them, so they keep cold I think that is wired correctly, heatbed conected with correct polarization to D8 and extrusor with no polarization to D10. This is my Marlin's source-code in configuration.h (only the begining, as I think that the rest doesn't matter. I also think that Temperature settings are the default ones):

#ifndef CONFIGURATION_H
#define CONFIGURATION_H

#include "boards.h"
#include "macros.h"

//===========================================================================
//============================= Getting Started =============================
//===========================================================================
/*
Here are some standard links for getting your machine calibrated:
 * [reprap.org]
 * [youtu.be]
 * [calculator.josefprusa.cz]
 * [reprap.org]
 * [www.thingiverse.com]
 * [sites.google.com]
 * [www.thingiverse.com]
*/

// This configuration file contains the basic settings.
// Advanced settings can be found in Configuration_adv.h
// BASIC SETTINGS: select your board type, temperature sensor type, axis scaling, and endstop configuration

//===========================================================================
//============================= DELTA Printer ===============================
//===========================================================================
// For a Delta printer replace the configuration files with the files in the
// example_configurations/delta directory.
//

//===========================================================================
//============================= SCARA Printer ===============================
//===========================================================================
// For a Scara printer replace the configuration files with the files in the
// example_configurations/SCARA directory.
//

// @section info

#if ENABLED(USE_AUTOMATIC_VERSIONING)
  #include "_Version.h"
#else
  #include "Default_Version.h"
#endif

// User-specified version info of this build to display in [Pronterface, etc] terminal window during
// startup. Implementation of an idea by Prof Braino to inform user that any changes made to this
// build by the user have been successfully uploaded into firmware.
#define STRING_CONFIG_H_AUTHOR "Oier Lauzirika (oierlauzi)" // Who made the changes.
#define SHOW_BOOTSCREEN
#define STRING_SPLASH_LINE1 SHORT_BUILD_VERSION // will be shown during bootup in line 1
//#define STRING_SPLASH_LINE2 STRING_DISTRIBUTION_DATE // will be shown during bootup in line 2

// @section machine

// SERIAL_PORT selects which serial port should be used for communication with the host.
// This allows the connection of wireless adapters (for instance) to non-default port pins.
// Serial port 0 is still used by the Arduino bootloader regardless of this setting.
// :[0,1,2,3,4,5,6,7]
#define SERIAL_PORT 0

// This determines the communication speed of the printer
// :[2400,9600,19200,38400,57600,115200,250000]
#define BAUDRATE 250000

// Enable the Bluetooth serial interface on AT90USB devices
//#define BLUETOOTH

// The following define selects which electronics board you have.
// Please choose the name from boards.h that matches your setup
#ifndef MOTHERBOARD
  #define MOTHERBOARD 33
#endif

// Optional custom name for your RepStrap or other custom machine
// Displayed in the LCD "Ready" message
#define CUSTOM_MACHINE_NAME "Hirude"

// Define this to set a unique identifier for this printer, (Used by some programs to differentiate between machines)
// You can use an online service to generate a random UUID. (eg [www.uuidgenerator.net])
//#define MACHINE_UUID "00000000-0000-0000-0000-000000000000"

// This defines the number of extruders
// :[1,2,3,4]
#define EXTRUDERS 1

// Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing).
// The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder).
// For the other hotends it is their distance from the extruder 0 hotend.
//#define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis
//#define EXTRUDER_OFFSET_Y {0.0, 5.00}  // (in mm) for each extruder, offset of the hotend on the Y axis

//// The following define selects which power supply you have. Please choose the one that matches your setup
// 1 = ATX
// 2 = X-Box 360 203Watts (the blue wire connected to PS_ON and the red wire to VCC)
// :{1:'ATX',2:'X-Box 360'}

#define POWER_SUPPLY 1

// Define this to have the electronics keep the power supply off on startup. If you don't know what this is leave it.
//#define PS_DEFAULT_OFF

// @section temperature

//===========================================================================
//============================= Thermal Settings ============================
//===========================================================================
//
//--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table
//
//// Temperature sensor settings:
// -2 is thermocouple with MAX6675 (only for sensor 0)
// -1 is thermocouple with AD595
// 0 is not used
// 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup)
// 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup)
// 3 is Mendel-parts thermistor (4.7k pullup)
// 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !!
// 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup)
// 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)
// 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup)
// 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup)
// 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup)
// 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup)
// 10 is 100k RS thermistor 198-961 (4.7k pullup)
// 11 is 100k beta 3950 1% thermistor (4.7k pullup)
// 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed)
// 13 is 100k Hisens 3950  1% up to 300°C for hotend "Simple ONE " & "Hotend "All In ONE"
// 20 is the PT100 circuit found in the Ultimainboard V2.x
// 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950
//
//    1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k
//                          (but gives greater accuracy and more stable PID)
// 51 is 100k thermistor - EPCOS (1k pullup)
// 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup)
// 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup)
//
// 1047 is Pt1000 with 4k7 pullup
// 1010 is Pt1000 with 1k pullup (non standard)
// 147 is Pt100 with 4k7 pullup
// 110 is Pt100 with 1k pullup (non standard)
// 998 and 999 are Dummy Tables. They will ALWAYS read 25°C or the temperature defined below.
//     Use it for Testing or Development purposes. NEVER for production machine.
//#define DUMMY_THERMISTOR_998_VALUE 25
//#define DUMMY_THERMISTOR_999_VALUE 100
// :{ '0': "Not used", '4': "10k !! do not use for a hotend. Bad resolution at high temp. !!", '1': "100k / 4.7k - EPCOS", '51': "100k / 1k - EPCOS", '6': "100k / 4.7k EPCOS - Not as accurate as Table 1", '5': "100K / 4.7k - ATC Semitec 104GT-2 (Used in ParCan & J-Head)", '7': "100k / 4.7k Honeywell 135-104LAG-J01", '71': "100k / 4.7k Honeywell 135-104LAF-J01", '8': "100k / 4.7k 0603 SMD Vishay NTCS0603E3104FXT", '9': "100k / 4.7k GE Sensing AL03006-58.2K-97-G1", '10': "100k / 4.7k RS 198-961", '11': "100k / 4.7k beta 3950 1%", '12': "100k / 4.7k 0603 SMD Vishay NTCS0603E3104FXT (calibrated for Makibox hot bed)", '13': "100k Hisens 3950  1% up to 300°C for hotend 'Simple ONE ' & hotend 'All In ONE'", '60': "100k Maker's Tool Works Kapton Bed Thermistor beta=3950", '55': "100k / 1k - ATC Semitec 104GT-2 (Used in ParCan & J-Head)", '2': "200k / 4.7k - ATC Semitec 204GT-2", '52': "200k / 1k - ATC Semitec 204GT-2", '-2': "Thermocouple + MAX6675 (only for sensor 0)", '-1': "Thermocouple + AD595", '3': "Mendel-parts / 4.7k", '1047': "Pt1000 / 4.7k", '1010': "Pt1000 / 1k (non standard)", '20': "PT100 (Ultimainboard V2.x)", '147': "Pt100 / 4.7k", '110': "Pt100 / 1k (non-standard)", '998': "Dummy 1", '999': "Dummy 2" }
#define TEMP_SENSOR_0 1
#define TEMP_SENSOR_1 0
#define TEMP_SENSOR_2 0
#define TEMP_SENSOR_3 0
#define TEMP_SENSOR_BED 1

// This makes temp sensor 1 a redundant sensor for sensor 0. If the temperatures difference between these sensors is to high the print will be aborted.
//#define TEMP_SENSOR_1_AS_REDUNDANT
#define MAX_REDUNDANT_TEMP_SENSOR_DIFF 10

// Actual temperature must be close to target for this long before M109 returns success
#define TEMP_RESIDENCY_TIME 10  // (seconds)
#define TEMP_HYSTERESIS 3       // (degC) range of +/- temperatures considered "close" to the target one
#define TEMP_WINDOW     1       // (degC) Window around target to start the residency timer x degC early.

// The minimal temperature defines the temperature below which the heater will not be enabled It is used
// to check that the wiring to the thermistor is not broken.
// Otherwise this would lead to the heater being powered on all the time.
#define HEATER_0_MINTEMP 5
#define HEATER_1_MINTEMP 5
#define HEATER_2_MINTEMP 5
#define HEATER_3_MINTEMP 5
#define BED_MINTEMP 5

// When temperature exceeds max temp, your heater will be switched off.
// This feature exists to protect your hotend from overheating accidentally, but *NOT* from thermistor short/failure!
// You should use MINTEMP for thermistor short/failure protection.
#define HEATER_0_MAXTEMP 275
#define HEATER_1_MAXTEMP 275
#define HEATER_2_MAXTEMP 275
#define HEATER_3_MAXTEMP 275
#define BED_MAXTEMP 150

// If your bed has low resistance e.g. .6 ohm and throws the fuse you can duty cycle it to reduce the
// average current. The value should be an integer and the heat bed will be turned on for 1 interval of
// HEATER_BED_DUTY_CYCLE_DIVIDER intervals.
//#define HEATER_BED_DUTY_CYCLE_DIVIDER 4

// If you want the M105 heater power reported in watts, define the BED_WATTS, and (shared for all extruders) EXTRUDER_WATTS
//#define EXTRUDER_WATTS (12.0*12.0/6.7) //  P=I^2/R
//#define BED_WATTS (12.0*12.0/1.1)      // P=I^2/R

//===========================================================================
//============================= PID Settings ================================
//===========================================================================
// PID Tuning Guide here: [reprap.org]

// Comment the following line to disable PID and enable bang-bang.
#define PIDTEMP
#define BANG_MAX 255 // limits current to nozzle while in bang-bang mode; 255=full current
#define PID_MAX BANG_MAX // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current
#if ENABLED(PIDTEMP)
  //#define PID_DEBUG // Sends debug data to the serial port.
  //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX
  //#define SLOW_PWM_HEATERS // PWM with very low frequency (roughly 0.125Hz=8s) and minimum state time of approximately 1s useful for heaters driven by a relay
  //#define PID_PARAMS_PER_EXTRUDER // Uses separate PID parameters for each extruder (useful for mismatched extruders)
                                    // Set/get with gcode: M301 E[extruder number, 0-2]
  #define PID_FUNCTIONAL_RANGE 10 // If the temperature difference between the target temperature and the actual temperature
                                  // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max.
  #define PID_INTEGRAL_DRIVE_MAX PID_MAX  //limit for the integral term
  #define K1 0.95 //smoothing factor within the PID

  // If you are using a pre-configured hotend then you can use one of the value sets by uncommenting it
  // Ultimaker
  //#define  DEFAULT_Kp 22.2
  //#define  DEFAULT_Ki 1.08
  //#define  DEFAULT_Kd 114

  // MakerGear
  //#define  DEFAULT_Kp 7.0
  //#define  DEFAULT_Ki 0.1
  //#define  DEFAULT_Kd 12

  // Mendel Parts V9 on 12V
  //#define  DEFAULT_Kp 63.0
  //#define  DEFAULT_Ki 2.25
  //#define  DEFAULT_Kd 440

  #define  DEFAULT_Kp 22.2
  #define  DEFAULT_Ki 1.08
  #define  DEFAULT_Kd 114

#endif // PIDTEMP

//===========================================================================
//============================= PID > Bed Temperature Control ===============
//===========================================================================
// Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis
//
// Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder.
// If your PID_dT is the default, and correct for your hardware/configuration, that means 7.689Hz,
// which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating.
// This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater.
// If your configuration is significantly different than this and you don't understand the issues involved, you probably
// shouldn't use bed PID until someone else verifies your hardware works.
// If this is enabled, find your own PID constants below.
//#define PIDTEMPBED

//#define BED_LIMIT_SWITCHING

// This sets the max power delivered to the bed, and replaces the HEATER_BED_DUTY_CYCLE_DIVIDER option.
// all forms of bed control obey this (PID, bang-bang, bang-bang with hysteresis)
// setting this to anything other than 255 enables a form of PWM to the bed just like HEATER_BED_DUTY_CYCLE_DIVIDER did,
// so you shouldn't use it unless you are OK with PWM on your bed.  (see the comment on enabling PIDTEMPBED)
#define MAX_BED_POWER 255 // limits duty cycle to bed; 255=full current

//#define PID_BED_DEBUG // Sends debug data to the serial port.

#if ENABLED(PIDTEMPBED)

  #define PID_BED_INTEGRAL_DRIVE_MAX MAX_BED_POWER //limit for the integral term

  //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+)
  //from FOPDT model - kp=.39 Tp=405 Tdead=66, Tc set to 79.2, aggressive factor of .15 (vs .1, 1, 10)
  //#define  DEFAULT_bedKp 10.00
  //#define  DEFAULT_bedKi .023
  //#define  DEFAULT_bedKd 305.4

  //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+)
  //from pidautotune
  //#define  DEFAULT_bedKp 97.1
  //#define  DEFAULT_bedKi 1.41
  //#define  DEFAULT_bedKd 1675.16

  // FIND YOUR OWN: "M303 E-1 C8 S90" to run autotune on the bed at 90 degreesC for 8 cycles.
#endif // PIDTEMPBED

// @section extruder

//this prevents dangerous Extruder moves, i.e. if the temperature is under the limit
//can be software-disabled for whatever purposes by
#define PREVENT_DANGEROUS_EXTRUDE
//if PREVENT_DANGEROUS_EXTRUDE is on, you can still disable (uncomment) very long bits of extrusion separately.
#define PREVENT_LENGTHY_EXTRUDE

#define EXTRUDE_MINTEMP 170
#define EXTRUDE_MAXLENGTH (X_MAX_LENGTH+Y_MAX_LENGTH) //prevent extrusion of very large distances.

//===========================================================================
//======================== Thermal Runaway Protection =======================
//===========================================================================

/**
 * Thermal Runaway Protection protects your printer from damage and fire if a
 * thermistor falls out or temperature sensors fail in any way.
 *
 * The issue: If a thermistor falls out or a temperature sensor fails,
 * Marlin can no longer sense the actual temperature. Since a disconnected
 * thermistor reads as a low temperature, the firmware will keep the heater on.
 *
 * The solution: Once the temperature reaches the target, start observing.
 * If the temperature stays too far below the target (hysteresis) for too long,
 * the firmware will halt as a safety precaution.
 */

#define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders
#define THERMAL_PROTECTION_BED     // Enable thermal protection for the heated bed

If you have any question, please ask me. Thank you and sorry for my bad English
Bye
Re: Ramps 1.4 not heating up
January 07, 2016 07:32PM
12V power connected to both sets of power inputs? Perhaps a photo of your connections to the ramps would help.

Welcome to the forum!
Re: Ramps 1.4 not heating up
January 08, 2016 09:35AM
Thank you JamesK for your answer; yes both 12v conectors are conected and I have tested them with a voltimeter (12,03V). I am attaching a photo.
Thank you again. PD, sorry for my mess of cables
Attachments:
open | download - DSC_0005.JPG (532.2 KB)
Re: Ramps 1.4 not heating up
January 08, 2016 09:49AM
OK, looks good. No need to apologise about the mess of cables, we all start there, and I'm still trying to tame my mess.

The heaters are switched on the -ve line, so if you put the -ve terminal of your voltmeter on one of the main -ve connections from the power supply you should be able to measure +12 on D8+ at all times. When the bed is off you should also see +12 on D8-, and when the bed is on D8- should fall to 0 - so that's the first thing to check. If D8- doesn't change when you turn the bed on then the problem is either in the firmware configuration (wrong pin defined for heated bed), or in the mega2560/ramps hardware.

As an aside, I don't like the way the bed + is taken through the ramps just to route it through the poly fuse, it adds an awful lot of heat for very little benefit. I'd recommend taking a 12v line directly from the psu to the bed heater to dramatically reduce the amount of heating on the electronics board. Put a 15A inline fuse (for a standard mk2 heat bed) in the heat bed 12v line to keep things safe. Car blade fuses work well and are easy to obtain, but there are plenty of different inline fuse holders to choose from.
Re: Ramps 1.4 not heating up
January 08, 2016 10:16AM
Hello again, I have tested and as you say, when bed is off, there are 12v between ground and D8±. But when I turn on the bed, nothing changes. I havent changed the pins.h (I think that thats the name of the pins configuration file) so should I order a new ramps + arduino? If the D8/D10 of the ramps board are the same pins of the Arduino, I can test it out which is the faulty one. If is not like this, please tell me how could I test it. When I finish making my printer work, I'll connect the bed as you have told me. Thank you for your recomendation.
Re: Ramps 1.4 not heating up
January 08, 2016 10:27AM
You shouldn't need to change anything in pins.h - it pulls in correct settings based on the MOTHERBOARD def

// The following define selects which electronics board you have.
// Please choose the name from boards.h that matches your setup
#ifndef MOTHERBOARD
#define MOTHERBOARD BOARD_RAMPS_13_EFB
#endif

I see you have yours set to the numeric 33, but that should be right for extruder, fan & bed (as shown in boards.h). The firmware compiled successfully after you made the changes, and uploaded ok? I had a couple of embarrassing diversions where I made changes and forgot to reflash the new firmware onto the board. Are you monitoring the log output from the board? Sometimes that gives clues to what is going on.

Another thing to check, my ramps was a budget-friendly version, and it came with a couple of dry joints on the mosfets. You might want to check the soldering and touch up if necessary.
Re: Ramps 1.4 not heating up
January 08, 2016 11:40AM
I have made the modifications in the code and I havent either seen any soldering defect on the board. The problem continues
Re: Ramps 1.4 not heating up
January 08, 2016 12:08PM
How mysterious. The schematic shows the mosfet control being a direct connection (via a 10 ohm resistor) to the D8 pin on the mega2560 PWM connector. You could check for changes on that pin directly to see if the mega2560 is switching the right pin. How are you sending the commands to turn the bed on and off? Have you established that any other communication is working, i.e. reading endstops or moving steppers?
Re: Ramps 1.4 not heating up
January 08, 2016 02:44PM
I am sending via Pronterface. Everything else is fine, In fact if the heatbed/hotend were able to heat up, I would be able to make my first printing. So if I write a simple program for arduino telling to put in HIGH pins D8/D10, both should start working, else there is some kind of defect in the electronics. Am I wrong?. I forgot to answer that there isn't any strange thin in the feedback, only that when I try to extrude, the printer doesnt allow me, as it needs a minimum of 170ºC to extrude, but if I change the minimum temp to 5 for example, there is not any problem
Re: Ramps 1.4 not heating up
January 08, 2016 02:47PM
I think that's correct, high to switch on the mosfets would be what I expect. You might want to look at the ramps test code in case it is useful (I haven't tried it) : [reprap.org]

Hope you find the answer soon, I know the excitement of that first print! I'll be kicking myself if I missed something obvious.
Re: Ramps 1.4 not heating up
January 08, 2016 02:56PM
I have tested uploading blink with the pin number changed, and the arduino is not giving any voltage. The ramps is till conected to it, should I unattach it to test? (as maybe there is some kind of short cicuit?). I dont know either if I am trying it properly; one side of the voltimeter to the GND pin between aref and D13 and the other to D8
Re: Ramps 1.4 not heating up
January 08, 2016 03:02PM
Any ground connection will do, as all grounds should be common, then the other probe of the voltmeter to the pin you are interested in.

Yes, the next step would be to remove the ramps and connect directly to the mega2560 to identify if the fault is on the mega or the ramps. Make sure everything is disconnected from power before unplugging.
Re: Ramps 1.4 not heating up
February 20, 2016 07:53AM
If wiring the Heatbed (or Hotend) directly to the PSU how does ramps control them?
Re: Ramps 1.4 not heating up
February 20, 2016 08:07AM
Quote
MechaBits
If wiring the Heatbed (or Hotend) directly to the PSU how does ramps control them?

Are you referring to this?

Quote

I'd recommend taking a 12v line directly from the psu to the bed heater to dramatically reduce the amount of heating on the electronics board. Put a 15A inline fuse (for a standard mk2 heat bed) in the heat bed 12v line to keep things safe.

The mosfet on the ramps is in the negative line - it switches the return to ground. So taking the +ve supply to the bed directly from the PSU (via a fuse) doesn't change the ramps ability to control the heater.
Re: Ramps 1.4 not heating up
February 20, 2016 09:07AM
I'm sure your right, it just makes no sense to me, simply because i just dont get how it works(hangs head in shame) even though this is simple stuff, my logic says + supplies the power it goes through the heater, then to -(or ground?) on ramps, so in my head by the time the board knows whats going on via thermistor...it's too late to do anything about it, how does it alter things?
(unless this point has a way to switch from ground to something else, so the heater gets hot, the only way I can think about it)

I know it's what I want to do to take the load off the board...the relay thing makes a little more sense to me, but still pondering which setup I want.

Also the LED supply has 3 separate rails, what would happen if these got mixed up, ie pos on 1, but retuning to neg on one of the others, something i've not done because it doesnt seem right, but it could happen by mistake.

Edited 2 time(s). Last edit at 02/20/2016 09:21AM by MechaBits.
Re: Ramps 1.4 not heating up
February 20, 2016 09:24AM
Yes, I remember thinking the same thing when I was first introduced to switching on the negative side. There's two things that I found helped to understand it, the first is that the bed is either fully on or fully off, so the ramps is acting just like a physical on off switch. The appearance of variable control just comes from switching the heat bed on and off quickly and for varying amounts of times. And the other thing is that electricity always flows in a circle, so if you have a switch in a circuit it doesn't matter where in the circle you put it - if the switch is open no electricity can flow around the circuit, so in our case, no heat added to the bed. For years I always tried to make switches in the line from the +ve supply to the thing being powered, and then when I discovered that a lot of times it's just easier to put the switch between the thing and the -ve it was a bit of a shock smiling smiley
Re: Ramps 1.4 not heating up
February 20, 2016 09:44AM
Almost getting it...the -ve on the ramps must have switching ability then, but what does it switch to, circuit, no circuit, off on ....it's sinking in slowly smiling smiley

I still cant see the circle as it starts at the psu and ends at the ramps, not back to psu.

Edited 1 time(s). Last edit at 02/20/2016 09:46AM by MechaBits.
Re: Ramps 1.4 not heating up
February 20, 2016 09:45AM
Quote
MechaBits
Also the LED supply has 3 separate rails, what would happen if these got mixed up, ie pos on 1, but retuning to neg on one of the others, something i've not done because it doesnt seem right, but it could happen by mistake.

The three connections will be connected together internally, so it doesn't matter which one you connect to - no need to try and match pairs of connections. They just put the extra connectors to make it easier to connect multiple wires.
Re: Ramps 1.4 not heating up
February 20, 2016 09:49AM
Yes my wiring is all very linear, but I was wondering about simplifying things with a common -ve
Re: Ramps 1.4 not heating up
February 20, 2016 09:55AM
Quote
MechaBits
Almost getting it...the -ve on the ramps must have switching ability then, but what does it switch to, circuit, no circuit, off on ....it's sinking in slowly smiling smiley

That's right, the negative connector on the ramps that we connect to the heat bed goes to the mosfet next to it. When the mosfet turns on it allows the current to flow from the heat bed to the negative power wire at the ramps power connector. Think of the mosfet as just a switch and everything looks simple and sane.
Re: Ramps 1.4 not heating up
February 20, 2016 10:13AM
Which connections were you thinking of making common? There's quite a lot of current flowing back through the negative wires, so it's worth keeping both negative connections from the RAMPs to the supply. It helps spread the load across the power connector on the ramps board as well as reducing the heating in the wire itself.

On the other hand, because the hot end heaters and the print fan are also switched on the negative side, I have thought about using a common positive line up to the print head to save on the number of wires going through the cable chain. I shall probably do that at some point.
Re: Ramps 1.4 not heating up
February 20, 2016 10:20AM
No Idea just yet...mainly from things with thin wires, fan's, lights, evil lasersmoking smiley,
I have been spreading it out across the 3 outs, which increases the amount of wires, but if I get second PSU,
I was hoping to run hotend & bed from that, then all the wires on the other PSU would be pretty lightweight.
You might want fan on when heater is off, so -ve's would go to different points?

Edited 1 time(s). Last edit at 02/20/2016 10:22AM by MechaBits.
Re: Ramps 1.4 not heating up
February 20, 2016 10:30AM
Yes, I'd have to keep individual wires for each -ve line so that the switching still worked, but I could save a couple of wires on the positive side. I was looking at how many cables I have to run to go dual extruder, and saving a few seemed like a good idea! Not sure if I can get down to a single + ve line for both extruders or not. I need to look at the total current and see what size wire I would need and how flexible it would be. It probably makes more sense to use two smaller ones than a single big one.
Re: Ramps 1.4 not heating up
February 20, 2016 11:38AM
I'm sure the fact that electricity is invisible is playing havoc with my visualization of whats going on,
but thanks for trying to clear things up, I think I have a better grasp of it now.
Sorry, only registered users may post in this forum.

Click here to login