Ord Hadron - Z Axis won't move down

G'day,

I have a new Ord Hadron and having an issue with the Z axis.

The Bed is a 200 by 200 job.

Using Pronterface version 2013.10.19, connects to the printer (using the IDE and command line), the X Y and Z motors move a little bit about 5 mm in the positive direction, the X and Y home buttons and the buttons on the target panel work fine but the Z moves up ok but won't move down nor does the Home Z work.

I have the bed MOSTLY built, I haven't connected the hothead resistor not the heat bed connected but I do have the thermistors wired.

Do I need the hot bed and hot head powered up?

I have attached the config and pins .h files in case I have something set wrong.

Any suggestions, ideally solutions would be appreciated.

Cheers,

I'd bet your z axis limit switch is wired wrong / connected wrong. If it's telling the Z that the switch is triggered, it's not going to move towards the switch.

You do not need to have the heated parts wired up to check the X,Y,Z axis. In fact it's a good idea to check things out one at a time. If the thermistors are wired, see if the "watch temperature" setting in Pronterface shows you a rational temperature (say 25C or so). If it does the terminators are likely set up right.

G'day Uncle Bob,

I issued an m command (can't remember which one now, and it said that x y and z where opened. I held the switch in and the command reported z triggered. Would that not suggest that the end stops are reporting correctly?

The carriage is not travelling down near the stop switch, won't travel down at all.

Just ran a test with the stepper motors not connected to the carriage rods and they spun up but not down so its not a binding problem.


Yes the thermistors are reporting 22 and 22.6, not sure if there should be a greater degree of separation, temperature wise.

G'day @goochy

Is it just the Z that wont go down? What about the other axis, do they all go in both directions?

This may not be the problem you have, but I managed to partially blow up a stepper driver, so that it would only go in one direction (No idea how that is possible, but it seemed to happen).

If for example X works in both directions, have you tried plugging one of the Z motors into X on the board.

If this is a stepper motor driver issue, you may have to unplug the stepper driver from a working axis, e,g X and plugging it into Z, albeit if there is something wrong with Z that caused it to blow up, you may end up blowing up another stepper driver.

Don't let the stepper drivers get too hot, thats how I manage to blow mine up.
I had to buy a new lot which came with heat sinks, and I added a fan to keep the whole lot cool.

G'day Roger,

To answer you Q, yes the X and Y move fully in both directions, using the individual buttons on the target (as well as the command line)

I did what you suggested, I plugged one of the Z's into the X stepper driver, and same result. Z will move (when I click any of the +X buttons, and will move back) but say I click +x1 5 times and -X1 6 times, the stepper motor only moves 5 steps back not 6 as I am expecting.

I unplugged the Z end stop and didn't make any difference.


Cheers, Steve

You have two Z motors They will need twice the current as the X and Y motors. (half current goes to each motor). I'd bet your driver Vref's are set so they are ok for one motor but not OK for two motors.

goochy

I agree with uncle_bob

Probably not enough drive to the motor.

You'll need to adjust the trim pot on the Z stepper driver.

keep turning the pot slightly clockwise and try again. (Note the trim pots on my stepper drivers seem to go around and around, so its hard to know when you are at the maximum, as they wrap around to minimum.
If you have a multimeter you could measure the voltage and ensure that you are turning it up.

I'm sure its documented in the wiki.

G'day UB and RC,

Even it there are individual stepper motor controllers for each stepper motor?

The trim pot shave a limit, roughly 360 degrees.

I forgot to mention that this is a RAMPS 1.4 on an Arduino Mega2560 R3, in case that makes a difference.

Didn't see it mentioned in the wiki.


PS, I'll wait for your replies in case the RAMPS/Arduino combo is a different kettle of fish.

Cheers,

With a normal Ramps 1.4 / Arduino setup, both Z motors plug into the same stepper driver. The driver has two connectors on it for that purpose. If you have the Z motors plugged into two drivers that's not the normal setup. You *can* do it that way. It requires some changes in the configuration files to make it work. It also eliminates a future second extruder. You use the second extruder driver for the second Z motor.

Your right, the Z axis stepper motors are plugged into the same controller.

I slowly increased the current but still no joy. Z axis refuses to go down to the bed.

Funny, that once Pronterface has connected and as soon as I click ANY button in Pronterface, the Z Axis motors spins positive for about a 10 step rotation as well as the motor connected to the button I pressed, I.E if I click +10 Z and X will spin but after that, I can manoeuvre X and Y up or down, in or out, go home etc.

Its like there is a setting in Slic3r (I believe Pronterface gets its info about the bed size and axis settings from Slic3r?


I hope there is a solution somewhere.

Cheers.

definitely something strange going on.

If you press the X+ button, only the X motor should move. etc.

You can test the same thing by sending commands to the Arduino / Ramps

If you send G1 X20 F2000 the X carriage should travel to position 20mm from home
Same for
G1 Y20 F2000
G1 Z20 F2000

(F2000 is just the speed you can omit this)

anyway, there should be no cross talk between axis, i.e each command should only move the printer in one axis

to move in all 3 axis you can do

G1 X30 Y30 Z 30 F2000

I'm not an expert in Marlin, but its possible that you have got some weird build for a completely different type of printer

Where did you get your version of Marlin from? If you PM me your email address I can email you the zip file of my mendelmax Marlin build, which works fine for me.

BTW. Where are U. I'm in Melbourne.


Re: Slic3r

Slic3r just converts models (STL) into a series of motor move commands, which Pronterface sends to the Arduino board, and the Arduino board sends messages to the stepper driver modules telling them to move the motors by the correct distance.

You have to enter your bed size into Slic3r so it knows where the center is, and how far it can position objects from the center.

But you need to get the basic stuff working in Pronterface before you bother trying to print code generated by Slic3r

G'day Roger, your suggesting of using your configuration.h file with sections copied over from my configuration.h relevant to my Hadron worked.

I have a working X Y Z now, X Y Z now go home although it still does lift Z up abouyt 10 mm with the very first command sent via Pronterface.
Perhaps I have set something in Slic3r.

Many thanks for your assistance.

Cheers.

I would very carefully go through the configuration.h file and make sure that the settings there all match your printer. There are hundreds of variations on these printers. Matching up the firmware to the hardware is a very important part of the build process.

At the very least you need to be sure of:

1) End stop setup and configuration
2) Steps per mm for X,Y,Z and extruder
3) Speed limits and acceleration limits
4) Electronics board type
5) Thermistor type (thermistor table)
6) Max and min temps for heated bed and hot end

