This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Problemas con el homing CORE XY
#1
Hola, llevo unos años imprimiendo. Este es mi primer proyecto de montar una impresora desde 0 con el sistema Core XY. Llevo tiempo buscando, investigando y probando cosas pero no sé que puede ser. :'(

Tengo problemas para aclararme con los ejes y el homing. Digamos que vista desde la parte frontal/superior quiero:
X_min esté en la parte izquierda
Y_min  esté en la parte de abajo
Se que hay  que cambiar el true/false de estas lineas pero no doy con la solución...
#define INVERT_X_DIR _false_
#define INVERT_Y_DIR _true_
#define INVERT_Z_DIR _true_
-----------------------------------------------------------------------------
// Direction of endstops when homing; 1=MAX, -1=MIN
// :[-1,1]
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1
----------------------------------------------------------------------------
// Uncomment one of these options to enable CoreXY, CoreXZ, or CoreYZ kinematics
// either in the usual order or reversed
#define COREXY
//#define COREXZ
//#define COREYZ
//#define COREYX
//#define COREZX
//#define COREZY
--------------------------------------------------------------------------
Dejo el excel
.xlsx   gir motors.xlsx (Tamaño: 47.27 KB / Descargas: 62) que he hecho para verlo más claro, el codigo Marlin y algunas fotos de la impresora para que lo podais entender y ayudar cuando antes. Sonrisa
Toda idea que tengais de que puede ser comentarlo, muchas gracias.


[Imagen: Foto-excel-ejes.jpg]
[Imagen: JuF2vzX.jpg]
[Imagen: Marlin-1.jpg]
[Imagen: Marlin-2.jpg]

Mi maquinita:

Perfileria cubo de 40x40 500mm
Perfileria base 30x30
Guias lineales: Hiwin MGN15H x500mm
Correas GT2 con poleas dentadas de 20T
4 Husillos de paso 2 y 4 crestas/hilos
La idea es que funcione con el BLtouch haciendo varios puntos de calibración en la base
Todo es diseño propio y esta en fase "beta"

[Imagen: IMG-1171.jpg]
[Imagen: IMG-1169.jpg]
[Imagen: IMG-1170.jpg]

Dejo el Marlin por aqui en un .rar


Archivos adjuntos
.rar   Marlin.rar (Tamaño: 69.87 KB / Descargas: 37)
  Responder
#2
Hola, veo que has publicado otro post relacionado con este tema en el subforo General, pero voy a contestarte a los dos aquí, ya que están relacionados.
He contruido mi propia CoreXY y en su día estuve intentando encontrar una forma de sistematizar la configuración de Marlin, para no tener que hacer todas las combinaciones hasta dar con la que consigue el movimiento correcto, aunque lo dejé de lado sin haber dado con una solución.
Da la casualidad que retomé este tema hace unos días, debido a la consulta de un usuario con una CoreXY reconvertida a grabador laser y he llegado a unas conclusiones que habrá que comprobar en la práctica, pues investigar en el código cómo gestiona Marlin la cinemática CoreXY (en cualquiera de sus variantes) no creo que sea algo que se pueda hacer fácilmente.
En principio, yo entiendo que la diferencia entre CoreXY y CoreYX debe de corresponderse con la situación relativa de los ejes: si el eje que se mueve sobre el otro es el Y, entonces se trata de una CoreXY; si es al revés, es una CoreYX.
Otra forma de definirlos, que en principio es equivalente al anterior criterio, sería considerando el movimiento de los ejes en función del de los motores: en CoreXY, sentidos de giro de los motores iguales, producen movimientos del eje Y; sentidos contrarios, movimientos del eje X. Para CoreYX sería lo contrario de lo anterior.
Si la orientación del esquema que pones de tu máquina, es con la parte delantera de la máquina en la parte baja del esquema, se trataría de una CoreYX, pues el eje X sería el horizontal y este se mueve sobre el otro, que sería el Y.
Para configurar este tipo de cinemática en Marlin, una vez definido el tipo de máquina que tenemos (CoreXY o CoreYX), quedan dos apartados por concretar: la lógica de los ejes y la conexión de los motores en la placa (cual va en el conector X y cual en el Y).
He pensado mucho sobre esto último y creo que la solución pasa por averiguar primero la conexión de los motores en la placa: una vez conectados correctamente, la lógica de los ejes en Marlin se deduce de como se mueven.
Para saber la conexión,  solo hay que verificar si los ejes se mueven en la misma dirección (los dos positivos o negativos) o si es distinta, independientemente de que estén los ejes intercambiados o no: si se mueven en distintas direcciones, hay que cambiar los motores de conector en la placa.
Una vez se mueven en el mismo sentido (positivo o negativo), ya solo hay que tocar la lógica: si con la misma lógica en ambos, están intercambiados los ejes, es que tienen que tener lógicas distintas y viceversa.
Con eso, ya solo quedaría probar las dos posibles combinaciones en cada caso, para dar con la que hace que los ejes se muevan correctamente: bien false-false o true-true; bien false-true o true-false.

