HICTOP i3 extruder failure - motor or control board?

HICTOP Reprap Prusa i3 printer has been working fine for about 3 months after learning it, calibration and firmware updates (currently Marlin 1.1.0-RC4). Last night I was re-calibrating e-steps for final firmware update to EEPROM as I have done before now most my calibrations are completed. Well, I accidentally hit the [move 100mm area] instead of the 1mm move on the manual control using Repetier Host. Even with a pre-heated hot end the extruder motor of course tried to fee 100mm of filament right away, first time I have heard the filament grinding and it took a few seconds to power off the printer.

Problem now is I cannot calibrate the e-steps, it's all over the place and the original e-step now under extrudes by 6mm (it was close to 1-2mm). It appears the motor now appears to be jerking or 'banging' on startup/acceleration as you can hear and feel it and also appears to have some backlash even with the motor removed and just feeding cold filament without the hot-end (no load or end pressure). When it steps, it is kind of 'rough feeling'. This original motor has been working fine with the original e-step value and never paid much attention to it, until now. Again the motor moves, just not smoothly nor reliably as it used to prior to commanding 100mm. If that feed did cause this, I sure hope this will be a example to others to be careful during e-step calibration.

Question: is determining if the motor is bad, or somehow the controller/motor driver got fried? I have no spares... and yes, I'm fairly electrically/engineering literate. Meter, o'scope, etc. Pin out's of controller and motor are in order.

Thanks in advance.

George

---

Edited 1 time(s). Last edit at 04/13/2016 02:06PM by GeorgeL16.

Fixing to try and swapping out the X-axis motor with the extruder motor, first by swapping cables, then possibly motors. Update later...

George

---

Currently it 'appears' that the controller is faulty. When the X-axis and e-step motors are swapped cable wise AT the controller connectors, the X-axis motor (now e-step) appears to 'chunk' and miss steps, the e-step (now X) seems to work fine. It is also noted that when the X (e-step) motor stops moving, the e-step motor is no longer locked by the controller in a fixed position, it's like a 'disable motor' command has been issued and moves freely all the while the X motor is still held in position. Interesting.

Has anyone blown a controller board by locking up a stepper motor? I would assume it would possibly cause an over-current on the driver and cause it to fail, but this one has not completely failed as the motor still moves, well... sort of.

---

Edited 1 time(s). Last edit at 04/13/2016 03:50PM by GeorgeL16.

It would be unusual to do any damage just by attempting to extrude filament. Motor stalls are normal and should do no harm, and if an extruder doesn't stall it typically just chews a hole in the filament - again, very normal and harmless. The easy way to damage a stepper driver is if the cable becomes disconnected while the power is on. Other than that, you have to try pretty hard. Still, it sounds like something has gone wrong for you, so a spare driver might be a fairly cheap way of checking that out. You could also check the simple stuff, like the drive gear coming loose (if you are using a mk8 style extruder), and the Vref being correctly set on the stepper.

since as you say you have a scope why not look at the waveforms out of the controller to the stepper and in doing so we could all get a look at what the output is like

The controller is a HICTOP single board with the stepper drivers built into the board. If the driver fails, it will require a new board. I may purchase a RAMPS 1.4 board on-line that has external driver modules for replacement without replacing the whole controll board.

Have designed stepper motor assemblies over the years, however it has been a long time. They are not complicated to interface and the waveforms are basically just a pair of phased A and B square waves. A 'net link here:
[www.nxp.com]

So I figure it might be an intermittent issue with the E0 (extruder) driver on the board. Have swapped cables, etc. and it appears that particular E0 output is the one that is causing the trouble. I tried re-configuring firmware to use 2 extruders and using the E1 output to drive the E0 motor, had no luck there getting it to work due to no thermistor in both E0 and E1, although I tried 'cheating' in software to ignore the E1 thermistor.

O'scope is acting up so was unable to look at the waveforms.

Looks like a replacement controller is in order. Let you know how it goes.

---.

You can configure the firmware to just use the E1 pins/driver instead of E0, no need to try and fake up dual extruders for that.

Quote
JamesK
You can configure the firmware to just use the E1 pins/driver instead of E0, no need to try and fake up dual extruders for that.