There are also settings if you have an SD card and / or an LCD display.

G'day Uncle Bob,

Yes, i was quite careful to only accept deltas that were relevant. my supplier got back to me and pointed out what was wrong in my original firmware, i revrrted back to that and now all working.

cheers,

OK, So I now have all the axis moving they way they should without printing/extruding, except now when I print a file, X and Y move (following the drawing in Pronterface) correctly, Z initially moves to its start position but won't go up, I end up with squished plastic.

In the configuration.h I have the following;
// Disables axis when it's not being used.
#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z true IS THIS CORRECT?
#define DISABLE_E false // For all extruders

#define INVERT_X_DIR true // for Mendel set to false, for Orca set to true For my printer, the Ord Hadron, Sould it be a Mendel or Orca?
#define INVERT_Y_DIR true // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR true // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false // for direct drive extruder v9 set to true, for geared extruder set to false

Any guidance would be appreciated.

Cheers,

Ok, there are only two home locations that give you a positive Z with a normal file. You can either home to the top right or to the bottom left. The other two locations (bottom right and top left) give you a negative Z. It's one of those silly right hand rule sort of things. You could re-write the slicing code to change all that. It's easier to change the home location.

Ok. So if the .h file looks ok, then I must have a wrong setting in either slic3r or pronterface.

Any clues as to what a hadron should be?

cheers

@goochy

It seems odd that this would be a Slic3r issue.

Are you sure the calibration is OK in Z. How far are you telling it to move in pronterface (in the Z axis) have you measured that 10mm commanded = 10mm moved (in Z)????

Also take a look at the GCode file you created, and see if you can find the lines where it moves the Z axis upwards, ie at the end of each layer. If you use a text editor and just search for the letter Z you should see it as part of the move command

Or you could write a dummy gcode file that had some moves in X and Y and then in Z and see if the printer responds as you'd expect. (it doesn't need to extrude at the time)

Oh. One more thought, check how fast the GCode file attempts to move the Z, I guess it could be something to do with that.

The config file needs to match the location of the switches on your printer. Without knowing where you have mounted the switchest's the combination of the file settings and the switch locations that makes things happen. it's difficult to know where you home just looking at the file. It's real easy to see on the printer. When you hit "home" it either moves the head to the top right or the bottom left of the bed. If it goes to either of the other two corners, you will get negative Z. I

To change the slicing process, you would need to go into the source code for Slic3r and re-write it for an upside down Z axis. I suspect you *could* do that. I would not want to spend the time on it.... I can think of no way to do it in Pronterface. That's just a feeder program for the printer. It does not do anything to the gcode.

G'day Uncle Bob,

The printer goes home bottom left.

Good idea about using the g codes.
Looking at the gcode file, there are instances
of g1 z0.35 at the start down to z10.100 near the end.

So it looks like it should be lifting the z axis.

If its not the software then non aligned rods or not enough current
to the motors which is odd as when not printing, the motors work fine.

goochy

Any luck getting the printer to work ?

Have you tried asking the company to send you a Gcode file that you could try on your printer?

My MendelMax kit came with a cube test gcode file that I was able to try even before I had figured out how to run Slic3r etc

You could try running your Gcode though [gcode.ws] and see if it looks like its lifting the Z axis as it prints.