P.S.: Para subir el Marlin que estás utilizando, solo tienes que incluir en el rar los archivos Configuration.h y Configuration_adv.h o excederás el tamaño máximo que permite el motor del foro para los archivos adjuntos.
También indicarte que el esquema que estás utilizando para la disposición de las poleas/correas no es muy adecuado en las de la parte central: tal y como las tienes, se inducen pares de fuerzas que puede que te den problemas de perpendicularidad de los ejes como no tengas un sistema robusto de guiado en ellos.
  Responder
#3
Hola Simemart, primero de todo muchissimas gracias por tu extensa y rápida respuesta!
Una pena que no acabaras ese proyecto de Core XY... la verdad es que me gustaria verla. Puedes mandarme alguna foto por privado?
No me acaba de quedar muy clara la diferencia entre la cinematica XY y YX. Simplemente son dos mootores y dos direcciones, solo puede haber cuatro combinaciones.
A todo esto de volverme loco con los ejes, direcciones, invertir cables (no los he tocado nunca)... he resuelto el problema.
Resulta que yo en su dia compre unos Módulos de Addon, que en principio mejoran la calidad de las piezas impresas porque filtran la corriente o algo así de los motores pero no estoy nada seguro de su funcionamiento. Nunca los llegue a probar. Estos son:
[Imagen: 2-2-1200x.jpg]

[Imagen: HTB1izx-Ybwa-H3-KVj-SZFjq6-AFWp-Xac-jpg-q50.jpg]

Dejo el link de donde los compré: https://es.aliexpress.com/item/328414738...web201603_
De repente se me paso por la cabeza desconectarlos, es decir; conectar los motores directamente a la placa Geteeech GT2560 Rev A+. Y solucionado, los ejes se mueven en las direcciones correctas tal y como yo quiero. Sonrisa
[Imagen: Sin-t-tulo.jpg]
  Responder
#4
Hola, no he dicho que no acabara el proyecto de CoreXY, solo que había abandonado la busqueda del método para saber como configurarla sin probar todas las posibles configuraciones. La impresora sí la terminé y es la que utilizo actualmente: puedes verla en el post que hice cuando concluí su montaje.
Lo de los TL-Smoothers es historia antigua y hacía tiempo que no lo veía aparecer por el foro. No tienen ningún efecto apreciable a no ser que se tengan drivers DRV8825, que son para los que están indicados debido a un defecto de diseño que tiene este modelo y que genera la denominada "piel de salmón", una especie de ondas en la superfice de las piezas impresas. En todo caso y que yo sepa, no deberían influir en la dirección de los ejes.
La forma en que se mueve ahora tu impresora, además de ser la que tú quieres que sea, es la que sigue el estandar de posicionamiento de ejes que existe para estas máquinas y que adoptan casi la totalidad de los fabricantes de impresoras y de aplicaciones que se utilizan con ellas (programas de diseño, de corte, etc.).
El hecho de que hayas decidido que el frente de la máquina sea ese y que siga el estandar (eje X de izquierda a derecha, eje Y de delante a atrás), es lo que hace que sea una CoreYX. Si te fijas en mi impresora, yo tomo el frente en el que sería tu lateral izquierdo y eso hace que la mía sea una CoreXY.
La cosa no es solo dos motores y dos direcciones, sino también cual es cada uno de los ejes y cómo se conectan los motores en la placa.
  Responder