First thank you very much for at least letting me know it is possible to swap a single extruder printer to be enable to be driven by the E1 controller instead of the default E0.

OK, making sure I understand completely understand firmware wise. Here the number of extruders would stay at 1 correct? :

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

So do I just disable TEMP_SENSOR_0 and enable TEMP_SENSOR_1 and physically swap the thermistor input to sensor input 1 on the RAMPS board and it should work? :

// ORIGINAL:
#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

// CHANGE TO:
#define TEMP_SENSOR_0 0  // CL: disable E0 thermistor
#define TEMP_SENSOR_1 1  // CL: enable E1 thermistor to debug E0 motor/controller
#define TEMP_SENSOR_2 0
#define TEMP_SENSOR_3 0
#define TEMP_SENSOR_BED 1

On a good note at least as of yesterday, my Marlin 1.1.0-RC4 code and firmware EEPROM settings are finally dialed in, small objects (20x20mm test cube) were printing very well with just power on, load .stl and print without having to re-configure/tweak EEPROM nor use the LCD control. Just load and go (default quality).

Thanks in advance.

Yes to extruders 1, no to changing the temp_sensor, you can leave that as is. The definition of which stepper to use is in the pins_*.h files. You will need to identify which one is being used which depends on the motherboard type that is set in configuration.h. If you're lucky it's obvious which of the pins_*.h files is being used, but if not you can track the convoluted mapping through the .h files. For example, I have in my configuration.h

#define MOTHERBOARD BOARD_RAMPS_13_EFB

These are mapped in boards.h which also defines an oddball boolean relationship:

#define MB(board) (MOTHERBOARD==BOARD_##board)

and this is used in pins.h to include the board specific file:

#elif MB(RAMPS_13_EF || MB(RAMPS_13_EE || MB(RAMPS_13_EFF) || MB(RAMPS_13_EEF)
  #include "pins_RAMPS_13.h"

So my pin definitions are in pins_RAMPS_13.h where I find the pins for E0 and E1:

#define E0_STEP_PIN        26
#define E0_DIR_PIN         28
#define E0_ENABLE_PIN      24

#define E1_STEP_PIN        36
#define E1_DIR_PIN         34
#define E1_ENABLE_PIN      30

So if I wanted to swap the stepper driver being used for E0 and E1 I would just swap those two sets of definitions over.

Hope this helps.

[edit: emoticons apply in code blocks? Seriously? *sigh*]

Edited 2 time(s). Last edit at 04/18/2016 11:28AM by JamesK.

James,

Just FYI: I'm an old school machine coder, Basic, Fortran, Cobol, DOS, Unix, Linux, C... so I guess I dated myself . Firmware source is currently a month old version of Marlin 1.1.0-RC4-DebugFix source after giving up on the OEM 'China' supplied source which was very buggy. Much has changed in code structure here, I for the sake of me cannot understand why they do not have what I call a "GlobalVars.h" file for all external referenced variables, defines, etc. Guess they are trying to keep the code 'newbie' friendly?

You have the same MB type definition, and the pins.h file was what I was going to look at next. What you indicate makes logical sense and probably will save me some time in the long run.

Got to love debug and coding, sure keeps the gray matter active does it not? Thanks again *very* much for your input, will let you know what I find out.

Cheers,

Chip

---

