Quantcast
Channel: Reprap Forum - Firmware - Marlin
Viewing all 12089 articles
Browse latest View live
↧

Re: babystepping z

September 18, 2018, 11:12 am
$
0
0
I use babystepping from the LCD control It works great .

I print a skirt and adjust while watching for the perfect height. below I can see and change watching the numbers on the LCD.

I should change the Multiplicator to a higher number like 10, 2 is way to fine.

#define BABYSTEPPING
#if ENABLED(BABYSTEPPING)
#define BABYSTEP_XY // Also enable X/Y Babystepping. Not supported on DELTA!
#define BABYSTEP_INVERT_Z false // Change if Z babysteps should go the other way
#define BABYSTEP_MULTIPLICATOR 2 // Babysteps are very small. Increase for faster motion.
//#define BABYSTEP_ZPROBE_OFFSET // Enable to combine M851 and Babystepping
//#define DOUBLECLICK_FOR_Z_BABYSTEPPING // Double-click on the Status Screen for Z Babystepping.
#define DOUBLECLICK_MAX_INTERVAL 1250 // Maximum interval between clicks, in milliseconds.
// Note: Extra time may be added to mitigate controller latency.
#endif
↧
Search

Re: Can not get firmware working for Wanhao Duplicator i3 with RAMPS1.4 and BLTouch

September 18, 2018, 12:16 pm
$
0
0
I believe it is 1.1.x (I am not at my personal computer at the moment to make sure). When I enable #define SDSUPPORT I get the error message in the pastebin. If I do not enable it, it will compile fine, but then I do not have SD support :( Thank you
↧
↧

mintemp triggered heater_id:0

September 18, 2018, 5:56 pm
$
0
0
I have a REPRAP Prusa i3 running Marlin firmware. I just changed the extruder/hotend that came with the kit to a Tital Aero. When trying to print, the heatbed begins to warm up, but the hotend never begins to heat. I've made the changes to the firmware as required, but something isn't right. Any ideas?
↧

Re: Can not get firmware working for Wanhao Duplicator i3 with RAMPS1.4 and BLTouch

September 18, 2018, 9:44 pm
$
0
0
Don't use Arduino: 1.8.6, its very broken

use Arduino: 1.8.5, Its known to work. (Arduino: 1.8.7 is also out but untested)
↧

Re: Can not get firmware working for Wanhao Duplicator i3 with RAMPS1.4 and BLTouch

September 18, 2018, 10:38 pm
$
0
0
I tried compiling the files you provided via dropbox. Without and with sdsupport enabled. On 1.8.5 they both seem to compile just fine.
It does indeed seem to be Marlin 1.1.9


To also get your computer to compile you could try out to do a clean up of your Arduino install.


A clean-up can include:

- rename the (windows user)\documents\Arduino\libraries folder.

- delete (or rename) any arduino folders in
--- (windows user)\AppData\Local
--- (windows user)\AppData\Roaming


First time you open Arduino IDE it will create a new and empty (windows user)\documents\Arduino\libraries folder

You may need to place a copy of Newliquidcrystal_135 library in the otherwise libraries folder.
You can get the Newliquidcrystal_135 here: [bitbucket.org]

You may also need a copy of the u8glib library
Get the version that works with Marlin 1.1.9 here: [github.com]


I hope this helps.
↧
↧

Re: Can not get firmware working for Wanhao Duplicator i3 with RAMPS1.4 and BLTouch

