Show all posts by user
I think it is more likely that you have the wrong display type configured. There are a lot of people at github.com/MarlinFirmware/Marlin that do work involving the LCD Panels. It might be worth while starting a thread there and asking. I suspect you will get an answer very quickly and it will be correct.
by
Roxy
-
Firmware - Marlin
Quotegaraguido
i used the newest Arduino software 1.6.8 with RC5 and there where no errors at all .
The release notes are not emphatic enough. But you REALLY need to use Arduino V1.6.8 because we think we have found some compiler bugs in the earlier versions. 1.6.8 looks like it can handle all of the Marlin code correctly.
by
Roxy
-
Firmware - Marlin
Are you using Arduino for other purposes? Some people do and end up with the u8glib being in multiple places. The one included with Marlin is the one that has to be used with Marlin.
by
Roxy
-
Firmware - Marlin
Quotefoot2theballs
I know warnings don't mean I can't upload the firmware to my board, but I'd like to clean up any sloppiness when I find it...I'm a bit of a perfectionist when it comes to these things. I suppose I could just flash it to the board now and fix the warnings later though. And hoxsiew, what I posted in the OP is all that Arduino gives me when I verify the code.
I suspect it is alre
by
Roxy
-
Firmware - Marlin
That is perfectly fine that you replaced the line with one that did not give you a warning. But you didn't have to do that. It was just the compiler alerting the programmers that they had gotten a little be sloppy on the type definitions.
by
Roxy
-
Firmware - Marlin
I don't know the specifics. But pin assignments changed between the two versions of the board. I think the Z-Probe Servo pin is one of them that changed.
by
Roxy
-
Firmware - Marlin
Probably the best thing to do is take your Configuration.h file and cross its settings over to the RCBugFix branch at GitHub.Com/MarlinFirmware/Marlin.
A huge number of improvements have been made and anything that doesn't go right, you can easily get questions answered.
by
Roxy
-
Firmware - Marlin
Are you running the Release Candidate? Specifically, RCBugFix? That is your best bet. This has changed depending upon the version you are running.
I think you want to make sure you have:
#define LANGUAGE_INCLUDE GENERATE_LANGUAGE_INCLUDE(en)
#define DISPLAY_CHARSET_HD44780_JAPAN // this is the most common hardware
#define ULTRA_LCD //general LCD support, also 16x
setup in your
by
Roxy
-
Firmware - Marlin
It sounds like you are not able to control the pins that turn on the bed and extruder heat. Has the printer ever worked correctly? Because, there has been a change in the RAMPS board, and it is possible you are defining the wrong board. Although, I think this was just a Z-Probe servo issue.
I'm not sure what to tell you other than you need to find out what pin controls the extruder's
by
Roxy
-
Firmware - Marlin
P 3 says do a 3x3 grid. V4 is the maximum verbose level for G29. T gives a topographical map of the probed bed.
May I suggest you start a similar thread at GitHub.com/MarlinFirmware/Marlin ? I know there were some Core-XY AutoBed issues with RC4 and I have a hunch you will get quicker answers over there.
by
Roxy
-
Firmware - Marlin
What Baud rate do you have PronterFace set at? Also, if this is the first time using PronterFace you need to load some USB Serial Drivers to let it get out the USB port and talk to the AVR board.
by
Roxy
-
Firmware - Marlin
M503 will print out the currently active settings. So if you boot up, it will load values from the EEPROM, and when you give it a M503 you can see everything.
by
Roxy
-
Firmware - Marlin
Nearly everything is A-OK! The code is getting very solid.
Give it a try!
by
Roxy
-
Firmware - Marlin
Quotepsiewert
What really confuses me is that even if I download the Ultimaker2Marlin config.h from GitHub it still doesn't work. Maybe I need to play around with the wiring.
Well... Start small. First bring up PronterFace and make sure the nozzle moves in the correct direction for X, Y & Z. Then verify correct movement with M114.
And then... When all of that behaves as you expect.
by
Roxy
-
Firmware - Marlin
QuoteOriginal Poster:
I've tried inverting the MAX end stop to a MIN, inverting Z axis direction, and changing the MANUAL_Z_HOME_POS but nothing works.
The bed will never raise to the hot end until I start a print. Mesh bed leveling isn't CRITICAL as I could always just calibrate by hand before printing but I'd rather use Marlin.
Does anyone have a suggestion? Here's my config file.
Delta's
by
Roxy
-
Firmware - Marlin
We are trying to make these options easier to configure. If you follow the directions, these options all work. But I have personally Crashed and Burned because I was too quick and over confident while setting end stop options:
Please Check Out:
by
Roxy
-
Firmware - Marlin
It doesn't really matter which way your motors turn. From what you are describing, your printer is moving correctly. The reason it is important to have the correct hand for your coordinate system is the Auto Bed Leveling matrix will be inverted if that is wrong. When the nozzle should be moving up, it will be moving down and vice versa.
by
Roxy
-
Firmware - Marlin
QuoteHarvey_S
When I decided to add auto bed leveling, I updated to the latest stable Marlin (1.1.0-RC3 - 01 December 2015). One decision that I made (and the source of my problems), is to keep the Z home switch separate from the Z probe used for ABL.
You may not realize this... But the RCBugFix branch is always better than the RC branch... The RC branch is frozen and RCBugFix is the RC branc
by
Roxy
-
Firmware - Marlin
For sure you lose resolution. I don't know what happens with the Sli3r's. I know Slic3r moves the Z-Axis in partial steps when it is doing support material. But Marlin will work.
I think you are worrying too much about partial steps. Everybody uses the micro-stepping and it seems to work OK.
by
Roxy
-
Firmware - Marlin
That capability is not built into Marlin currently. But it is literally a one line change (addition) to do it. You would simply add a delay(100); at the start of the run_z_probe() routine.
by
Roxy
-
Firmware - Marlin
My guess is you have a left handed coordinate system.
Check out:
by
Roxy
-
Firmware - Marlin
It will note the location that the endstop triggered. And this will not be a full step typically. This will be at some micro-step.
by
Roxy
-
Firmware - Marlin
Go into your Configuration.h file and turn on:
#define AUTO_BED_LEVELING_FEATURE
But you will also need to define things like X_PROBE_OFFSET_FROM_EXTRUDER, Y_PROBE_OFFSET_FROM_EXTRUDER, Z_PROBE_OFFSET_FROM_EXTRUDER. And... You will have to configure the servo information also. And... That assumes you want the default Auto Bed Leveling. There are several flavors (and required configurat
by
Roxy
-
Firmware - Marlin
This post is just a head up for everybody using Marlin on their 3D-Printers. Release Candidate #4 is getting very stable and the bug reports have dropped off to mostly being support questions. Very soon, we expect to promote RCBugFix to be the new, official, stable release of Marlin. If you know of any issues with RC-4, please let us know about them ASAP!
PS. A really big Thank You! to
by
Roxy
-
Firmware - Marlin
My guess is you didn't turn on the G29 stuff. You need to change a number of #defines in your configuration.h file to turn on the G29 stuff.
by
Roxy
-
Firmware - Marlin
I would start small... I would verify that PronterFace can move the nozzle in the directions that I tell it to move. I would look at the output of M114 and M119 to make sure the machine is sane.
by
Roxy
-
Firmware - Marlin
If it starts raising the effector after it starts doing the bed probe, the problem is you are probing outside of the Delta Probable Radius. You need to probe a smaller area so the nozzle stays over the bed at all times.
by
Roxy
-
Firmware - Marlin
What version of Marlin are you using? I suggest you try the current RCBugFix branch. It has some SD Memory card stuff tweaked in it.
by
Roxy
-
Firmware - Marlin
This would be a very difficult machine for which to write code to control. If you want the machine to work correctly and reliably, the developers of the code would need a machine to code against.
> does anyone know how I can make it work?
My opinion is your best bet is to actually build several of these machines and see if you can get them into the hands of a motivated developer. I can te
by
Roxy
-
Firmware - mainstream and related support