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

Z- Probing G28 works but G29 gives Probing failed

May 8, 2019, 1:41 pm
$
0
0
Dear Forum,

I am having a pretty weired behavior on my Core- XY type printer.

I use Marlin 2.0 bugfix and an inductive probe.

If I send G28 homing of all axis works like a charm. If I send G29 afterwards, autobed leveling is running without any difficulties. I can see the LED of the probe changing on all 9 spots that are probed, meaning that the build plate has been detected successfully. But after bed leveling I get a "probing failed" message on the display.

Any ideas what's going wrong?

Thanks in advance for your appreciated help.

P.S.: I will post the config as soon as I can access it because it is burried in a computer without network and thumbrive
↧
Search

Re: Marlin 2.0 - Re-Arm_Ramps does not see Inductive sensor

May 8, 2019, 3:11 pm
$
0
0
How are you powering the SN04-N? Many sensors that are specified to run off 6-36V will run OK at 5V supply, but will definitely not run correctly at 3.3V supply. You need to power it from a 5V (or 24V) pin on the board. If you power it from 24V you definitely will need a divider network. Be aware that the Re-ARM adds a 10K pullup resistor to each endstop input so that has to be taken into account in your divider network calculations. It might be a better option to use a Schottky diode instead of a divider network, or do what I did and use an optocoupler.
↧
↧

Set GPIO pin state based on hotend temperature

May 9, 2019, 2:08 am
$
0
0
Hi all. I'm looking for a way to set the state of a GPIO pin based on the hotend temperature (e.g., GPIO set high when above a temperature threshold, and low otherwise). The plan is to use the GPIO as an input to a custom-built fume extraction fan controller. I plan on hijacking an unused pin on my board (Lulzbot Mini with RAMBo and single extruder).

I've been looking through the source code (Marlin 2.0.0.110) and I don't have a good sense where I could insert a GPIO state change. There's a lot going on in there. Initially I was looking at using getActualTemp_celsius().

Could you please help me determine the appropriate place to insert the code? Note: I'm also open to other suggestions than using a GPIO pin. My fan controller can utilize UART, SPI, I2C, etc. Maybe there's something that Marlin is already sending out that I could intercept?

Thanks!
↧

Re: Set GPIO pin state based on hotend temperature

May 9, 2019, 5:55 am
$
0
0
its already there...

take a look in configuration_adv.h

/**
 * Extruder cooling fans
 *
 * Extruder auto fans automatically turn on when their extruders'
 * temperatures go above EXTRUDER_AUTO_FAN_TEMPERATURE.
 *
 * Your board's pins file specifies the recommended pins. Override those here
 * or set to -1 to disable completely.
 *
 * Multiple extruders can be assigned to the same pin in which case
 * the fan will turn on when any selected extruder is above the threshold.
 */
#define E0_AUTO_FAN_PIN -1
#define E1_AUTO_FAN_PIN -1
#define E2_AUTO_FAN_PIN -1
#define E3_AUTO_FAN_PIN -1
#define E4_AUTO_FAN_PIN -1
#define E5_AUTO_FAN_PIN -1
#define CHAMBER_AUTO_FAN_PIN -1
#define EXTRUDER_AUTO_FAN_TEMPERATURE 50
#define EXTRUDER_AUTO_FAN_SPEED 255   // 255 == full speed

set one of these to an unused pin and set a temp and that pin will change state at that temp
↧

Re: Marlin 2.0 - Re-Arm_Ramps does not see Inductive sensor

May 9, 2019, 9:30 am
$
0
0
Hi there,

I came right, I used a optocoupler in the end as you did. Works like a Charm. Thanks a lot for answering my question

Regards
↧
↧

Re: Z- Probing G28 works but G29 gives Probing failed

May 9, 2019, 11:27 am
$
0
0
I did somer more debugging using the debug option. The printer stops the bed leveling and says. SLOW Probe Failed.

any ideas? I have been searching for the problem a couple of nights already and would highly appreciate help.

echo:DEBUG:LEVELING
ok
  current_position=(102.00, 42.00, -0.70) : >>> G29
Machine Type: Core
Probe: FIX_MOUNTED_PROBE
Probe Offset X:5 Y:65 Z:-1.30 (Right-Back & Below Nozzle)
Auto Bed Leveling: LINEAR
 (disabled)

  current_position=(102.00, 42.00, -0.70) : set_probe_deployed
