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
Vertex K8400 y BlTouch
#1
Buenos dias,

Tengo desde hace unos años una impresora Velleman Vertex K8400 a la cual le he ido añadiendo ciertas mejoras (cama caliente, HotEnd E3D V6, actualizacion firm 1.1.9v). Mi objetivo ahora es ponerle un sensor BLTouch. Hay algunos problemas que no veo claros ya que no hay practicamente nada de info al respecto de este fabricante, lo primero es que la placa que monta es una personalizacion con chip AtMega2560, nada de placas conocidas donde es facil encontrar soporte (VM8400MB).
Esta placa no dispone de ningun conector tipo Z probe ni tampoco un conector destinado a Servo. Mi idea es usar el Z-Stop y buscarme la vida para el resto de pines 5v y PWM, corregirme si voy bien...
El cableado del Bltouch segun el fabricante lleva el siguiente conexionado:
One I/O for control (Orange wire : PWM or Software PWM)
One I/O for Zmin(White wire : endstop / Z-probe)
GND and +5V power

Os mando el conexionado que tengo en mente por si veis algun error:
[Imagen: esquema-conexion-bltouch-k8400.png]

En caso de que el conexionado sea correcto cambiaria el archivo pins_k8400.h
#ifdef NUM_SERVOS
#define SERVO0_PIN 6 //BLTouch orange wire   --> Digital pin 6 PWM  PH3 Pin físico 15
#endif

Por si a alguien le interesa, en el siguiente link se puede ver el esquema del microchip ATMega2560 para ver la configuración de los pines:
https://docs.arduino.cc/hacking/hardware/PinMapping2560

Me podeis decir si estoy en lo correcto?? Me da bastante respeto estos cambios por si da un chispazo...

Un saludo y gracias
  Responder
#2
Hola, en principio parece correcto tu planteamiento pero, para definir el pin del servo 0, debes tener en cuenta algunas cosas.
Para esa placa se utilizan tres archivos de pines: el pins_K8400.h, que incluye el pins_3DRAG.h (esta placa es un clon de la 3DRAG), que a su vez incluye el pins_RAMPS.h y después del include en los dos primeros archivos, se redefinen algunos pines para adaptarlos a ese modelo en concreto.
Por ello, debes colocar la definición del pin del servo 0, después del include del archivo pins_3DRAG.h en el archivo pins_K8400.h, anulando antes la definición previa que se hace en el archivo pins_RAMPS.h, de esta forma:

#if ENABLED(BLTOUCH)
#ifdef SERVO0_PIN
#undef SERVO0_PIN
#endif
#define SERVO0_PIN 6
#endif


En este PDF tienes más información sobre esa placa.
En el esquema que se incluye y que refleja las conexiones que piensas utilizar, veo algún error de pinout respecto al archivo que utiliza Marlin, así que yo lo tomaría con muchas reservas: por ejemplo, en dicho esquema se indica que el HEATER1 utiliza el pin físico 23 (pin digital 10) y el HEATER2 el pin físico 24 (pin digital 11) y en el archivo de pins se asigna el 11 al primero y al segundo el pin 6 (este es el que piensas utilizar para el BL-Touch).
  Responder
#3
Gracias lo primero por la rapida respuesta, 
No había caído en que pudiera estar asignado el pin en el archivo pins_ramps.h, anularé la definición lo primero en el pins_k8400.h
Respecto el enlace que me mandas, ya lo conocía, lo busque para comprobar la capacidad del condensador que hay en Z-Stop, leí en la web de BlTouch que no puede tener un condensador de alta capacidad.

Respecto los pines es un poco lioso y de verdad que agradezco la molestia. Te cuento lo que creo que estoy viendo:
1. Archivo pins_k8400.h   -->  #define HEATER_1_PIN  11    // Define el Hotend 1 al pin digital 11
2. Archivo pins_3drag.h   -->   #define HEATER_2_PIN   6    //  
3. Archivo pins_ramps.h  -->    #define HEATER_0_PIN      RAMPS_D10_PIN
                                             #define RAMPS_D10_PIN    10

Lo que entiendo de las definiciones y el esquema de la placa es que, aunque en el esquema lo llama Ext1 Heater realmente se refiere al HEATER_0_PIN del Marlin  que si estaria direccionado al pin digital 10, y si le pusiera el 2º hotend que se le puede instalar estaría conectado al físico 24, definido al pin 11 en el Marlin ya que es #define HEATER_1_PIN  11.  En el archivo pins_3drag.h define el pin 6 a un posible tercer hotend opción que no es posible por lo que no es ningún problema redefinirlo para el servo. En definitiva, que en el esquema lo llama HEATER 1 cuando en el Marlin es HEATER_0
Esto es lo que yo creo, no se si lo ves como yo?
  Responder