September 18, 2018, 10:55 pm
$
0
0
So, I also tried to compile with 1.8.6 - it did not go well :-(

I get the exact error message you mention.


The error is part of a know problem with compiling Marlin firmware on Arduino IDE 1.8.6.
Arduino 1.8.6's, and possibly 1.9-beta's own use of macros, seems to have some kind of conflict with the way Marlin also uses macros.
↧

Re: can't compile with PARKING_EXTRUDER in 1.1.9, 2.0

September 19, 2018, 4:11 am
↧

Re: Can not get firmware working for Wanhao Duplicator i3 with RAMPS1.4 and BLTouch

September 19, 2018, 4:13 am
$
0
0
Ah, I see others already commented about the version of Arduino.

I just tried to compile your files with Arduino IDE 1.8.7, and the compile now works.. Let's hope the resulting sketch (firmware) also runs as well as usual.
↧
Search

Re: can't compile with PARKING_EXTRUDER in 1.1.9, 2.0

September 19, 2018, 4:34 am
$
0
0
Can we see (and test with) a copy of your configuration files?

and possibly a copy of the pins_xxx.h file you use with your board?

Edit: Ah, I see that you mentioned a patch, while I were preparing for this question.
↧
↧

Re: Can not get firmware working for Wanhao Duplicator i3 with RAMPS1.4 and BLTouch

September 19, 2018, 8:35 am
$
0
0
Thank you all so much, I was able to get the sketch compiled and uploaded using 1.8.7 (but not 1.8.5 oddly enough). Now have SD support, looks like the only issue now is that M119 command shows z_min as triggered (when it is in the air not touching anything and retracted), I have tweaked the configuration.h and made sure that the following is set:

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define X_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Y_MIN_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Z_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define X_MAX_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false // set to true to invert the logic of the probe.

I can deploy and stow the pin using M280 P0 S10 to deploy and M280 P0 S90 to stow, but like I said getting the wrong reply using M119 command. Also just to make sure I have it right, the x and y endstops should show open when they are not being triggered correct? Thanks again
↧

Re: Adding optoencoder to endstop slot to provide filament odometer - firmware help needed

September 19, 2018, 2:24 pm
$
0
0
Still hoping someone with some knowledge of the code might help here...


Never having looked at Marlin internals before I don't really have any clue what I'm doing, so more likely to break something than not (and given the time cost of each build/test cycle and the relative lack of interest in this this post it probably isn't worth pursuing, but these seem like potential points for code to enable the above steps.
I'm acually pretty suspicious I must be missing something, because on the face of it this seems such a basic enhancement, I would have thought it would have been done long ago.

I think also it would make more sense initially to use gcode_M118() [Marlin_main.cpp 8966] to echo a message to the host initially for testing then add the M117 feature later


Setting up a pin for the trigger (I use RAMPS, so everything refers to pins_RAMPS.h) I think initially I'd just hijack one of the runout pins
#ifndef FIL_RUNOUT_PIN
#define FIL_RUNOUT_PIN 19 // This co-opts pin used by #define Z_MAX_PIN 19
#endif

if you already have a runout system in place you could use one of the other 4 in runout.h
#if NUM_RUNOUT_SENSORS > 4
case 4: is_out = READ(FIL_RUNOUT5_PIN) == FIL_RUNOUT_INVERTING; break;
#endif

Would it be reasonable to modify near the following code in runout.h (which is already being called by the runout pin interrupt) to increment the odometer?
Need to check if the runout interrupt is triggers by both rising and falling signal (which would be required by and encoder wheel). Also I'm not sure how Marlin currently compensates for jitter on the endstops, as this is very likely to be an issue with the wheel too.
Also the prepare_move_to_destination() bit code would have to set a flag if it's a retract (in which case the odometer would have to decrement)

inline void gcode_G0_G1(
...
FORCE_INLINE static void run() {
if ((IS_SD_PRINTING || print_job_timer.isRunning()) && check() && !filament_ran_out) {
filament_ran_out = true;
enqueue_and_echo_commands_P(PSTR(FILAMENT_RUNOUT_SCRIPT));
planner.synchronize();
}
}

The looks like it probably refers to the the extruder current position (in Marlin_main.cpp 13651)
This would seem Iike a reasonable place to check that the filament odometer value is at the same point as the current position and set the retract flag for so the odometer was correctly incremented/decremented.
The alarm (step 3) looks like it could be triggered from anywhere with BUZZ(duration, frequency), so this section could sound this if there was a problem and somehow (?) queue the M118 message for the host;

void prepare_move_to_destination() {
...
if (!DEBUGGING(DRYRUN)) {
if (destination[E_AXIS] != current_position[E_AXIS]) {
#if ENABLED(PREVENT_COLD_EXTRUSION)


(obviously providing HAS_BUZZER == true which seems to be set if you have #define BEEPER_PIN in pins_RAMPS.h - this seems to be under LCD panel code, but there seems no reason a piezo couldn't be hooked up to any aux pin, so you could put this with #define SPEAKER in Configuration.h
[I'm not sure the difference between BUZZER and SPEAKER. the latter only seems to be used in buzzer.h for this code
#if ENABLED(SPEAKER)
CRITICAL_SECTION_START;
::tone(BEEPER_PIN, this->state.tone.frequency, this->state.tone.duration);
CRITICAL_SECTION_END;
↧

Re: Marlin 1.1.9 and Ramps 1.6

September 19, 2018, 8:14 pm
$
0
0
I have problem with ramps 1.6 and MEGA 2560 all stepper motors not move. I though that marlin for Ramps1.4 fit to Ramps 1.6. But All times figure out and not works. I contaced to BIQU RAMPS 1.6 and they gave me marlin for Ramps 1.6. And I uploaded it to Mega 2560. There a lot of errors. I think that they did not check for any 3D printer. They check their own 3d printer. What parts you have and fix in marlin will work or I do not know. BUT ONE PROBLEM about wires of stepper motor there not explain about wires(like 2B2A1A1B).
↧

Re: Marlin 1.1.9 and Ramps 1.6

September 19, 2018, 9:50 pm
$
0
0
1,6 is identical software to 1.4, so their own firmware will not change anything

motor not moving is normally one of many things

1) no 12v to the 12v 5amp connector (main power)
2) endstops not connected, or not working correctly
3) stepper motors not wired correctly
4) vref not set
5) microstepping jumpers not installed
6) dead board
7) no stepper driver modules
8) stepper driver modules plugged in backwards
9) Incorrect motherboard set in firmware

So you see you have a lot to check.

