Quantcast
Channel: Repetier-Firmware - Repetier-Forum
Viewing all 1057 articles
Browse latest View live
↧

Status LED

January 3, 2017, 3:19 am
$
0
0
Hi, I have seen on the net some videos showing the LED operation WS2812b with repetier firmware. Having these at home led wondered if they were officially supported by repetier firmware. It would be really nice as you can install them on some professional printers and if you can convert the light colored in white with the M355 command.
Thank you very much for your help and I hope we can get along with a solution.

Lorenzo
↧
Search

X_MAX Problem

January 3, 2017, 12:31 pm
$
0
0

My printer does not move more than 200mm on the x axis. I set X_MAX_LENGTH = 320
↧
↧

TMC2130

January 6, 2017, 5:43 am
$
0
0
Hi

Are there any examples out there on how to program the driver to output a signal when load changes?

I wondered if this could be used so the nozzle itself act as touchprobe
↧

Auto bed leveling issue

January 8, 2017, 6:32 pm
$
0
0
I'm having a issue with the repetier bed leveling. Everything seems to setup up OK but when it's starts a print it starts outon the 1st layer with the nozzle on the bed like it should but when it moves any distance in x axis or y axis it seems like it raises up slowly 2 or 3 mms as if it's over compensating not sure what is going on with that any help would be appreciated I also have tried several different things firmware wise to fix it but no luck
↧

Auto leveling difference between G30 and G32