#4
Efectivamente, tienes razón con la definición de los pins de los calentadores, me olvidé de que Marlin los numera desde 0, por lo que no es necesario ningún cambio en ese apartado y el esquema está correcto.
  Responder
#5
Ya he realizado la instalación física y creo que esta todo correcto, y digo "creo" porque una vez hecha la instalación del BlTouch y la actualización del firmware (BugFix 2.1) no soy capaz de hacer homing. Cuando enciendo la maquina el vastago sale y entra dos veces a modo test (creo que esto es correcto), cuando pulso  Autohome se desplaza la cama en sentido contrario al sensor ZMin 1cm aprox, el vastago  hace varios movimientos y se queda en error marcando en la LCD STOPPED.
Contentarte lo primero que el marlin lo descargo de la pagina oficial y lo modifico yo, no es uno modificado por otra web. De hecho la prueba que he hecho es instalar la versión Bugfix 2.1 con las modificaciones para mi maquina sin el BlTouch y funciona la maquina perfectamente, después conectar el Bltouch y modificar el Marlin para que lo reconozca.
El archivo Configuration.h se queda de la siguiente manera:
#define USE_ZMIN_PLUG
#define USE_XMAX_PLUG
#define USE_YMAX_PLUG

#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_MIN_PROBE_ENDSTOP_INVERTING false  // Set to true to invert the logic of the probe.

#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define BLTOUCH

#define Z_SAFE_HOMING
Evidentemente hay mas cambios pero creo que no interfieren.
Cuando ejecuto el M119 para probar el cambio de TRIGERED (pin recogido) a OPEN (pin desplegado) me funciona correctamente, cada vez que ejecuto el comendo cambia de posicion el vastago y tambien Open/Trigered
Adjunto un enlace a un video del error:
https://youtu.be/8L1QyBEqxLo

Me imagino que lo facil es pensar un fallo en el conexionado pero ha quedado como el esquema que hay arriba y creo que estaria bien...
  Responder
#6
Por el video que pones, parece que todo está bien conectado y lo que no va es el movimiento del eje Z para terminar el home de ese eje.
Dado que tienes definidos los finales de carrera de los ejes X e Y como MAX, tendrás con valor 1 los parámetros X_HOME_DIR e Y_HOME_DIR, pero el eje Z está definido como MIN, por lo que su parámetro (Z_HOME_DIR) debe tener valor -1: comprueba que no lo tengas mal configurado.
  Responder
#7
Así es como lo tengo configurado. 
Ten en cuenta que antes de hacer ningún cambio para el Bltouch funcionaba correctamente por lo que esa configuración esta igual.
Pudiera ser que, aunque el esquema de la placa me dice que esta bien el conexionado del BlTouch como Z-Min, los calbes estuvieran cruzados? me refiero a los dos cables que destina el Bltouch a la funcion de sensor de fin de eje Z.
Antes de BlTouch tenia lo siguiente:
#define USE_ZMIN_PLUG
#define USE_XMAX_PLUG
#define USE_YMAX_PLUG
#define Z_MIN_ENDSTOP_INVERTING true// 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 X_HOME_DIR 1
#define Y_HOME_DIR 1
#define Z_HOME_DIR -1

Despues de instalar BlTouch
#define USE_ZMIN_PLUG
#define USE_XMAX_PLUG
#define USE_YMAX_PLUG
#define Z_MIN_ENDSTOP_INVERTING false// Set to true to invert the logic of the endstop. BLTOUCH SIEMPRE EN FALSE
#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 X_HOME_DIR 1
#define Y_HOME_DIR 1
#define Z_HOME_DIR -1
  Responder
#8
Esa configuración está correcta.
El conexionado de los cables del BL-Touch que van al conector del final de carrera del eje Z (blanco y negro), se indica correctamente en el esquema que pusiste en tu primer mensaje y debe respetarse para que funcione bien: qué pines son el - y el S del conector, lo puedes ver en el pdf que puse en mi primera respuesta.
Ten en cuenta que no es raro que fallen estos sensores y para comprobar su funcionamiento, además del comando M119, se puede utilizar el comando de posicionamiento de servos, enviando M280 P0 S120, que realiza un autotest; enviando M280 P0 S160 se resetea el sensor en caso de parpadeo constante de la luz roja (error).
  Responder