Yes, the Marlin source code strikes me as a little bit odd at times. For what it's worth, I switched over to Repetier-firmware a while back which has a fairly capable on-line configuration tool that makes this sort of change rather easy. I'm not sure that there is a lot to choose between the two firmwares functionally, although Repetier has some alternative temperature management routines and defaults to a higher pid frequency that I prefer (I wasn't keen on the house lights flickering at 8 Hz).

Fixing to give this a try. Man, the motherboard type is getting crazy in the code trying to follow it! pins_RAMPS_13.h just includes pins_RAMPS_14.h... damn.

file: pins_RAMPS_14.h

// CL: swap E0 and E1 outputs to use E1 instead of E0 outputs un-comment below:
#define SWAP_E0_WITH_E1 // normal mode = comment out!
#ifdef SWAP_E0_WITH_E1
  #define E0_STEP_PIN        26 // CL: now assigned to E1
  #define E0_DIR_PIN         28 // CL: now assigned to E1
  #define E0_ENABLE_PIN      24 // CL: now assigned to E1

  #define E1_STEP_PIN        36 // CL: now assigned to E1
  #define E1_DIR_PIN         38 // CL: now assigned to E1
  #define E1_ENABLE_PIN      30 // CL: now assigned to E1
#else
  #define E0_STEP_PIN        36
  #define E0_DIR_PIN         38
  #define E0_ENABLE_PIN      30

  #define E1_STEP_PIN        26
  #define E1_DIR_PIN         28
  #define E1_ENABLE_PIN      24
#endif

Again, let you know how it goes.

Chip

---

Well, the above did not work still outputs on E0, however is now stuck displaying "Heating..." on the LCD. More to code to go through...

Chip

---

Me stupid, when you #define something, at least put it in order. E1 now moves the extruder, however no matter if you input a +E or -E move it retracts the filament, never feed it into the hot end. Man... more code to go through.

Proper pins_RAMPS_14.h edit here:

/ CL: swap E0 and E1 outputs to use E1 instead of E0 outputs uncomment below:
#define SWAP_E0_WITH_E1 // normal mode = comment out!
#ifdef SWAP_E0_WITH_E1
  #define E0_STEP_PIN        36 // CL: now assigned to E1
  #define E0_DIR_PIN         38 // CL: now assigned to E1
  #define E0_ENABLE_PIN      30 // CL: now assigned to E1

  #define E1_STEP_PIN        26 // CL: now assigned to E0
  #define E1_DIR_PIN         28 // CL: now assigned to E0
  #define E1_ENABLE_PIN      24 // CL: now assigned to E0
#else
  #define E0_STEP_PIN        26
  #define E0_DIR_PIN         28
  #define E0_ENABLE_PIN      24

  #define E1_STEP_PIN        36
  #define E1_DIR_PIN         34
  #define E1_ENABLE_PIN      30
#endif

Configuration.h E0 and E1 setup, both are correct so I have no clue yet what is going on:

// For direct drive extruder v9 set to true, for geared extruder set to false.
#define INVERT_E0_DIR false
#define INVERT_E1_DIR false
#define INVERT_E2_DIR false
#define INVERT_E3_DIR false

Chip

---

Looks like a typo in the new E0 dir pin, the old E1 dir pin was 34, you've got the new EO pin as 38

Quote
JamesK
Looks like a typo in the new E0 dir pin, the old E1 dir pin was 34, you've got the new EO pin as 38

You are correct sir. Good news is extruder is working off E1 now. Question: does the extruder ever feed then appear to retract a little while manually feeding using the LCD-Prepare->Move at 220c and slowly stepping it a 1mm at a time? In other words I can fell a slight 'chunking' and retraction while gently holding the filament and still get that what appears to be 'slop' in the motor, or is it in the firmware, i.e. retraction while manually feeding. Can push filament manually by hand and oozes out just fine. Wonder if I have a partial clog that just happened to occur at the same time as the overfeed? BTW: pin 38 was X_ENABLE, found that out when x-axis acted up.

Quote

Question: does the extruder ever feed then appear to retract a little while manually feeding using the LCD-Prepare->Move at 220c and slowly stepping it a 1mm at a time?

Good question. On my lcd the encoder seems a little bit jumpy and I could imagine that sometimes giving the reverse direction to what I was trying to do. It's not something I particularly remember noticing happening in practice, but then it's probably not something I'd be looking for either. You could try commanding the extrusion from host software instead - that should give nice smooth movements with nothing other than the direction you command.

Jim,

Change this in the Configuration.h file and you will jump no more with the LCD control:

#define ENCODER_PULSES_PER_STEP 4 // CL: HICi3 =4, was =1, Increase if you have a high resolution encoder
#define ENCODER_STEPS_PER_MENU_ITEM 1 // CL: HICi3 =1, was =5, Set according to ENCODER_PULSES_PER_STEP or your liking

Chip

---

Thanks Chip, I shall have to give that a go.