The only other thing I can think of, is that your PSU is not delivering enough current when you have all 4 motors running.

Have you tried using Pronterface to send something like

G1 X100 Y100 Z50 F2000

This should drive all 3 motors at the same time. If the Xand Y don't move to 100mm and the Z to 50mm its something to do with the electronics and the PSU etc

G'day Roger,

I'll try it in the morning, thanks for the g codes.

i hope it is a config thing,

the supply has sent me a link to a calibration thing via thingiverse, will try your codes and uncle bobs suggestions as well.

cheers

You can send the Z motion gcodes to the printer one at a time. That's what Pronterface is doing when you tell it to move up or down on the Z axis.

What are you using for slicing software? It sounds like you are using Slic3r. If it is set up normally it will generate positive Z. That’s what it sounds like your files have in them. You can set Slic3r to start with a Z offset, so it can try to start below your zero point. It will print positive from there. You can also do things in relative mode rather than absolute. They still should have positive Z.

The first thing the code does at the start of a print is to home the printer. Is it the homing process what’s giving you a problem?

G'day UB and RC,

Apologies for not sending through what apps/versions I am using etc.
Ord Hadron.
Ramps 1.4
Slic3r (initially slic3r-mswin-x86-0-9-10b, have upgraded to slic3r-mswin-x86-1-0-0-RC1 to see if that made a difference.
Pronterface 2013.10.19

RC, I tried your codes G1 X100 Y100 Z50 F2000 and yes that worked, all the motors spun up and looked like it was sliding upward.
UB, I think your right there, I send all axis to home (bottom left when looking at the printer fom the front) if I use the code z 10, the z axis climbs to only 4 mm.

So somewhere I have not configured an offset perhaps?

Update:
Ok getting closer I think.
I added 5mm to Slicer z axis, exported a new gcode, ran it through pronterface and it looked like it was moving correctly.


Cheers,

Edited 2 time(s). Last edit at 11/21/2013 07:53PM by goochy.

Ok, the Z offset is something you can enter into Slic3r. You can also set it with your Z zero stop. There may be a way to mess with it in the firmware. Normally you set adjust it to zero with the stop and then leave the offset in Slic3r at zero.

All that said - yes I'm running my printer with a +0.68 mm offset on Z at the moment ... long story ...

Quote
goochy
I use the code z 10, the z axis climbs to only 4 mm.

Looks like you need to change the steps calibration in your config file, so that Z10 moves to position 10mm from the base plate.

If its only moving up 4mm when it should move 10mm, i.e 40% I'd have thought that your print head nozzle is lighly to be dragging through the last layer of the print when it goes up a layer and start again, because the Gcode Slic3r created would tell the extruder to extrude enough melted filament to be the layer height.

e.g. if first layer is at 0mm and layers are 0.3mm then the first layer will be extruded at around .3mm high.
But if your printer starts the 2nd layer at 0.3 * 40% = 0.12mm its going to be attempting to extrude into the previous layer's extrusion.

This is going be messy, as its either going to knock the first layer off the bed, or its its stuck down well, I suppose it could end up by pressing down on it and squirting filament out the sides

If you are going to check the Z calibration, start from 4 mm above the baseplate and move up something like 100 mm. That way you don't have any strange "end" issue or step resolution issues.

Ok, been off for a while.

I broke the thermistor on the Hot End right at the glass, ordered 2 new ones and they promptly arrived.

New hurdle.

Using 20mm-hollow-box from [www.thingiverse.com] as a calibration test, all seems to go well up until about 3.5 mm (of 10 mm print) and the extruder stops pulling through filament.

When I stop the print, using Pronterface, I hit the extrude button to extrude 3 mm, and the filament pulls through ( I then reverse the extrude in case it is going to cause an issue), so that seems to be all ok.

I replaced my marlin files with a working set form the supplier, and all motors are moving as I would expect.
Slic3r, I was using ver 1.0.0RC1, I replaced it with 0.9.10.56 but no difference.

Pronterface is version 2013.10.19.

I have uploaded a zip of pics of my pronterface settings and my slic3r folder in the app data dir, hoping someone can see a boo boo.

Any clues as to what is happening here?

Cheers,

Usually a filament feed stall / jam is not a software issue. It's either something wrong with your extruder / hot end / filament. About the only thing that will impact it is the max feed rate setting in your firmware. When you set Pronterface to something fast, it only will feed as fast as the firmware will allow.

Since the extruder worked after things stopped, it's not a normal jam where the filament gets chewed up and you can't feed until you pull it out. That sort of rules out crud in the filament. I'd take a look at where you have the extruder feed set in the firmware. I would also take a look at how tight your extruder is set, it may be to loose. That would let it slip without chewing up filament very fast.

Edited 2 time(s). Last edit at 11/30/2013 02:42PM by uncle_bob.

I had a similar issue recently, and the problem turned out to be caused by a loose grub screw on the extruder motor