#9
Esos comandos funcionan correctamente, los probe al principio desde Pronterface y tambien desde el LCD.
En el video que envié se puede apreciar lo que me mosquea y creo que es la base del problema: cuando pulso Autohome (apenas se aprecia por el brillo LCD) el hotend se va a la posicion de casa de los sensores y luego se mueve al centro de la cama por el Z_Safe_Homing, cuando está en el centro deberia desplegarse el vastago justo antes de moverse la cama, simpre se queda situado en la posicion interna del bltouch que viene a ser la posicion de Trigered y entonces la cama baja, evidentemente si no sale el vastago aparece un error porque la cama se mueve hacia abajo 1cm aprox y mecanicamente no deberia tener ningun obstaculo para salir el vastago pero no lo hace, es como si no se enviara la orden de desplegarlo que seria M280 P0 S10 (en pronterface funciona).
Creo que este es el problema pero no veo la solucion por mucho que revise el Marlin. ¿puede ser que el sensor funcione por comando en Pronterface pero al pulsar home no?
  Responder
#10
Pues es bastante raro que con comandos gcode funcione bien y no lo haga en el homing, en teoría funciona con el mismo código.
Se me ocurren dos posibles causas para este comportamiento:
- Ruido inducido en los cables. Comprueba que no estén entrelazados con los demás que van al hotend.
- Versión de BLTouch. Las 3.x (3.0 o 3.1), puede que necesiten que se configuren algunos parámetros adicionales en Marlin, que se encuentran en su apartado del archivo Configuration_adv.h:
- Voltaje de señal. Por defecto, estas versiones de BLTouch detectan el voltaje lógico de la MCU a la que se conectan (3,3V o 5V) pero, en algunas placas que trabajan a 5V y que incluyen un condensador de mucha capacidad en el circuito de control del final de carrera del eje Z, no se detecta correctamente y hay que forzarlo, definiendo el parámetro #define BLTOUCH_SET_5V_MODE.
- Delay. Por defecto, Marlin pone una pausa de 500 ms para que se reconozca el comando y puede ser necesario variar este valor, mediante el comando BLTOUCH_DELAY: en el canal de Youtube Teaching Tech, se indica un valor de 100 ms para estas versiones, no sé si será apropiado en este caso, pero se puede probar otros valores entre 100 y 500 para ver si se soluciona el problema.
- Modo software. Se activa con el parámetro BLTOUCH_FORCE_SW_MODE y puede ser útil en caso de ruido inducido en los cables.
  Responder
#11
No hubo suerte, he probado a cambiar todos las lineas que comentas y sigue igual.
Respecto el ruido, tenia esperanzas ya que tengo el cable del bltouch esta en la misma manguera que el resto (calentador, termistor, fan...) la prueba que he hecho es conectar un cable mas corto que viene con el sensor en vez del cable largo que tuve que pedir a postas, de esta manera no se puede quedar montado en el hotend pero podria ver si hace bien el proceso, tampoco hubo suerte, hace exactamente lo mismo.
Me quedo sin ideas, he cambiado a un firm anterior (1.1.9) e igual.
Puede ser que este defectuoso aun viendo que los movimientos mecanicos los hace bien? yo veo claro que falla la parte de endstop. Por cierto tambien he probado a cruzar los cables blanco/negro de la parte del conector que tiene la funcion endstop por si acaso estaban mal pero tampoco, el cable blanco se queda en el pin de S y el negro en tierra.
He visto que hay mas mensajes en ingles de gente que les funcionan los test del bltouch pero luego el homing les falla, pero no consigo encontrar ningun mensaje que me oriente...
¿Pudiera ser que me fallase por la parte electronica que lleva mi mainboard para los endstop? tiene un condensador pero es pequeño y en la web del fabricante del bltouch confirman que con condensadores de esta capacidad no supone ningun problema (100nf)
  Responder
#12
Por lo que has indicado en otro mensaje de que las respuestas del comando M119 son correctas y por lo que se ve en el vídeo, yo diría que el problema se encuentra en la parte servo del BLTouch, así que considero que lo más probable sea que esté mal el dispositivo y me temo que para saber si es así o no, necesitarás probarlo en otra placa o cambiarlo por otro.
Si quieres descartar el circuito de control del final de carrera del eje Z como causa del problema, puedes intercambiarlo por el de otro eje simplemente intercambiando la asignación de pines: en este caso, las de X e Y se encuentran en el archivo pins_K8400.h y el de Z en el archivo pins_3DRAG.h.
  Responder