deploy: 1
do_probe_raise(10.00)
>>> do_blocking_move_to(102.00, 42.00, 11.30)
<<< do_blocking_move_to
echo:busy: processing
>>> do_blocking_move_to(102.00, 42.00, 11.30)
<<< do_blocking_move_to
>>> probe_pt(75.00, 75.00, raise, 0, probe_relative)
  current_position=(102.00, 42.00, 11.30) : 
>>> do_blocking_move_to(70.00, 10.00, 11.30)
<<< do_blocking_move_to
  current_position=(70.00, 10.00, 11.30) : set_probe_deployed
deploy: 1
  current_position=(70.00, 10.00, 11.30) : >>> run_z_probe
  current_position=(70.00, 10.00, 11.30) : >>> do_probe_move
>>> do_blocking_move_to(70.00, 10.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
echo:busy: processing
echo:busy: processing
  current_position=(70.00, 10.00, 0.39) : sync_plan_position
  current_position=(70.00, 10.00, 0.39) : <<< do_probe_move
  current_position=(70.00, 10.00, 0.39) : <<< run_z_probe
>>> do_blocking_move_to(70.00, 10.00, 5.39)
<<< do_blocking_move_to
echo:busy: processing
<<< probe_pt
>>> probe_pt(104.00, 75.00, raise, 0, probe_relative)
  current_position=(70.00, 10.00, 5.39) : 
>>> do_blocking_move_to(99.00, 10.00, 5.39)
<<< do_blocking_move_to
  current_position=(99.00, 10.00, 5.39) : set_probe_deployed
deploy: 1
  current_position=(99.00, 10.00, 5.39) : >>> run_z_probe
  current_position=(99.00, 10.00, 5.39) : >>> do_probe_move
>>> do_blocking_move_to(99.00, 10.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
  current_position=(99.00, 10.00, 0.40) : sync_plan_position
  current_position=(99.00, 10.00, 0.40) : <<< do_probe_move
  current_position=(99.00, 10.00, 0.40) : <<< run_z_probe
>>> do_blocking_move_to(99.00, 10.00, 5.40)
<<< do_blocking_move_to
echo:busy: processing
<<< probe_pt
>>> probe_pt(133.00, 75.00, raise, 0, probe_relative)
  current_position=(99.00, 10.00, 5.40) : 
>>> do_blocking_move_to(128.00, 10.00, 5.40)
<<< do_blocking_move_to
  current_position=(128.00, 10.00, 5.40) : set_probe_deployed
deploy: 1
  current_position=(128.00, 10.00, 5.40) : >>> run_z_probe
  current_position=(128.00, 10.00, 5.40) : >>> do_probe_move
>>> do_blocking_move_to(128.00, 10.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
echo:busy: processing
  current_position=(128.00, 10.00, 0.50) : sync_plan_position
  current_position=(128.00, 10.00, 0.50) : <<< do_probe_move
  current_position=(128.00, 10.00, 0.50) : <<< run_z_probe
>>> do_blocking_move_to(128.00, 10.00, 5.50)
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(133.00, 104.00, raise, 0, probe_relative)
  current_position=(128.00, 10.00, 5.50) : 
>>> do_blocking_move_to(128.00, 39.00, 5.50)
<<< do_blocking_move_to
  current_position=(128.00, 39.00, 5.50) : set_probe_deployed
deploy: 1
  current_position=(128.00, 39.00, 5.50) : >>> run_z_probe
  current_position=(128.00, 39.00, 5.50) : >>> do_probe_move
>>> do_blocking_move_to(128.00, 39.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
echo:busy: processing
  current_position=(128.00, 39.00, -0.50) : sync_plan_position
  current_position=(128.00, 39.00, -0.50) : <<< do_probe_move
  current_position=(128.00, 39.00, -0.50) : <<< run_z_probe
>>> do_blocking_move_to(128.00, 39.00, 4.50)
<<< do_blocking_move_to
echo:busy: processing
<<< probe_pt
>>> probe_pt(104.00, 104.00, raise, 0, probe_relative)
  current_position=(128.00, 39.00, 4.50) : 
>>> do_blocking_move_to(99.00, 39.00, 4.50)
<<< do_blocking_move_to
  current_position=(99.00, 39.00, 4.50) : set_probe_deployed
deploy: 1
  current_position=(99.00, 39.00, 4.50) : >>> run_z_probe
  current_position=(99.00, 39.00, 4.50) : >>> do_probe_move
>>> do_blocking_move_to(99.00, 39.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
  current_position=(99.00, 39.00, -0.60) : sync_plan_position
  current_position=(99.00, 39.00, -0.60) : <<< do_probe_move
  current_position=(99.00, 39.00, -0.60) : <<< run_z_probe
>>> do_blocking_move_to(99.00, 39.00, 4.40)
<<< do_blocking_move_to
echo:busy: processing
<<< probe_pt
>>> probe_pt(75.00, 104.00, raise, 0, probe_relative)
  current_position=(99.00, 39.00, 4.40) : 
>>> do_blocking_move_to(70.00, 39.00, 4.40)
<<< do_blocking_move_to
  current_position=(70.00, 39.00, 4.40) : set_probe_deployed
deploy: 1
  current_position=(70.00, 39.00, 4.40) : >>> run_z_probe
  current_position=(70.00, 39.00, 4.40) : >>> do_probe_move
>>> do_blocking_move_to(70.00, 39.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
echo:busy: processing
  current_position=(70.00, 39.00, -0.69) : sync_plan_position
  current_position=(70.00, 39.00, -0.69) : <<< do_probe_move
  current_position=(70.00, 39.00, -0.69) : <<< run_z_probe
>>> do_blocking_move_to(70.00, 39.00, 4.31)
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(75.00, 133.00, raise, 0, probe_relative)
  current_position=(70.00, 39.00, 4.31) : 
>>> do_blocking_move_to(70.00, 68.00, 4.31)
<<< do_blocking_move_to
  current_position=(70.00, 68.00, 4.31) : set_probe_deployed
deploy: 1
  current_position=(70.00, 68.00, 4.31) : >>> run_z_probe
  current_position=(70.00, 68.00, 4.31) : >>> do_probe_move
>>> do_blocking_move_to(70.00, 68.00, -0.70)
<<< do_blocking_move_to
echo:busy: processing
echo:busy: processing
  current_position=(70.00, 68.00, -0.70) : sync_plan_position
  current_position=(70.00, 68.00, -0.70) : <<< do_probe_move
SLOW Probe fail!
  current_position=(70.00, 68.00, -0.70) : <<< run_z_probe
>>> do_blocking_move_to(70.00, 68.00, 4.30)
<<< do_blocking_move_to
  current_position=(70.00, 68.00, 4.30) : set_probe_deployed
deploy: 0
>>> do_blocking_move_to(70.00, 68.00, 4.30)
<<< do_blocking_move_to
Error:Probing failed
<<< probe_pt
  current_position=(70.00, 68.00, 4.30) : set_probe_deployed
deploy: 0
  current_position=(70.00, 68.00, 4.30) : > probing complete
<<< G29
X:70.00 Y:68.00 Z:4.30 E:0.00 Count A:11040 B:160 Z:11008
ok

My config as well as the complete debugging log is attached. [attachment 111244 Configuration.h] [attachment 111245 Configuration_adv.h] [attachment 111246 Fehlermeldung.txt]
↧

Re: Set GPIO pin state based on hotend temperature

May 9, 2019, 10:11 pm
$
0
0
Thanks. I couldn't get it to work that way, so instead I modified a function in temperature.h. Probably not the best location to inject code, but seems to work. Here's the modified function to hijack PH1 on RAMBo:

    FORCE_INLINE static float degHotend(const uint8_t e) {
      E_UNUSED();
      // Custom firmware for fume extraction and lighting system
      if (temp_hotend[HOTEND_INDEX].current >= 35) {
        PORTH |= (1 << 1); // turn on system
      } else {
        PORTH &= ~(1 << 1); // turn off system
      }
      return temp_hotend[HOTEND_INDEX].current;
    }

For some reason the compiler is complaining about "PORTH1" (PH1), so instead I just used the decimal equivalent.
↧

Re: Z- Probing G28 works but G29 gives Probing failed

May 10, 2019, 4:36 am
$
0
0
Hi there,

I get more or less the same error. I had a problem getting my inductive sensor working but it is working fine now, using an optocoupler. The problem is that if I do a g28 everything seems to run well. When I do a G29, my X and Y (alpha and beta) steppers start behaving erratically and it seems it does not know what to do and fails with "probing fails". This started happening last night. I have a re-arm board with a Ramps 1.4 and it is a coreyx machine. I have Marlin 2.0 installed on the re-arm. My config file for Marlin 2.0 did work perfectly on the Arduino Mega

I did not have time to look deeper into my problem yet but will give feedback when I know more.

Can you please give me a short rundown of how to do the leveling debugging, please.
↧
Search

Marlin 2.0.x MINTEMP BED on startup - not printing

May 10, 2019, 9:33 pm
$
0
0
Hello all, I think this is my first post here.

I'm getting a "MINTEMP BED" error as soon as my printer starts up. I'm using a BigTreeTech SKR v1.1 controller board, with the hardware from an Anet A8 printer (stepper motors & bed but a new hotend setup). I've flashed Marlin 2.0.x since this is a 32 bit board, and when I run the original SmoothieWare bin on the board the bed temp is registered just fine.

I can flash Marlin with the dummy sensor, 998, and everything works as it should. As soon as I re-flash with what I thought was the correct sensor, the system halts.

I have tried sensor 5, which is what is in the default Anet A8 configuration.h file and sensor 1 since that appears to be the same as the smoothieware sensor in the config.txt file.

This 'halt' happens whether or not the temp sensor is plugged in to the board. I would think that if there was no reading it would be 999/undef/something.

Short of just trying the different temp sensors for the bed, what else can be done?

Thanks
↧
↧

Re: Z- Probing G28 works but G29 gives Probing failed

May 10, 2019, 10:50 pm
$
0
0
You have to uncomment the respective line in the config, compile and send M111 S32 before sending G29.

Do you maybe have negative values in your step settings? I think your problem is by accident leveling related.

Best,

Louis
↧

Re: Marlin 2.0.x MINTEMP BED on startup - not printing

May 10, 2019, 10:54 pm
↧

Re: Z- Probing G28 works but G29 gives Probing failed

May 11, 2019, 12:16 am
$
0
0
Hi, thanks for the reply, I found out my vref on my A4988 drivers were set too low and therefore behaved erratic. I am up and running again.


Thanks a lot
↧

Re: Set GPIO pin state based on hotend temperature

May 11, 2019, 1:27 am
$
0
0
There is the TEMP_STAT_LEDS built-in option if you wanted.
↧
↧

Why was it named Marlin?

May 11, 2019, 8:09 am
$
0
0
Bit of a random, yet serious, question, but why did the developers choose the name Marlin? Does anyone know? Is there any fish related anecdote?
↧

Re: BLTouch and heater failure

May 11, 2019, 8:17 am
$
0
0
FIXED: I couldn't find a fix for this on Marlin 1.x, but updating to to Marlin 2.0 got rid of the issue.
↧
Search

Re: Z- Probing G28 works but G29 gives Probing failed

May 11, 2019, 12:21 pm
$
0
0
Hi all,

I'm getting the same issue here - I'm on Marlin 1.1.9 and here's my debug log:

G29
Machine Type: Cartesian
Probe: FIX_MOUNTED_PROBE
Probe Offset X:20 Y:0 Z:-2.75 (Right-Center & Below Nozzle)
Auto Bed Leveling: BILINEAR (disabled)

  current_position=(155.00, 25.00, 5.75) : set_probe_deployed
deploy: 1
do_probe_raise(5.00)
>>> do_blocking_move_to(155.00, 25.00, 7.75)
<<< do_blocking_move_to
>>> do_blocking_move_to(155.00, 25.00, 7.75)
<<< do_blocking_move_to
  current_position=(155.00, 25.00, 7.75) : setup_for_endstop_or_probe_move
>>> probe_pt(25.00, 25.00, raise, 0, probe_relative)
  current_position=(155.00, 25.00, 7.75) : 
>>> do_blocking_move_to(5.00, 25.00, 7.75)
echo:busy: processing
<<< do_blocking_move_to
  current_position=(5.00, 25.00, 7.75) : set_probe_deployed
deploy: 1
  current_position=(5.00, 25.00, 7.75) : >>> run_z_probe
  current_position=(5.00, 25.00, 7.75) : >>> do_probe_move
>>> do_blocking_move_to(5.00, 25.00, 0.75)
echo:busy: processing
<<< do_blocking_move_to
  current_position=(5.00, 25.00, 2.06) : sync_plan_position
  current_position=(5.00, 25.00, 2.06) : <<< do_probe_move
  current_position=(5.00, 25.00, 2.06) : <<< run_z_probe
>>> do_blocking_move_to(5.00, 25.00, 7.06)
echo:busy: processing
echo:busy: processing
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(100.00, 25.00, raise, 0, probe_relative)
  current_position=(5.00, 25.00, 7.06) : 
>>> do_blocking_move_to(80.00, 25.00, 7.06)
<<< do_blocking_move_to
  current_position=(80.00, 25.00, 7.06) : set_probe_deployed
deploy: 1
  current_position=(80.00, 25.00, 7.06) : >>> run_z_probe
  current_position=(80.00, 25.00, 7.06) : >>> do_probe_move
>>> do_blocking_move_to(80.00, 25.00, 0.75)
echo:busy: processing
<<< do_blocking_move_to
  current_position=(80.00, 25.00, 1.37) : sync_plan_position
  current_position=(80.00, 25.00, 1.37) : <<< do_probe_move
  current_position=(80.00, 25.00, 1.37) : <<< run_z_probe
>>> do_blocking_move_to(80.00, 25.00, 6.37)
echo:busy: processing
echo:busy: processing
<<< do_blocking_move_to
<<< probe_pt
>>> probe_pt(175.00, 25.00, raise, 0, probe_relative)
  current_position=(80.00, 25.00, 6.37) : 
>>> do_blocking_move_to(155.00, 25.00, 6.37)
<<< do_blocking_move_to
  current_position=(155.00, 25.00, 6.37) : set_probe_deployed
deploy: 1
  current_position=(155.00, 25.00, 6.37) : >>> run_z_probe
  current_position=(155.00, 25.00, 6.37) : >>> do_probe_move
>>> do_blocking_move_to(155.00, 25.00, 0.75)
echo:busy: processing
echo:busy: processing
<<< do_blocking_move_to
  current_position=(155.00, 25.00, 0.75) : sync_plan_position
  current_position=(155.00, 25.00, 0.75) : <<< do_probe_move
SLOW Probe fail!
  current_position=(155.00, 25.00, 0.75) : <<< run_z_probe
>>> do_blocking_move_to(155.00, 25.00, 5.75)
echo:busy: processing
<<< do_blocking_move_to
Error:Probing failed
<<< probe_pt
  current_position=(155.00, 25.00, 5.75) : set_probe_deployed
deploy: 0
>>> do_blocking_move_to(155.00, 25.00, 5.75)
<<< do_blocking_move_to
  current_position=(155.00, 25.00, 5.75) : > probing complete
  current_position=(155.00, 25.00, 5.75) : clean_up_after_endstop_or_probe_move
<<< G29
X:155.00 Y:25.00 Z:5.75 E:0.00 Count X:12400 Y:2000 Z:14720
ok

This is using bilinear levelling.

Cheers

Joe
↧

Marlin 2 STM32F4 Hardware SPI

May 11, 2019, 10:09 pm
$
0
0
Hi,
i have one question.
Can MARLIN 2.x support more then one Hardware SPI for the STM32F4 MCU ?
For Example one for the SD-Card and one for the TMC2130 or one for EEPROM.

Thank's in advance for any help.
↧
↧

MArlin 1.1.9 on Tango Board

May 11, 2019, 11:19 pm
$
0
0
Dears all,

I have a Tango board using the Biqu Marlin 1.1.8
Tring to upgrade the firmware to last version 1.1.9 I have found a problem with the LCD,
Reprap Full graphics smart controller 128x64, the screen is complete corrupted and
buzzer remains switched on with a very noisy sound.
I have tried to compare the initial version from Biqu and last one, without finding out the issue.

Has anyone an idea to solve the matter?

Jek
↧

Re: Why was it named Marlin?

May 12, 2019, 5:33 am
$
0
0
I posted that question on SE and I appreciate greenonline's efforts to help answer it, and to help guide the question to whatever channels won't flag it as off-topic. So thank you for that!
↧

Re: Marlin 2.0.x MINTEMP BED on startup - not printing

May 13, 2019, 11:10 am
$
0
0
How recent is your version of Marlin? There were some very recent fixes to the temperature handling code for 32-bit platforms (specifically applies to the LPC1768 on the SKR) that fix some issues with temperature errors on startup. Try a fresh bugfix-2.0.x checkout and see if you have better luck with those fixes included.
↧
Viewing all 12089 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>