January 10, 2017, 2:44 am
$
0
0
Hi
I have some issue with repetier v.0.92.9 with autoleveling. I create config with repetier firmware with support of Z-probing (https://www.repetier.com/documentation/repetier-firmware/z-probing/). My 3D printer is Mendle90 and I have probe about 59mm to the left of nozle (Z_X_PROBE_OFFSET=-59 / Y_Z_PROBE_OFFSET=0). When I doing test ther's everything ok. In steps:
G28 X0 Y0 - homing X and Y (in my case HOME of X and Y is in X=210 and Y210 - thers are endstop's X/Y)
G1 X100 Y100 - move the nozlze near the center of the bed
G30 - the xcarrige move of offset and then probe is in the X100/Y100 and when the probe end's the carriage returns to posioon of the nozzle in X100 Y100
And that is correct
Strange situation is when I using autoleveling in start G-code.
G28 X0 Y0
G32 S3 (to the points of nozzle on the bed P1 X70 Y20; P2 X205 Y20; P3 X70 Y180)
This P1-P2 are the points of the nozzle (the probe is in points decrase of X offset X11 Y20; X146 Y20; X11 Y180) and when the probbing ends then the carriage move to directions where the probe was but repetier still show that the nozzle is in the directions of last probe. 
I did the test where all 3 Probe points have the same X/Y=100 and when the probing end the nozzle still move left of offset but repetier show directions X/Y100 - in this case the physical point of nozzle is X41Y100
Why there is a difference between procesing G30 and G32 - G30 works great with offset?
↧
↧

Filament Clogging detection

January 10, 2017, 4:42 am
$
0
0
Is there any provision for filament detection...Please let us know
↧

Interactive retraction distance and its speed during printing

January 12, 2017, 1:10 pm
$
0
0
Dunno if is a stupid request, but one of the must important thing during printing is the amount of retraction and its speed.
it would be great to be able to calibrate the most of being able to change during printing.
The firmware should simply intercept its gcode and then modify it before sending it to the printer, for example:

G1 E-4.6000 F7200

Starting from the value "100%", after the tuning with the pot at "50%" of the original value:

G1 E-2.3000 F7200

And same thing for the retraction speed, for example "50%":

G1 E-2.3000 F3600

Possible?
↧

Z-probe Creating Incorrect Results

January 12, 2017, 5:55 pm
$
0
0
Hey all, 

Been having some very strange results with my z-probe and was wondering if anyone could shed some light on the issue. I was having no luck with G32. Today I'd had enough with fighting G32. I used G33 to create a bump map, the results were of course incorrect so I then redid each point by hand with the paper method. I'm getting very good first layers now, but this isn't really a solution because if I ever change anything I will have to go through this process again. At very least I have some nice data to go over, maybe that will lead to a solution. Thank you to anyone who tries to help.

Printer: DIY Delta (Kossel Mini derivative)
Firmware: Repetier 0.92.9
Board: Arduino Mega + Ramps

I'll link to my EEPROM settings, my config.h, and the results from redoing the distortion map by hand. 



↧
Search

All stepper motors only move one direction

January 13, 2017, 1:30 pm
$
0
0
I'm currently building something similar and I'm have having problems with my 425oz motors only goin one direction. I'm using ramps 1.4 with M542T drivers and repetier 92.9 with arduino 1.8.1. I've tried disabling ends tops and I've wiring the driver a few different ways with no luck. Any help would be great.
↧
↧

Nozzle too close to bed w z probe

January 14, 2017, 9:20 am
$
0
0
I have an inductive sensor and I think I have autolevel working OK. However I've noticed that the nozzle is too close to the bed and over squishing. My current zprobe height is set to 2 in this screenshot but it still seems to close. If I go lower to .7 I get a probing error.

So how can I fine tune the nozzle to bed distance? And what is the proper way to ensure that after changing a value in the eeprom and saving it it's used. Do I just run G29 S2 Everytime?

Screenshot of eeprom @ https://goo.gl/photos/FjvsR3XxDWNnRjzg8

Thank you!
↧

G32 inconsistent with G33

January 15, 2017, 1:11 am
$
0
0
Hi everyone,

I know there are loads of threads about autoleveling issues. But I haven't seen my particular issue yet. 

Printer: Anet A8 (Zonestar type)
Modifications: inductive probe. No Z endstops.
Procedure: 
- Power on
- Home X+Y
- G32
- G33

Symptoms:
After a G32, I would expect that the average bed height + rotation is calibrated. So doing G33 after G32 should result in a bump map that is close to 0 (I know my bed's warp is <0.5mm). However, the bump map generated from G33 has a bias - almost -2mm on each measured point. How can this be? It seems to me the G32 probed measurements are not consistent with G33's measurements.

Second thing which I found strange: once G33 is done, as expected, Z is moving with X and Y. But when I re-home X, it moves the Z axis down a lot. This would be OK seeing as the bump map does have a big offset. But it does it every time I home X. In other words, if I keep homing X, Z will eventually crash into the bed.
Is this a consequence of not having a Z max endstop?

Thanks a lot for the help! :)
↧

Heating automatically stops

January 16, 2017, 2:24 am
$
0
0
I'm using the repetier software. Everything works fine but when i want to heat my extruder or bed it automatically stops after a few seconds. Does anyone know what the problem could be? 

I'm using the ultratronics pro motherboard
↧

Unknown command: M106 & M107

January 17, 2017, 5:31 am
$
0
0
When adjusting the fan speed from Repetier-Host V1,6.2, using the Manual Control tab, the command log reports: 
Unknown Command N169 M106 S255 
and 
Unknown Command N180 M107

It seems the N### is not fixed. 

It does result in my fan not being controlled. The same happens during a print session, when said gcode is send to the printer for a print.

This is on my Da Vinci 1.0A

Repetier Firmware reported on the printer LCD display at startup:
Da Vinchi 1.0
Repetier 0.92Mod 

How can this be resolved?
↧
↧

Error Compiling Message in DEV firmware

January 18, 2017, 8:18 pm
$
0
0
When I try to compile the firmware I get an error message

In the configuration.h file I have set #define HAVE_HEATED_BED 0

But the UI seems to have a heated bed menu even though I marked that I don't have a heated bed.

Is this the reason the firmware won't let me execute any Gcode?

The error message is pasted below...


Arduino: 1.6.4 (Windows 8.1), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)"

In file included from Repetier.h:586:0,
                 from ui.cpp:20:
uimenu.h:1285: error: expected '}' before 'UI_MENU_PREHEAT_BED'
 #define UI_MENU_PREHEAT_SUB {&ui_menu_preheat_hdl UI_MENU_ADDCONDBACK_C UI_MENU_PREHEAT_BED UI_MENU_PREHEAT_EXT0 UI_MENU_PREHEAT_EXT1 UI_MENU_PREHEAT_EXT2 UI_MENU_PREHEAT_EXT3 UI_MENU_PREHEAT_EXT4 UI_MENU_PREHEAT_EXT5}
                                                                         ^
ui.h:526:93: note: in definition of macro 'UI_MENU'
 #define UI_MENU(name,items,itemsCnt) const UIMenuEntry * const name ## _entries[] PROGMEM = items;const UIMenu name PROGMEM = {2,0,itemsCnt,name ## _entries};
                                                                                             ^
uimenu.h:1286:30: note: in expansion of macro 'UI_MENU_PREHEAT_SUB'
 UI_MENU(ui_menu_preheat_sub, UI_MENU_PREHEAT_SUB, UI_MENU_BACKCNT + 1 + HAVE_HEATED_BED + NUM_EXTRUDER)
                              ^
uimenu.h:1285: error: expected ',' or ';' before 'UI_MENU_PREHEAT_BED'
 #define UI_MENU_PREHEAT_SUB {&ui_menu_preheat_hdl UI_MENU_ADDCONDBACK_C UI_MENU_PREHEAT_BED UI_MENU_PREHEAT_EXT0 UI_MENU_PREHEAT_EXT1 UI_MENU_PREHEAT_EXT2 UI_MENU_PREHEAT_EXT3 UI_MENU_PREHEAT_EXT4 UI_MENU_PREHEAT_EXT5}
                                                                         ^
ui.h:526:93: note: in definition of macro 'UI_MENU'
 #define UI_MENU(name,items,itemsCnt) const UIMenuEntry * const name ## _entries[] PROGMEM = items;const UIMenu name PROGMEM = {2,0,itemsCnt,name ## _entries};
                                                                                             ^
uimenu.h:1286:30: note: in expansion of macro 'UI_MENU_PREHEAT_SUB'
 UI_MENU(ui_menu_preheat_sub, UI_MENU_PREHEAT_SUB, UI_MENU_BACKCNT + 1 + HAVE_HEATED_BED + NUM_EXTRUDER)
                              ^
uimenu.h:1285: error: expected declaration before '}' token
 #define UI_MENU_PREHEAT_SUB {&ui_menu_preheat_hdl UI_MENU_ADDCONDBACK_C UI_MENU_PREHEAT_BED UI_MENU_PREHEAT_EXT0 UI_MENU_PREHEAT_EXT1 UI_MENU_PREHEAT_EXT2 UI_MENU_PREHEAT_EXT3 UI_MENU_PREHEAT_EXT4 UI_MENU_PREHEAT_EXT5}
                                                                                                                                                                                                                          ^
ui.h:526:93: note: in definition of macro 'UI_MENU'
 #define UI_MENU(name,items,itemsCnt) const UIMenuEntry * const name ## _entries[] PROGMEM = items;const UIMenu name PROGMEM = {2,0,itemsCnt,name ## _entries};
                                                                                             ^
uimenu.h:1286:30: note: in expansion of macro 'UI_MENU_PREHEAT_SUB'
 UI_MENU(ui_menu_preheat_sub, UI_MENU_PREHEAT_SUB, UI_MENU_BACKCNT + 1 + HAVE_HEATED_BED + NUM_EXTRUDER)
                              ^
expected '}' before 'UI_MENU_PREHEAT_BED'

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

↧

OLED SW_SPI DUE RADDS1.5

January 19, 2017, 3:40 am
$
0
0

Hello Repetier Useres,

i try to implement a SSD1306 OLED SPI Display to my Printer by using the Repetier Firmware an got some issues. I'm use a Arduino DUE + Radds 1.5 interface in my Printer, for the tests only the DUE.

So on Step by Step. To be sure the Display Works fine i Download the last Version of the normal u8glib and try the "Hello World".  Like the guy in the YouTube Video (Search for: DUE OLED U8GLIB    Time: 17sek.) i added the Pin 48 in the Routine. As you can see, allready with the Display Pin configuration from the RADDS board.

If i do so, the Display works.

U8GLIB_SSD1306_128X64 u8g(44, 45,48, 46, 47);   // SW SPI Com: SCK = 13, MOSI = 11, DON'T KNOW, CS = 10, A0 = 9

Display Pins are : VCC, GND, CLK, MOSI, CS, D/C

Why i have to add the Pin.....really don't know but without the Display will be Black


Now i try the same with repetier Firmware. So on i create a brand new Sourcecode via Repetier-Firmware 0.92.x with Configuration Tool and only chose

  •  Arduino DUE based board 
  •  RADDS

Next Step

  • FEATURE_CONTROLLER =1

and in the UIConfig.h 

  • #define UI_DISPLAY_TYPE 5
  • #define U8GLIB_SSD1306_SW_SPI


#define UI_DISPLAY_RW_PIN          -1
#define UI_DISPLAY_D0_PIN          -1      // PINF.5, 92, D_D4
#define UI_DISPLAY_D1_PIN          -1      // PINK.2, 87, D_D5
#define UI_DISPLAY_D2_PIN          -1      // PINL.5, 40, D_D6
#define UI_DISPLAY_D3_PIN          -1      // PINK.4, 85, D_D7
#define UI_DISPLAY_D5_PIN          -1      // PINK.2, 87, D_D5
#define UI_DISPLAY_D6_PIN          -1      // PINL.5, 40, D_D6
#define UI_DISPLAY_D7_PIN          -1      // PINK.4, 85, D_D7

#define UI_DELAYPERCHAR            50

// Special pins for some u8g driven display
#define UI_DISPLAY_CS1 -1
#define UI_DISPLAY_CS2 -1
#define UI_DISPLAY_DI -1
#define UI_DISPLAY_RW_PIN -1

#define UI_DISPLAY_D4_PIN        44    // PINF.5, 92, D_D4  // SCK Pin:  UI_DISPLAY_D4_PIN
#define UI_DISPLAY_ENABLE_PIN    45   // PINK.3, 86, D_E   // Mosi Pin: UI_DISPLAY_ENABLE_PIN
#define UI_DISPLAY_RS_PIN        46   // PINK.1, 88, D_RS  // CD Pin:   UI_DISPLAY_RS_PIN

#define UI_DISPLAY_RESET_PIN 47   


Code will Compile, but the Display don't Show something 

so i have to dig deeper and look in the ui.cpp and see the Funktion

#ifdef U8GLIB_SSD1306_SW_SPI
    u8g_InitSPI(&u8g,&u8g_dev_ssd1306_128x64_sw_spi,  UI_DISPLAY_D4_PIN, UI_DISPLAY_ENABLE_PIN, U8G_PIN_NONE, U8G_PIN_NONE);

why the Funktion hast two "None" Pins ? If i compare with the "Hello World" and use the Variable Value i got:  

repetier:
     u8g_InitSPI(&u8g,&u8g_dev_ssd1306_128x64_sw_spi,  44, 45, NONE, NONE);
Hello World:
     U8GLIB_SSD1306_128X64 u8g(44, 45,48, 46, 47);   


Can please someone help me so make the right definitions to get the Display running?


Thanks a Lot,

Axel






  




↧
Search

Stalling problems

January 19, 2017, 8:13 am
$
0
0

Hi everyone!

I am having stalling issues with my printer. Randomly on complex print (currently http://www.thingiverse.com/thing:2023835) the cache goes down to 0 and the printer stop for about 30 seconds before continuing. I have tried to play with the values below without success. Lowering the print speed and/or segments per second doesn’t seem to help. The stalling occurred when using a SD card or USB.



My setup: Delta / radds / raps128 / dev firmware (same problem with 0.92)

Print speed = 200mm/s

Acceleration = 1000 mm/s2

Jerk = 25

DELTA_SEGMENTS_PER_SECOND_PRINT = 600

DELTA_SEGMENTS_PER_SECOND_MOVE = 600

DELTASEGMENTS_PER_PRINTLINE = 60

STEP_DOUBLER_FREQUENCY = 80000

PRINTLINE_CACHE_SIZE = 92

MOVE_CACHE_LOW = 92

lowTicksPerMove = 250000


Does anyone have the same problem ?

 

Thank you!

 

↧

DEV version Gcode won't execute

January 19, 2017, 2:19 pm
$
0
0
The new DEV compile works without a heated bed but my Gcode doesn't execute.

I've heated the extruder and homed all the axes.. but the Gcode still won't work.

I am using an SD card and printing from my LCD panel. I have 4 extruders but I am only using and heating up one.

I have used the same Gcode files with the previous firmware and it worked.

How can I get the software to execute my Gcode even when I haven't heated the nozzle?
↧
↧

Communicate with RUMBA board via alternate TX/RX connections?

January 20, 2017, 3:16 am
$
0
0
Hello,

I think I may have damaged the on-board USB-to-TTY converter (i.e. the Atmega16u2 chip) on my RUMBA control board. Normally as a workaround I would just use a separate USB-to-TTY converter, connected to a TX0/RX0 pin breakout in order to upload firmware and communicate with the Mega2560 chip.

Unfortunately on this version of the RUMBA board there are no breakout pins for the TX0/RX0 connections, but there are pins accessible for the TX1/RX1 and TX3/RX3 serial connections. Knowing that the bootloader is programmed only to allow firmware uploading from the Arduino IDE via the specific TX0/RX0 connections, I know I won't be able to load new firmware onto the board via USB-to-TTY; rather, I'd have to use an AVR programmer and the ICSP connector. But if I were able to load firmware using an AVR programmer, is there a way I could modify the firmware so that I could use one of the other serial connections besides TX0/RX0 to communicate with the board through Repetier-Host?

I tried modifying some pin assignments in the fastio.h firmware file, as it seemed to be the only place where TXD/RXD pins could be assigned explicitly. Here is the code:


#if defined (__AVR_ATmega1280__) || defined (__AVR_ATmega2560__)
// UART
#define RXD DIO15
#define TXD DIO14

// SPI
#define SCK 52
#define MISO DIO50
#define MOSI DIO51
#define SS 53

I changed the DIO0 and DIO1 assignments to DIO15 and DIO14, respectively, in accordance with the ATmega2560 digital pins that correspond to the RX3 and TX3 serial connections. However, when I compiled and uploaded the firmware via USB to a separate, fully functioning Arduino Mega board for testing, I was unable to connect to the board in Repetier-Host using the external USB-to-TTY adapter connected to digital pins 14 and 15 (TX3 and RX3). The connection was not refused, but it just wouldn't connect fully. 

Upon checking the serial monitor in the Arduino IDE, there was no output. When I connected the TX/RX wires from the USB-to-TTY adapter to the RX0/TX0 pins on the Arduino board, I received the expected output 'wait' repeatedly on new lines. Furthermore, despite the firmware pin assignment change I made, Repetier-Host would only communicate with the board when the USB-to-TTY adapter was wired to the TX0/RX0 pins and not the TX3/RX3 pins on the Arduino board.

So it looks like my firmware change didn't accomplish what I wanted, which again is to be able to communicate with the board using Repetier-Host and the TX3/RX3 serial connection on the board. I suspect the way to accomplish this has little to do with the Repetier firmware and more to do with some modification to an Arduino library that the Repetier firmware uses. Is there a way to do this?

Thanks for your help and advice!
↧

Problem mit Autolevel

January 21, 2017, 7:36 am
$
0
0
moin moin,
habe die 0.92.9 auf einem ANet A8 am laufen.
beim autoleveln tastet er das board richtig ab und erstellt eine matrix.
beim drucken werden die unebenheiten aber leider nur in positive richtung ausgeglichen.
so wandert die düse innerhalb eines layers langsam aber sicher immer höher.
hat da jemand eine gute idee?
danke.

↧

User define thermistor: ADC value instead resistance

January 22, 2017, 3:37 pm
$
0
0
Hi Roland, there's way to insert in the on-line configurator the ADC value read with "M105 X0" command in the "User define thermistor table"?
I've the ability to physically detect the temperature on my nozzle with a precision instrument, and it would therefore be easier for me to be able to enter the temperature reading value and ADC instead of the resistance.
I think i've really wrong temp reading with my RAMPS V1.4 because the Arduino 5V voltage regulator go out only with 4.7V, so I guess this can cause errors in calculation of the temperature.
Bests,

Marco
↧
Viewing all 1057 articles
Browse latest View live
Search