#13
Pensando sobre el problema, se me ocurre otra posible causa: que no tenga suficiente alimentación desde la placa el BLTouch cuando hay otros consumos concurrentes, lo que explicaría que funcione bien al enviar los comandos gcode, pero no lo haga durante el homing.
Como indica @mashirito en su tutorial sobre estos dispositivos, con las RAMPS puede necesitarse alimentación externa en el BLTouch y la placa de ese modelo es básicamente una RAMPS.
  Responder
#14
Mira que me parecia cojonu.... la idea, ayer por la noche seguí haciendo pruebas con el firm y me fije que al hacer el test del vastago la pantalla LCD perdia intensidad y cuando he leido tu mensaje ha cuadrado todo pero....
Esta mañana he conectado los cables del servo (+ -) a una fuente de laboratorio para que le suministre los 5v directamente sin utilizar la mainboard, como puedes ver en el siguiente video tengo el sensor Bltouch fuera conectado a la main con los cables cortos que vienen de serie para evitar las posibles interferencias (excepto los que están en la fuente) y el resultado es el mismo.
https://youtube.com/shorts/UTD5-XrXRAo?feature=share

El video es cuando pulso Autohome, se puede ver que la cama baja 15mm y se queda haciendo los test de meter/sacar vastago, cuando se para da error y en la pantalla LCD aparece STOPPED. Entiendo que al bajar la cama los 15mm se debe sacar el vastago para quedarse fuera, acto seguido la cama sube hasta llegar al pin.


He abierto un ticket en la tienda que compre el sensor por si existe la posibilidad de enviarselo para que lo prueben, 

No tiene mucha logica lo siguiente pero haber que piensas: cuando se sustituye el Z-Min por un Bltouch se tiene que quedar activada la siguiente linea:
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
Esta linea le dice al firm que se utilice el pin del endstop para homing/ABL. Sin embargo cuando se utiliza un conector dedicado a Z-Probe no se usa esa linea pero si se utiliza una que define el pin que se va a utilizar:
#define Z_MIN_PROBE_PIN XX  // siendo XX el numero de pin dedicado al Probe
¿Merece la pena pegarme por este lado? no lo veo claro porque si lo hago el firm entenderia que sigo teniendo un EndStop fisico y a parte el BLTouch...
  Responder
#15
Pues si cuando hace el test la pantalla baja de intensidad, seguramente el BLTouch esté defectuoso, de ahí ese efecto (seguramente por un consumo excesivo en él).
No sé si lo has tenido en cuenta, pero cuando se utilizan dos fuentes separadas, es muy importante unir sus GND para garantizar una referencia de votaje 0 igual en ambas.
Cuando se realiza el home, si se desconoce la posición del eje Z o si esta definido el parámetro Z_HOMING_HEIGHT y Z se encuentra por debajo de esa distancia del punto 0, el eje se posiciona en el valor de ese parámetro antes de comenzar el proceso; si se tiene un sensor para realizar el home del eje Z, este eje subirá la distancia configurada en el parámetro Z_CLEARANCE_DEPLOY_PROBE de forma que se asegure una distancia suficiente para desplegar el sensor (si la necesita).
Por todo ello, el proceso una vez se ordena el home normalmente es como sigue: la cama baja (o sube el cabezal de impresión), se realiza el home de los ejes X e Y, se mueve el cabezal al centro de la cama, se despliega el sensor, la cama asciende (o baja el cabezal) hasta activarlo (una o varias veces, según la configuración).
El parámetro Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN no le indica a Marlin que el sensor se usará para detectar el final de carrera del eje Z, sino a qué pin está conectada la línea de retorno de señal del sensor (en este caso al pin Z-min), que es por donde este le informa que se ha activado.
Para que Marlin sepa que tiene que utilizar el sensor para el homing, hay que definir el parámetro USE_PROBE_FOR_Z_HOMING, cosa que Marlin hace de forma automática cuando se define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN.
Si definimos otro pin para la línea de señal del sensor, Marlin considerará que tenemos otro dispositivo para hacer el home del eje Z (conectado en Z-min), si no definimos el parámetro que le indica que utilice el sensor para ello.
En todo caso, tener el BLTouch conectado en Z-min o en un pin distinto, no es muy probable que solucione el problema.
  Responder