1) check you have powered it correctly and the power supply is on and providing 12v.
2) check endstop status by sending M119 to the controller, if they don't report open when not triggered, it wont move in that direction.
3) the connectors on the ramps are 2B 2A, this is the first coil, 1A 1B, this is the second coil. The labeling is from the stepper driver

4) Depends on your stepper driver modules. What do you have? Picture?
5) under each stepper driver modules is 6 pins for 3 jumpers, most should have all 3 jumpers on it
6) run the ramps test firmware to check [reprap.org] (moves all motors, turn on all mosfets)
7) you need stepper drivers modules installed
8) they need to be in the correct way... do not use the silver pot as a visual reference. As different models have it at different ends of the module.
9) set motherboard in configuration.h "#define MOTHERBOARD BOARD_RAMPS_14_EFB"

NB E axis will not move until hot end is heated... so do not start with testing that.
↧
↧

Machine never raises Z axis to probe while leveling the bed

September 20, 2018, 3:26 am
$
0
0
I have a problem with my recently added inductive probe and Marlin 1.1.9. The probe is connected to the Z min endstop, and works fine for homing. The printer moves in XY to the middle of the bed, raises Z, lowers Z until the probe senses the bed, raises Z again and lowers Z more slowly. So far so good.

I confingured AUTO_BED_LEVELING_BILINEAR, and when I run G29 after homing, the following happens:
The printer lifts Z, moves in XY to the first probing point, lowers Z until the probe senses, but only once. It the moves in XY to the next probe point, but it never lifts Z again. Instead, it quickly drags along in XY to all other probe points, and gives identical numbers for each point.

I tried deliberately skewing the bed, so that it leaves the initial Z height that gets probed on the first point. I notice that when the LED on the sensor goes off, the Z steppers move down a little until the LED is on again, and then the machine continues through the remaining positions without ever moving Z again. The result is that I get two different numbers: one for the first to Y rows, and one for the last two Y rows.
Why does the machine never lifts the Z axis again?

Here's my config: [gist.github.com]
↧

TMC2130 use_tmc_sw_spi driver error

September 20, 2018, 4:02 am
$
0
0
Hi,

I've setup everything with tmc2130 to use with spi mode. I did multiple tests that mosi is on pin 44 and able to confirm that I can't use pin 44 because when there's a wire plugged into that pin, firmware just got into "driver error, please restart" screen. Even if the wire just plugged there not connected to the driver pin.

By default, pin 44 are default to e1 if I'm not mistaken and this may be due to clash between them. I still haven't tried to shift mosi pin to other pins yet as I am quite confused which is which. I also tried moving the sw_mosi from pin 44 to 58, the firmware kept throwing me same error regardless of the wire being plugged or not on both ends.

I am using an arduino ch340 mega 2560 burnt 12v regulator along with bigtreetech's ramps1.6+tmc2130 as well as 2004 lcd panel.

I also put 2 power source, 12v to the ramps, usb to the arduino mega so the mega able to function properly
↧
Search

Re: TMC2130 use_tmc_sw_spi driver error

September 20, 2018, 4:31 am
$
0
0
software SPI... horrible....

yes the default pin presumes you are not using E1 for anything

you can change it to any pin you like.

Why not just use the real physical SPI ports?
↧

Re: TMC2130 use_tmc_sw_spi driver error

September 20, 2018, 5:03 am
$
0
0
Thought that I would able to use the software spi so the whole board wiring and assembly looks cleaner.

Is there any clash if I leave the x and y cs pin to default which is 53 and 49?

I was thinking to move all cs pins to 63, 40, 42, 65 and 66 if there are no clash on aux-2
↧
↧

Desperate

September 20, 2018, 6:16 am
$
0
0
Hi.

I'm new to the forum and 3d printing. I've had my printer a while now, probably about six months (Anycubic Prusa I3 Ultrabase Acrylic). My latest issue has got me completely stumped. My extruder and part cooling fan are coming on when i switch the printer on and stay on. I have no control of them through the slicer S3d or Gcode terminal (M107) for example. I have updated to Marlin 1.1.8, I've also tried 1.1.9 and reinstalled the original Hex file. The problem remains the same.
I've Googled, Youtubed, Facebooked and tried everything to sort this to no avail. Can someone please help.

Jim
↧

Re: Machine never raises Z axis to probe while leveling the bed

September 20, 2018, 6:22 am
$
0
0
After mulling over the code for a bit to find out what exactly it is supposed to do, I stumbled over what went wrong: I had Z_CLEARANCE_BETWEEN_PROBES and Z_CLEARANCE_MULTI_PROBE commented out! Now everything is working as expected.
↧

SD card auto init after boot?

September 20, 2018, 9:44 am
$
0
0
Dear all,

I upgraded from Marlin 1.1.5 to 1.1.9 and so far all is great except that the SD card, provieded an SD card is inserted, does not auto initialize itself when the printer is reset or rebooted. It might be that this is due to some changes in how I had to select the display etc. as I initially had some small trouble finding the right settings (again, everything otherwise works as excepted) but is there a configurationsetting that would bring me back the former behaviour?

TIA,
Markus
↧
Viewing all 12089 articles
Browse latest View live
Search