marlin firmware and half height prints

i have a nwreprap prusa i3 (nwreprap.com)
originally i misread the instructions and installed the sprinter firmware and managed to get it printing fairly well. i picked up a discount reprap extra large lcd full graphics screen with controller, and was trying to get it working (still nothing but working with the guys at http://www.makergeeks.com/xtsm12lcdra1.html on that problem)

anyway on to the problem, sprinter was running a max height of 100mm for printing (found the setting to fix that) but i upgraded to marlin (https://nwreprap.com/downloads/marli...-i3-250000.zip) for the more integrated screen support hoping that it would help with the lcd screen. in the configuration.h file it shows the correct settings for build platform (200x200x200) but when i print my 20mm test cube it comes out reliably at 50%. before switching to the marlin firmware my only height problem was when it tried printing over 100mm. am i missing something with the marlin firmware?
specs
ramps 1.4 controller
software being used:
slic3r
pronterface

any help would be appreciated!
Mike

Are you saying the calibration cube is printing at 50% of the size it is supposed to? If so, first make sure you didn't scale it down accidently when you sliced it. But if not, you can try changing the line:

#define DEFAULT_AXIS_STEPS_PER_UNIT

in your configuration.h file. There will be 4 numbers on the line. X,Y,Z & E. If you double each of the X,Y & Z numbers, the print should scale up to be twice as big.

x and y output is good but i get about half the height i should be ie 12.8mm instead of 20mm

just so you see what i mean the green cube is 20mm the rest have been printed since changing the firmware:Attachment 2902

OK.... So just scale the 3rd number. Try doubling it, recompile, flash the firmware, and re-print.

Let us know how it goes....

i double the numbers in the 3rd position from 3993.9 to 6k and the shafts spun in the coupler, so i dropped it down to 5k and got a vase print that was supposed to be 79mm tall and got this:

OK... That isn't all bad. It maybe you just need to tighten down your coupler's so they can't slip. If there is slippage, there is no way the movements will be accurate. You have to get that cleaned up first.

But if that isn't what is going on, your stepper motors might not be able to keep up with the higher step rate. If making your couplers tighter doesn't prevent slippage, some of your other numbers might be close to the limit. If so, Go find these lines. Your actual numbers are going to be different than my numbers (that are posted here).

#define DEFAULT_MAX_FEEDRATE {500, 500, 5, 40} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {9000,7000,100,700} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.

If we are only messing with the Z-Axis, we only want to mess with the 3rd number. Make the 3rd number 1/4 of what it currently is for both of these lines. The reason is we don't want to be right at the edge.

And Doing a quick calculation... We need to change that 3rd number in:

#define DEFAULT_AXIS_STEPS_PER_UNIT

to something like: 5000 * 79mm / 56.7mm = 6966

Bigmikeinil, I'll be interested in seeing how the printer works out for you. It was one on my short list of printers I was looking at.

According to the nwreprap site, the printer uses M5 threaded rods. That should put the steps per unit in the Z-axis the same as my MakerFarm i3v. FWIW, I have a configuration.h value of 4000 for Z in DEFAULT_STEPS_PER_UNIT. I agree with Roxy that if you think you were seeing the coupler loose at a value of 6000, it's probably still loose at any other value - just not as noticeable. The web site also says it uses Pololu stepper motor drivers on a RAMPS board. Was adjustment of the trimpot on each motor driver something addressed in the assembly instructions?

Have you went through the process to calibrate your extruder for the filament you're using? That'll affect the fourth number in the DEFAULT_STEPS_PER_UNIT values. The lower part of the vase appears like you might be under-extruding.

Have you measured how much change in height you get when you command a Z movement from software like pronterface or Repetier-Host? That'd be a way to keep testing the issue without burning time and filament on prints. That would also remove unknowns related to how much you're extruding and any issues you might have in the slicer software setup.

Do you get the same height if you print the same thing twice?

#define DEFAULT_AXIS_STEPS_PER_UNIT {98.98, 98.98, 4007.32, 700} // default steps per unit for ultimaker
#define DEFAULT_MAX_FEEDRATE {500, 500, 5, 45} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {9000,9000,100,10000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for skeinforge 40+, for older versions raise them a lot.


copied/pasted direct from arduino app and is current, when i measure 100mm command send from pronterface it measures out to 100.02mm which is quite good.

printbus: i think the allthread is one of the weakest links in the chain have been giving thought to upgrading them to direct drive acme screws like the ones used in the davinci xyz (dad has one) so far ive replaced bed rods and bearings (went through 36 linear bearings to find 3 that had no wobble) 2 stop switches, and various other hardware. to be honest, the drill rod stock shipped with the unit is not what a drill maker would consider first quality and are probably seconds as i found variations throughout the length of the rods.. the endstop switches were rather junky (replaced with 69 cent bulk ones)
as far as the ramps chips i have been thinking about swapping out the stock chip for the higher current one just to be safe, it is running 2 steppers on the same chip as the others that are running 1.

mjoliner: used this http://youtu.be/wAL9d7FgInk as my guide for calibration and that calibration took me from rather poor prints to rather nice prints with sprinter firmware.

as for now im going to crank out 2 consecutive 20mm cubes just to verify consistency and i have one i printed with the exact same filament before the firmware change ill post a pic of all 3 when done
thanks guys

heres the results:
left cube was printed the other day under sprinter
middle cube today first print
right cube last print

What is the height of the right one? It looks like you need to scale up your Z-Axis DEFAULT_AXIS_STEPS_PER_UNIT. And until I had things working right, I would bump down:

#define DEFAULT_MAX_FEEDRATE {500, 500, 2, 45} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {9000,9000,30,10000}

roxy thats the wierd thing, with that setting for z-axis default steps when i move it up 100mm in pronterface it measures out to 100.02mm but when i go to print something i get 50% print height

Quote:

---

Originally Posted by bigmikeinil

roxy thats the wierd thing, with that setting for z-axis default steps when i move it up 100mm in pronterface it measures out to 100.02mm but when i go to print something i get 50% print height

---

And that is a big reason why you ought to try the smaller numbers for Feedrate and Acceleration. It is possible your stepper motors can't keep up. Pronterface isn't going to use highly aggressive numbers for manually moving the carriage around. They are going to use numbers that work for everybody. So if it works when you are manually moving things around in Pronterface but not with your GCode... It is possible the GCode numbers are too aggressive.

I'm not saying this is the problem. But I am saying I would back off my numbers until the problem is understood.

I agree with Roxy. For comparison, here are the numbers MakerFarm uses as their values, and their printers can likely be assumed to be close to what you have.

#define DEFAULT_MAX_FEEDRATE {250, 250, 2, 22} // (mm/sec)
#define DEFAULT_MAX_ACCELERATION {1000,1000,5,1000} // X, Y, Z, E maximum start speed for accelerated moves.

These are considerably slower than what appear to be Marlin defaults that you're using now.

On the Pololu driver boards, I assume you're referring to Pololu Black as the higher current driver board? I think the only difference is a more efficient heat dissipation scheme on the board. IMO, unless you've noticed the heatsink on the driver board running hot (well, I'm assuming nwreprap has you put heatsinks on the driver chips), buying the fancier driver board won't get you much. You can always set the Z-motor driver for 2x the setting of the drivers with one motor if you haven't already.

If you go to the Acme screws, remember you'll have to go back in and readjust the Z value in the DEFAULT_STEPS_PER_UNIT since they have a significantly different thread.

Have you been in touch with nwreprap at all over this, since they say the firmware files they provide are pretailored for you?

ive changed the values in arduino, re-uploaded the firmware, and am printing another cube now. ive yet to talk to a human at nwreprap, they have a nack for calling back while im at work and have just received a reply to an email to them on the subject... response so far "you have to calibrate #define DEFAULT_AXIS_STEPS_PER_UNIT {98.98, 98.98, 4007.32, 700}" even tho in the email i had said i had that within .02 mm of perfect, will let you know how this cube comes out
thanks

just finished printing my cube... its now shorter by about 1.5mm than the last one!

Hi Mike. I have those couplers sitting on my bench. I think they will make a world of difference. Those three cubes above are all different sizes and the two smaller ones were made with no changes between them - that can only mean those couplers are slipping or you are losing steps. I know how loose the slip coupler seemed to me, that's why I ordered the couplers. Swing by and pick them up in the morning. BTW, I printed out a couple knobs for the top of the 5mm threaded rod so that it will be easier to adjust them on the fly. I can't address the software issues, you know that's where I'm weak, but that stuff you are seeing appears hardware related to me.

Dad

ok this morning ive made up my mind that i would rather be able to print stuff than have a working screen and not be able to print stuff so im going to reup my original firmware and fix the bedsize issue and then dig through the marlin code a little more to see if i can figure out whats causing the issue with print height. ill keep you guys posted on how it goes. thanks!

Incidentally.... There have been some posts about fixing LCD Panel corruption if you search for them. Some of the panels can be fixed by just having the firmware periodically reset the board. I don't remember the specifics, but the problem had to do with the board getting out of phase when writing 4-bit nibbles to it to form a byte.

my screen problems are basically: 1. couldnt find all of the code niblets the instructions said to enable. 2 screen lights up with no data displayed. 3. printer is not picking up the sd card slot. (sais sdinit fail when connecting in pronterface) have been going back and forth with support for the screen with josh at makergeeks. printing a test cube now and it looks a lot better since uploading sprinter again

latest cubes after switching back to old firmware (sprinter) left to right -- block before marlin - test blocks with marlin -- and after reupload of sprinter

Perhaps there is somebody who would be kind enough to share their Marlin file with mike. It would help a lot to have one that does work the lcd to examine for his error with it? I know the stepper numbers will be different and so on, but having a copy that we know works might make all the difference.

Mike, even if you switch back to the first one, we know the couplers are a problem. A weak spot that must be fixed. Lets do that anyway??

true ill be over a little later this afternoon thanks!

Quote:

---

Originally Posted by stargeezer

Perhaps there is somebody who would be kind enough to share their Marlin file with mike. It would help a lot to have one that does work the lcd to examine for his error with it? I know the stepper numbers will be different and so on, but having a copy that we know works might make all the difference.

Mike, even if you switch back to the first one, we know the couplers are a problem. A weak spot that must be fixed. Lets do that anyway??

---

There might be a lurker who'll jump in, but I don't recall anyone frequenting this area of the board that has the 128x64 graphic pixel type of display. Most of us have the simpler 20x4 character displays. If you think that Marlin version would be of use to you as a reference, go to the MakerFarm subforum and look for the thread on the Marlin firmware fork for the MakerFarm i3v printer. That is based on a pretty current version of Marlin.

bigmikeinil, As I said before, definitely work to fix the couplers if you've seen them slipping at any speed, any acceleration. I'm not sure what kind of coupler nwreprap uses, but the plastic tubing ones on MakerFarm and commonly used elsewhere tend to soften with temperature. IMO, having one good print on Sprinter firmware first thing of the day isn't all that conclusive. That could change as the Z-motors warm up and soften the couplers if they are plastic.

If you do think you have a firmware issue in Marlin, try comparing the configuration files between sprinter and Marlin to see where they're different. Sure the syntax will be different, but what you're looking for are differences in values for similar settings.

And don't forget to calibrate the extrusion setting in Marlin. Your last settings still suggest you're running with the default of 700 steps per unit for it.

well aaron over at nwreprap contacted me today and helped me tons! we seem to have the height issue worked out, in marlin even. a few more tweaks and ill have it printing like it was in sprinter. never made it over to pickup the new couplers today will have to do that tomorrow. thank you all for your help! hopefully soon enough ill be able to help other people out with theirs.

Did you get the lcd working? I've been working on my "simulator", but all I get is the backlight on.

So, what were the changes nwreprap had you make to the Marlin firmware that solved your problems?

Quote:

---

Originally Posted by printbus

So, what were the changes nwreprap had you make to the Marlin firmware that solved your problems?

---

I think there was code posted... But one of our members here knows all about the LCD Panel corruption and how to work around it. If you search for i^2c you will find where I got corrected on how the panels work and the code (and explanation) that you want.

Quote:

---

Originally Posted by Roxy

I think there was code posted... But one of our members here knows all about the LCD Panel corruption and how to work around it. If you search for i^2c you will find where I got corrected on how the panels work and the code (and explanation) that you want.

---

Roxy - I could have elaborated, but I was wondering about the changes specific to the half-height problem. As to the display issue, the OP is trying to add a graphic display panel onto his printer, not one of the usual 20 characters by 4 rows jobs. I have no idea whether the graphic panels use the same nibble interface that the character displays do, but I'm guessing the interface could be quite different. I'm actually the one who explained the character corruption issue we can get on the 20x4 displays, but it's not related to the OP's display issue. FWIW, the thread where I discuss the 20x4 screen corruption problem is in the firmware enhancements to marlin area - http://3dprintboard.com/showthread.p...ed-LCD-screens

FOLLOWUP COMMENT: The pixel mapped graphic display modules don't have the nibble transfer mode, so the nibble-sync issue that leads to corrupted text on the 20x4 LCD modules shouldn't be possible. Marlin communicates with the graphic module using Serial Peripheral Interface (SPI), like it does with the SD card.

Quote:

---

Originally Posted by printbus

Roxy - I could have elaborated, but I was wondering about the changes specific to the half-height problem. As to the display issue, the OP is trying to add a graphic display panel onto his printer, not one of the usual 20 characters by 4 rows jobs. I have no idea whether the graphic panels use the same nibble interface that the character displays do, but I'm guessing the interface could be quite different. I'm actually the one who explained the character corruption issue we can get on the 20x4 displays, but it's not related to the OP's display issue. FWIW, the thread where I discuss the 20x4 screen corruption problem is in the firmware enhancements to marlin area - http://3dprintboard.com/showthread.p...ed-LCD-screens

---

OK! Sorry to interrupt! Thank You for the explanation!

It irks me when manufacturers and retailers don't provide sufficient reference information for their products, or worse yet, when the information they provide is incomplete or outright wrong.

Makergeeks provides two sets of instructions on how to enable the graphic module support in Marlin - printed text on the product page and the "how to hook up..." video on the product page. IMO, the text guidance on the product page is outright wrong, even ignoring the typos and errors that are waiting to surprise the non-programmer. The text appears to be the changes necessary to add a typical 20 x 4 character smart panel, not the graphic bitmap style. The firmware change instructions in the video are likely what you need, but I think there's one important problem in what the video says. It talks about how if the configuration.h file in your Marlin source doesn't have a commented #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER that you can uncomment, you should just add the #define statement for it. Huh? That might work, but only if the rest of the code is already there to react to that #define. I would say that if your configuration.h file doesn't have that commented line waiting for you, you need to look into whether the Marlin version you have has the graphic panel support there. As a minimum, I'd search the Marlin files to see if they already contain the REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER text anywhere. If not, you need to find a newer version of Marlin to be working with, since just adding the #define for a new display type won't get you diddly squat.