#16
Desconocía los de tener la misma GND para las dos, entiendo que seria utilizando la GND de la impresora también en la fuente...

He pedido otro BLTouch para probarlo (no lo veo claro), y también he aprovechado a enviar un correo a la propia web de AntClacbs enviandole el esquema electrico que lleva el Z-Min en mi placa por si ellos ven necesario quitar el condensador, en su propia web dice que no es necesario al ser de poca capacidad pero a lo mejor ven algo que yo no.
También he probado a cambiar el sensor a Mode 5V Logic que se hace por comandos desde pronterface pero sigue haciendo lo mismo, pensaba que con ponerlo en el firm ya estaba pero no, hay que enviar los comandos que ponen en su web.

Espero a recibir el nuevo para probar
  Responder
#17
Simplemente es poner un cable que una los GND de las dos fuentes, la de la impresora y la externa.
Sobre lo que indicas del 5V Mode, cuando se inicializa Marlin comprueba el modo seleccionado y si es necesario lo cambia, por supuesto utilizando los comandos que indica AntcLabs, por lo que no debería ser necesario hacer nada más por nuestra parte.
Por cierto, ¿de qué versión es el que tienes?
  Responder
#18
3.1.
Si no me equivoco mañana recibo otro de la misma versión, cruzare los dedos para que sea fallo del sensor porque no lo veo claro. En caso de que siga fallando hare pruebas utilizando el conector X-min (en mi Marlin X-Max) para descartar problema en la parte eléctrica del eje Z aunque me extrañaría. También tengo pensado quitar el condensador aunque digan que de esa capacidad no afecta, no me supone especial problema quitarlo y volver a ponerlo si no soluciona nada:
https://www.antclabs.com/wiring3-1

He mirado otros esquemas de placas (ramps 1.4 por ejemplo) y me da la sensación que la electrónica de los sensores en la placa es mucho mas básica hasta el punto que aparentemente no hay nada, por ejemplo no veo ningun transistor en el esquema o no lo entiendo:
null[Imagen: ramps-1-4.jpg]

Esto me daría que pensar que no se pudiera conectar un sensor bltouch en mi placa por incompatibilidad. Como te decía, he enviado un correo a las propia web del fabricante del sensor con el esquema de mi circuito por si me pueden confirmar que se pueda, o no. Si llego a este caso miraría incluso hacer mi propio pequeño circuito para conectarlo a un pin libre del ATMega 2560 con todo el lio que significa pero me he encabezonado que mi impresora acaba teniendo un sensor BlTouch
  Responder
#19
Las placas RAMPS no llevan ninguna circuitería en los conectores de final de carrera, de ahí que no aparezca nada en el esquema, pero eso no quiere decir que esos componentes que llevan casi todas las demás placas, incluso basadas en ellas, no sean realmente necesarios, simplemente se debe a que dicha circuitería se cuenta con que estará en los propios interruptores de final de carrera: busca por Makerbot endstops (se diseñaron para las RAMPS) y verás que llevan la misma circuitería que tu placa.
Si no se colocan, casi con toda probabilidad se tendrán problemas con el ruido y los microrebotes de los interruptores, claro que si se piensa utilizar siempre un sensor, es posible que esos componentes no sean necesarios ni convenientes.
En todo caso, no es necesario que retires ningún condensador, simplemente utiliza cualquier otro pin de la placa que esté libre, sirve cualquiera.
La versión 3.1 del BLTouch es de la que más problemas he visto en los post para conseguir hacerlo funcionar de forma correcta y me temo que hay una gran probabilidad de que la nueva unidad que vas a recibir se comporte igual que la que tienes ahora, por lo que creo que tendrás que encontrar la solución por otra vía.
  Responder
#20
He probado el nuevo bltouch y lo mismo, sigue sin funcionar, tampoco me sorprende. Se me ocurre conectarlo a algún pin libre, ¿es posible conectar directamente el pin del bltouch que gestiona la señal del endstop a un pin libre del AtMega 2560? Más o menos como he hecho con el servo.
Con esto quitaría la parte de electrónica que pudiera estar dando problemas.
  Responder


Posibles temas similares…
Tema Autor Respuestas Vistas Último mensaje
  Problema calibrado BLTouch DJuan 6 4,763 11-04-2020, 09:41 AM
Último mensaje: carlos_mahiques