#5
Estoy revisando los archivos de configuración de Marlin que has adjuntado (veo que tienes DRV8825 por lo que quizá sí necesites los TL-Smoothers) y diría que tienes mal configurados los offsets del sensor BL-Touch: has puesto que está, respecto al centro de la boquilla, a 0 en el eje X y a 20 mm en el eje Y (hacia el lado positivo del eje), cuando por las fotos creo apreciar que están cambiados los ejes: en el que parece estár a 0 sería en Y y en X donde estaría a 20 mm hacia el lado positivo.
Unas cuantas recomendaciones:
- habilita las funcionalidades S Curve (#define S_CURVE_ACCELERATION) y Adaptive Step Smoothing (#define ADAPTIVE_STEP_SMOOTHING), pues hacen que los movimientos sean más suaves y fluidos.
- habilita el uso de la EEPROM (#define EEPROM_SETTINGS), para no tener que compilar y grabar el firmware en la placa cada vez que quieras modificar algún parámetro y que se mantenga esa modificación entre reinicios.
- deshabilita el soporte de arcos (//#define ARC_SUPPORT), ya que no lo utiliza ningún programa de corte y está ocupando memoria flash para nada.
La versión de Marlin 2 que estás utilizando (2.0.6) ya es algo antigua: yo instalaría la última versión bugfix (va por la 2.0.8), aunque necesitarás hacerlo con otro IDE distinto del de Arduino (yo utilizo PlatformIO en Visual Studio Code con Auto Build Marlin).
Y cuando te canses del ruido que hace al imprimir, cambia los DRV8825 por TMC, por lo menos en los ejes XYE. Si no quieres meterte a cablearlos por UART, unos TMC2208 en modo Standalone son más que suficientes para una mejora muy grande, aunque pasen a tener 16 micropasos en lugar de los 32 que tienen los DRV (tendrás que cambiar la configuración de micropasos por milímetro de esos ejes a la mitad).
  Responder
#6
(06-02-2021, 01:57 PM)Simemart escribió: Estoy revisando los archivos de configuración de Marlin que has adjuntado (veo que tienes DRV8825 por lo que quizá sí necesites los TL-Smoothers) y diría que tienes mal configurados los offsets del sensor BL-Touch: has puesto que está, respecto al centro de la boquilla, a 0 en el eje X y a 20 mm en el eje Y (hacia el lado positivo del eje), cuando por las fotos creo apreciar que están cambiados los ejes: en el que parece estár a 0 sería en Y y en X donde estaría a 20 mm hacia el lado positivo.
Unas cuantas recomendaciones:
- habilita las funcionalidades S Curve (#define S_CURVE_ACCELERATION) y Adaptive Step Smoothing (#define ADAPTIVE_STEP_SMOOTHING), pues hacen que los movimientos sean más suaves y fluidos.
- habilita el uso de la EEPROM (#define EEPROM_SETTINGS), para no tener que compilar y grabar el firmware en la placa cada vez que quieras modificar algún parámetro y que se mantenga esa modificación entre reinicios.
- deshabilita el soporte de arcos (//#define ARC_SUPPORT), ya que no lo utiliza ningún programa de corte y está ocupando memoria flash para nada.
La versión de Marlin 2 que estás utilizando (2.0.6) ya es algo antigua: yo instalaría la última versión bugfix (va por la 2.0.8), aunque necesitarás hacerlo con otro IDE distinto del de Arduino (yo utilizo PlatformIO en Visual Studio Code con Auto Build Marlin).
Y cuando te canses del ruido que hace al imprimir, cambia los DRV8825 por TMC, por lo menos en los ejes XYE. Si no quieres meterte a cablearlos por UART, unos TMC2208 en modo Standalone son más que suficientes para una mejora muy grande, aunque pasen a tener 16 micropasos en lugar de los 32 que tienen los DRV (tendrás que cambiar la configuración de micropasos por milímetro de esos ejes a la mitad).
los DRV8825 van fuera jejeje, tengo estos ya preparados para ponerle. 
TMC2209-V1.2
[Imagen: IMG-1174.jpg]

[Imagen: IMG-1175.jpg]

[Imagen: IMG-1176.jpg]

[Imagen: Geeetech-20171205191726.jpg]
Mi duda sobre como ponerlos es: si mi placa es esta y tiene el condensador ese enmedio del driver no puedo ponerlos con los dos pines centrales esos que tiene. ¿debo desoldarlos? ¿Cambio de placa?
Tampoco se exactamente para que son los 2 pines, para modos SPI o WART pero no se que hace Nusenuse

Me estudiare todo lo que me has recomendado y lo aplicare sin duda. Enserio que muchas gracias @Simemart, te veo 100% convenzido de todo y lo que dices.

P.D. Me gusta mucho tu Core XY, sobretodo que la tengas toda diseñada por ti y se ve que imprime muy bien. Enhorabuena! Number_one

Y para que el BLtouch haga mediciones a cada esquina y una en el centro, que función debo activar?
  Responder
#7
Gracias por el comentario, la verdad es que imprime muy bien, aunque tuve que realizar algunos cambios para corregir pequeños defectos del diseño original.
Sobre los TMC2209 que piensas usar, no creo que esos pines te toquen con los condensadores, en todo caso puedes doblarlos con cuidado un poco hacia afuera para que no lo hagan.
Como puedes ver en la tarjetita de pinout que traen, el pin más hacia el exterior es el de Vref (donde se mide este parámetro al regular los drivers) y el más hacia el centro el Diag, que se utiliza para el sensorless (el propio driver detecta el final de carrera, lo que suprime la necesidad de interruptores o sensores).
Si no los piensas conectar en modo UART, tendrás que configurar los micropasos mediante los puentes (solo se usan el MS1 y el MS2, que para 32 micropasos serían puente en MS1 y libre MS2) y regular la Imax con el potenciómetro: creo que esos drivers llevan unas resistencias de senseo de 0,11 Ohms, por lo que la formula sería Imax = 0,71 * Vref.
La utilidad que permite medir en las cuatro esquinas y en el centro de la cama se denomina Level Corners y se activa con la línea #define LEVEL_BED_CORNERS. Bajo ella, tienes varios parámetros a configurar, entre ellos #define LEVEL_CENTER_TOO, si quieres que mida también en el centro o #define LEVEL_CORNERS_USE_PROBE si quieres que se utilice el sensor en lugar de hacerlo de forma manual.
  Responder
#8
Me gustaria conectarlos en modo UART pero no acabo de enteneder como hacerlo, ni si es posible con mi placa Geeetech GT2560, encuentro escasa inforamción al respecto. ¿Tu sabes como?
Entiendo que se conectan en esta posición y efectivamente los pines tocan el condensador.

[Imagen: IMG-1178.jpg]

[Imagen: IMG-1179.jpg]

(#define LEVEL_CORNERS_USE_PROBE) no lo encuentra, supongo que la opción a habilitar es esta que te refieres:

// Force the use of the probe for Z-axis homing
//#define USE_PROBE_FOR_Z_HOMING
  Responder
#9
Sí, los TMC van orientados como los DRV, con los potenciómetros de regulación en la misma dirección.
Como te comenté, solo tienes que doblar con cuidado los pines hacia afuera para que no peguen en el condensador (no te preocupes que no pasa nada por doblarlos un poco).
El parámetro del Level Corners que te indico no es el que pones: ya te dije que la versión que estás usando de Marlin ya es algo antigua y en esa época no se había incorporado la funcionalidad de usar el sensor para el Level Corners, por eso no encuentras el parámetro LEVEL_CORNERS_USE_PROBE: si sigues con ella, tendrás que hacerlo a mano.
Sobre la conexión de los TMC por UART, yo personalmente no le veo tanta relevancia y la mayoría de los usuarios de estos drivers solo los usan por la disminución del ruido de los motores y eso no requiere utilizar esa conexión.
Otras ventajas, como la comodidad de la regulación por software sí son interesantes, pero si la placa no viene preparada para realizar ese tipo de conexión (como es el caso de la GT2560 Rev. A+), no sé si merece la pena ponerse a cablear de forma externa los drivers, pues además hay que modificar bastante el archivo de pins en Marlin.
En todo caso, hacerlo en esa placa es muy difícil, por no decir casi imposible, pues las líneas necesarias para este control, se encuentran todas en el conector LCD y son usadas por la pantalla.

P.S.: Ten en cuenta la configuración de los puentes para definir los micropasos de los TMC y quita el puente de MS3, pues no se utiliza para esta finalidad en estos drivers.
Y no te olvides de regular la intensidad máxima que enviarán a los motores, para lo que necesitarás usar un voltímetro: la regulación optima es la que utiliza la menor intensidad que permita un funcionamiento correcto de los motores, por lo que tendrás que ir probando.
Un valor apropiado para comenzar pueden ser 0,7A que equivalen, según la fórmula que te indiqué, a 1V más o menos, entre Vref y GND.
Mucho cuidado al manipular el potenciómetro de ajuste si utilizas un destornillador conductor y también al realizar las medidas con las puntas del voltímetro, para no hacer contacto con ningún otro punto del driver que no sean los indicados.
Para realizar la regulación, hay que tener conectada la fuente de alimentación a la placa, pues los drivers tienen que tener alimentación en el pin VM.
  Responder
#10
No sé que he tocado pero ahora me da error al compilar y sin querer guarde... No tengo una copia del archivo de cuando funcionava Triste
¿Donde puedo encontrar la ultima versión para Marlin? No he sido capaz de encontrarla. Lo digo para utilizar la función LEVEL_CORNERS_USE_PROBE
Me olvido de la conexión por UART entonces.

He puesto los tmc 2209 en X e Y; he quitado el puente de MS3 y los he calibrado.
  Responder
#11
Hola, la ultima versión siempre es la bugfix-2.0.x, cuyo enlace de descarga se encuentra en la página oficial de descarga de Marlin.
Si pones el error que te está dando al compilar, quizá pueda indicarte donde está el problema.
Yo tengo los TMC también en el extrusor, pues sino este pasa a ser el protagonista del ruido durante las impresiones.
  Responder
#12
(09-02-2021, 12:52 AM)gerard escribió: No sé que he tocado pero ahora me da error al compilar y sin querer guarde... No tengo una copia del archivo de cuando funcionava Triste
¿Donde puedo encontrar la ultima versión para Marlin? No he sido capaz de encontrarla. Lo digo para utilizar la función LEVEL_CORNERS_USE_PROBE
Me olvido de la conexión por UART entonces.

He puesto los tmc 2209 en X e Y; he quitado el puente de MS3 y los he calibrado.

He descubierto el error de compilar pero no se porque es devido;

Options: A4988, A5984, DRV8825, LV8729, L6470, L6474, POWERSTEP01,
*          TB6560, TB6600, TMC2100,
*          TMC2130, TMC2130_STANDALONE, TMC2160, TMC2160_STANDALONE,
*          TMC2208, TMC2208_STANDALONE, TMC2209, TMC2209_STANDALONE,
*          TMC26X,  TMC26X_STANDALONE,  TMC2660, TMC2660_STANDALONE,
*          TMC5130, TMC5130_STANDALONE, TMC5160, TMC5160_STANDALONE
* :['A4988', 'A5984', 'DRV8825', 'LV8729', 'L6470', 'L6474', 'POWERSTEP01', 'TB6560', 'TB6600', 'TMC2100', 'TMC2130', 'TMC2130_STANDALONE', 'TMC2160', 'TMC2160_STANDALONE', 'TMC2208', 'TMC2208_STANDALONE', 'TMC2209', 'TMC2209_STANDALONE', 'TMC26X', 'TMC26X_STANDALONE', 'TMC2660', 'TMC2660_STANDALONE', 'TMC5130', 'TMC5130_STANDALONE', 'TMC5160', 'TMC5160_STANDALONE']
*/
#define X_DRIVER_TYPE  DRV8825 (esta línea devería poner: #define X_DRIVER_TYPE  TMC2209)
#define Y_DRIVER_TYPE  DRV8825 (esta línea devería poner: #define Y_DRIVER_TYPE  TMC2209)
#define Z_DRIVER_TYPE  DRV8825
//#define X2_DRIVER_TYPE A4988
//#define Y2_DRIVER_TYPE A4988
//#define Z2_DRIVER_TYPE A4988
//#define Z3_DRIVER_TYPE A4988
//#define Z4_DRIVER_TYPE A4988
#define E0_DRIVER_TYPE  DRV8825
//#define E1_DRIVER_TYPE A4988
//#define E2_DRIVER_TYPE A4988
//#define E3_DRIVER_TYPE A4988
//#define E4_DRIVER_TYPE A4988
//#define E5_DRIVER_TYPE A4988
//#define E6_DRIVER_TYPE A4988
//#define E7_DRIVER_TYPE A4988

Si lo dejo como TMC2209 me da error al compilar Facepalm

Este es el error que me da: (compilo sin tener la placa conectada por USB, pero supongo que eso no influye.

Arduino:1.8.10 (Windows 10), Tarjeta:"Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

In file included from sketch\src\inc/MarlinConfig.h:41:0,

from sketch\src\MarlinCore.h:24,

from sketch\src\MarlinCore.cpp:31:

sketch\src\inc/SanityCheck.h:2329:4: error: #error "TMC2208 or TMC2209 on X requires X_HARDWARE_SERIAL or X_SERIAL_(RX|TX)_PIN."

#error "TMC2208 or TMC2209 on X requires X_HARDWARE_SERIAL or X_SERIAL_(RX|TX)_PIN."

^

In file included from c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\hal.h:23:0,

from c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\hal.h:26,

from sketch\src\inc/MarlinConfig.h:30,

from sketch\src\MarlinCore.h:24,

from sketch\src\MarlinCore.cpp:31:

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_DDR" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:81:42: note: in definition of macro '_SET_OUTPUT'

#define _SET_OUTPUT(IO) SBI(DIO ## IO ## _DDR, DIO ## IO ## _PIN)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:35: note: in expansion of macro 'SET_OUTPUT'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_PIN" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:81:61: note: in definition of macro '_SET_OUTPUT'

#define _SET_OUTPUT(IO) SBI(DIO ## IO ## _DDR, DIO ## IO ## _PIN)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:35: note: in expansion of macro 'SET_OUTPUT'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

In file included from c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\hal.h:23:0,

from c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\hal.h:26,

from sketch\src\inc/MarlinConfig.h:30,

from sketch\src\MarlinCore.h:24,

from sketch\src\MarlinCore.cpp:31:

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_RPORT" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:76:48: note: in definition of macro '_WRITE'

#define _WRITE(IO,V) do{ if (&(DIO ## IO ## _RPORT) < (uint8_t*)0x100) _WRITE_NC(IO,V); else _WRITE_C(IO,V); }while(0)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_WPORT" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:66:21: note: in definition of macro '_WRITE_NC'

if (V) SBI(DIO ## IO ## _WPORT, DIO ## IO ## _PIN); \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_PIN" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:66:42: note: in definition of macro '_WRITE_NC'

if (V) SBI(DIO ## IO ## _WPORT, DIO ## IO ## _PIN); \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_WPORT" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:67:21: note: in definition of macro '_WRITE_NC'

else CBI(DIO ## IO ## _WPORT, DIO ## IO ## _PIN); \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_PIN" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:67:42: note: in definition of macro '_WRITE_NC'

else CBI(DIO ## IO ## _WPORT, DIO ## IO ## _PIN); \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_WPORT" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:71:30: note: in definition of macro '_WRITE_C'

uint8_t port_bits = DIO ## IO ## _WPORT; /* Get a mask from the current port bits */ \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_RPORT" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:73:10: note: in definition of macro '_WRITE_C'

DIO ## IO ## _RPORT = port_bits & _BV(DIO ## IO ## _PIN); /* Atomically toggle the output port bits */ \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\pins\mega/pins_GT2560_REV_A.h:105:51: error: pasting "/* Must be enabled at startup to keep power flowing*/" and "_PIN" does not give a valid preprocessing token

#define SUICIDE_PIN 54 // Must be enabled at startup to keep power flowing

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:73:48: note: in definition of macro '_WRITE_C'

DIO ## IO ## _RPORT = port_bits & _BV(DIO ## IO ## _PIN); /* Atomically toggle the output port bits */ \

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:96:31: note: in expansion of macro '_WRITE'

#define WRITE(IO,V) _WRITE(IO,V)

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\fastio.h:108:51: note: in expansion of macro 'WRITE'

#define OUT_WRITE(IO,V) do{ SET_OUTPUT(IO); WRITE(IO,V); }while(0)

^

sketch\src\MarlinCore.h:107:27: note: in expansion of macro 'OUT_WRITE'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

sketch\src\MarlinCore.h:107:37: note: in expansion of macro 'SUICIDE_PIN'

inline void suicide() { OUT_WRITE(SUICIDE_PIN, SUICIDE_PIN_INVERTING); }

^

In file included from sketch\src\inc/MarlinConfig.h:33:0,

from sketch\src\MarlinCore.h:24,

from sketch\src\MarlinCore.cpp:31:

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\core\macros.h:185:48: error: pasting "ENA_" and "/* Enable thermal protection for all extruders*/" does not give a valid preprocessing token

#define _ENA_1(O) _ISENA(CAT(_IS,CAT(ENA_, O)))

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\timers.h:100:22: note: in definition of macro '_CAT'

#define _CAT(a,V...) a##V

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\core\macros.h:185:44: note: in expansion of macro 'CAT'

#define _ENA_1(O) _ISENA(CAT(_IS,CAT(ENA_, O)))

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\core\macros.h:193:35: note: in expansion of macro '_ENA_1'

#define TERN_(O,A) _TERN(_ENA_1(O),,A) // OPTION converted to A or '<nul>'

^

sketch\src\module/temperature.h:826:7: note: in expansion of macro 'TERN_'

TERN_(THERMAL_PROTECTION_HOTENDS, static tr_state_machine_t tr_state_machine[HOTENDS]);

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\core\macros.h:185:48: error: pasting "ENA_" and "/* Enable thermal protection for the heated chamber*/" does not give a valid preprocessing token

#define _ENA_1(O) _ISENA(CAT(_IS,CAT(ENA_, O)))

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\hal\avr\timers.h:100:22: note: in definition of macro '_CAT'

#define _CAT(a,V...) a##V

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\core\macros.h:185:44: note: in expansion of macro 'CAT'

#define _ENA_1(O) _ISENA(CAT(_IS,CAT(ENA_, O)))

^

c:\users\gerar\appdata\local\temp\arduino_build_763525\sketch\src\core\macros.h:193:35: note: in expansion of macro '_ENA_1'

#define TERN_(O,A) _TERN(_ENA_1(O),,A) // OPTION converted to A or '<nul>'

^

sketch\src\module/temperature.h:828:7: note: in expansion of macro 'TERN_'

TERN_(THERMAL_PROTECTION_CHAMBER, static tr_state_machine_t tr_state_machine_chamber);

^

In file included from sketch\src\module/stepper/indirection.h:44:0,

from sketch\src\module/stepper.h:47,

from sketch\src\MarlinCore.cpp:53:

sketch\src\module/stepper/trinamic.h:29:24: fatal error: TMCStepper.h: No such file or directory

compilation terminated.

exit status 1
Error compilando para la tarjeta Arduino/Genuino Mega or Mega 2560.

Este informe podría contener más información con
"Mostrar salida detallada durante la compilación"
opción habilitada en Archivo -> Preferencias.
  Responder
#13
El error lo tienes porque estás configurando el tipo de driver para control por UART: si no vas a controlarlos así (como es el caso), tienes que seleccionar TMC2209_STANDALONE, pues es en este modo como van a trabajar.
Si piensas utilizar la última versión de Marlin, ten en cuenta que no podrás compilarla con el IDE de Arduino, como ya te indiqué en una respuesta anterior.
  Responder
#14
Sorprendido 
Eres un genio @Simemart tenais razón con lo de "TMC2209_STANDALONE" ya me deja compilar!
De momento seguire con esta versión de Marlin. ¿Hay otra opción de calibrado que es la de 9 puntos no? A esto me refiero: https://www.youtube.com/watch?v=iwRxw8zz...o-lighting
Y me gustaría que hiciera eso mejor que solo las esquinas. ¿Qué opción és en Marlin?


Archivos adjuntos
.rar   Marlin Core XY.rar (Tamaño: 70.08 KB / Descargas: 20)
  Responder
#15
Como ya he comentado en otras ocasiones, no hay que confundir nivelación de la cama, calibración de la altura inicial de impresión (punto cero del eje Z) y autolevel.
El primero es el que se realiza en las cuatro esquinas y dependiendo de que la cama sea más o menos propensa a perde la nivelación, habrá que hacerlo con más o menos asiduidad. Este ajuste hay que realizarlo de forma manual y lo único que se puede automatizar en estas impresoras, es el posicionamiento del cabezal de impresión en las esquinas.
El segundo es el que se realiza normalmente con la hoja de papel y en el centro de la cama, pues es donde suelen estar colocadas las piezas que se imprimen. También es un ajuste que hay que realizar de forma manual y como en el caso anterior, habrá que realizarlo con mayor o menor frecuencia, de pendiendo de cómo tengamos configurada la máquina (si tenemos un sensor, solo habrá que hacerlo la primera vez al ajustar el Z Probe Offset, por ejemplo).
Por último, el tercero es una funcionalidad pensada para corregir durante la impresión las iregularidades que pueda tener la cama pero, aunque su nombre incita a suponerlo, no para nivelarla en el sentido indicado en el primer punto.
Esta función realiza una medición de la distancia hasta la cama en varios puntos que se configuran al activarla en el firmware y con ello genera una función que da la variación en la altura en cada punto, ajustando durante la impresión la altura del eje Z para que siempre sea constante el grosor de capa en todos los puntos.
Volviendo a tus preguntas, la opción de calibrado de 9 puntos que indicas es el autolevel y para tenerlo tendrás que configurar algún tipo (bilineal es el más utilizado) y si quieres que sea algo útil y cómodo de usar, instalar un sensor para realizar las medidas.
El autolevel se activa seleccionando el tipo de sensor que se va a utilizar (manual, si no se tiene sensor, aunque es bastante pesado realizar las mediciones así) y descomentar la línea correspondiente al tipo: por ejemplo, si es el bilinear sería la línea #define AUTO_BED_LEVELING_BILINEAR.
Otras configuraciones a realizar son los offsets del sensor (si lo tenemos) y e núero de puntos de medición (por defecto, una rejilla de 3x3=9 puntos).
Por lo que he podido apreciar en las fotos que has insertado, tu impresora va atener una cama muy sólida y si colocas una superfice que esté completamente plana, se mantendrá así idefinidamente, con lo que te recomiendo que te olvides del autolevel, pues en esta situación será más un incordio que una ayuda.
Con lo que puede que tengas un problema es con la disposición por parejas, en lados opuestos, de los cuatro husillos que mueven la cama y que su movimiento sea independiente: eso te obligará a revisar cada cierto tiempo el nivel entre los dos lados, pues los motores independientes siempre tienden a desfasarse con el tiempo, incluso estándo conectados al mismo driver.
En este sentido, quizá te interese la posibilidad de automatizar ese nivelado mediante la utilización de dos finales de carrera independientes, uno en cada lado de la cama, aunque esto te obliga a conectar los dos motres de Z en drivers independientes (quizá ya los tengas así).
Respecto a los problemas de movimiento de los ejes XY, en este tipo de cinemática suelen ser debidos a cuestiones mecánicas más que del software, por lo que deberás revisar que las dos correas tengan una tensión similar, que los ejes se deslicen los dos de forma suave y que los dos drivers estén regulados muy parecidos.
  Responder


Posibles temas similares…
Tema Autor Respuestas Vistas Último mensaje
  Tamaño personalizado para CORE XY Manueldr80 1 832 15-01-2019, 07:57 PM
Último mensaje: Manueldr80