Hola amigos, a ver si alguno ha tenido el fallo que tengo en Universal Studio Code y es el siguiente:
Cuando instale Marlin ya note que no me dejo poner el nombre mío o el de la impresora y según iba configurándola, me di cuenta también
que en el buscador tampoco me dejaba poner nada, algunas veces una letra nada más, intente buscar a ver si encontraba el fallo, cosa que
no no encontré. Acabe de configurarla y como al compilar fue bien, no le di importancia. Cuando tuve que cambiar la dirección de algún
motor o alguna lógica fue cuando vi que solo me dejaba poner la primera letra, entonces sale un cuadro de dialogo y dice: Detectar automáticamente, si
pinchas en el se quita, pero cuándo intentas escribir otra letra vuelve. A ver si alguien me dice como solucionarlo, gracias.
Hola, probablemente ese comportamiento no sea un fallo, sino una característica habilitada en el editor de VSC, seguramente las sugerencias.
Para comprobarlo, debes ir al menú Archivo>Preferencias>Configuración y poner en el cuadro de búsqueda quick sugestion: te permitirá activar o desactivar las sugerencias al escribir y el tiempo de retardo para que aparezcan.
Hola, e echo lo que me dijistes, busque en archivo<preferencias<configuración y en el cuadro que se abrió puse quick<suggestion. En todos los sitios que
tenia para cambiar fui probando y cada vez que probaba miraba a ver si ya me dejaba escribir pero nada. Borre VSC y todo los rastros que encontré y lo
volví a instalar y sigue sin dejarme escribir, ya no se que hacer, estoy perdido. a ver si puedes ayudarme. Gracias.
Si no son las sugerencias, desconozco cual es el problema: tendrás que dar más información y alguna captura de pantalla donde se vea ese cuadro de diálogo que indicas.
Hola de nuevo, me e roto la cabeza y sigo sin encontrar donde puedo escribir normalmente. Buscando en quick suggestion, un sitio me llevó
al archivo Settings. joson y hay encontré esto que te mando, los he revisado unas cuantas veces, pero no acabo de entender lo que al final
significa, te los mando por si alguno de ellos fuera el culpable.
"platformio-ide.autoOpenPlatformIOIniFile": falso,
"auto-build.defaultEnv.name": "LPC1769",
"workbench.editor.empty.hint": "oculto",
"grunt.autoDetect": "activado",
"jake.autoDetect": "activado",
"makefile.configureOnOpen": verdadero,
"gulp.autoDetect": "activado",
"window.menuBarVisibility": "compacto",
"editor.unicodeHighlight.invisibleCharacters": falso,
"": verdadero,
"auto-build.preservePIO": verdadero,
"git.suggestSmartCommit": falso,
"git.openRepositoryInParentFolders": "nunca",
"workbench.settings.applyToAllProfiles": [ "editor.suggest.snippetsPreventQuickSuggestions",
"editor.fontSize"
],
"terminal.integrated.suggest.quickSuggestions": falso,
"[cpp]": {
"editor.wordBasedSuggestions": "desactivado",
"editor.semanticHighlighting.enabled": verdadero,
"editor.stickyScroll.defaultModel": "foldingProviderModel",
"editor.suggest.insertMode": "reemplazar"
},
"editor.quickSuggestions": {
"comentarios": "activado",
"otro": "desactivado"
},
"files.autoSaveWhenNoErrors": verdadero,
"files.autoSaveWorkspaceFilesOnly": verdadero,
"terminal.integrated.suggest.windowsExecutableExtensions": {},
"[platformio-debug.asm]": {},
"window.closeWhenEmpty": verdadero,
"editor.suggest.snippetsPreventQuickSuggestions": verdadero,
"terminal.integrated.suggest.suggestOnTriggerCharacters": verdadero,
"terminal.integrated.suggest.insertTrailingSpace": verdadero
}
Para configurar las sugerencias al escribir no es necesario ir a los archivos json, al buscar quick suggestions en Archivo>Preferencias>Configuración, se indican los tres apartados donde pueden aparecer las sugerencias de escritura: Otros (Other), Comentarios (Comments) y Cadenas (Strings).
Si estando todos en Off te sigue saliendo, entonces es otra cosa distinta y desconozco cual puede ser: quizá algo relacionado con las nuevas funcionalidades de la IA, si es que la tienes activada.
E revisado donde me dices y en mucho más. E mirado por internet como puedo vaciar UEC para que al instalarlo esté limpio, pero por más que borro todo antes de instalar el marlin ya esta dentro, sigo todos los procesos que encuentro por la red y nada. pero e conseguido mediante copi de otro sitio y paste, conseguir que no tenga fallos, pero donde no tenia problema en:
X_MIN_ENDSTOP_INVERTIR false
Ahora si pongo true me los da, cuando antes no me los daba. yo tengo el fin de carrera en PROBE pero antes del problema de la escritura también lo tenia hay. no sé que hacer.
Hola, no será Z_MIN donde tienes el problema? Porque X_MIN no tiene ninguna relación con el sensor (PROBE).
Si te da error al cambiar la lógica de Z_MIN, probablemente se deba a que tienes configurado el sensor como BL-Touch y este tiene que configurarse siempre en false.
Esto viene a cuento de que estoy poniendo un CR Touch en una placa SKR V1.4 turbo y lo tengo conectada a PROBE Y a SERBOS.
Cuando muevo el eje X de izquierda a derecha va bien pero cuando llega al final de carrera (parte izquierda) no para y de hay de
cambiar la lógica por true.
Vale, entiendo entonces que el problema está en el final de carrera del eje X, pero me confundió que mencionases el PROBE, pues no tiene nada que ver.
La lógica de los finales de carrera depende del tipo de interruptor: para los NC (normalmente cerrados, es decir conectados siempre y desconectados al pulsar), la lógica debe ser false; para los NO (normalmente abiertos, es decir, siempre desconectados y conectados al pulsar), la lógica debe ser true.
Si el final de carrera del eje Y funciona de forma correcta y los ejes X e Y tienen el mismo interruptor de final de carrera, también tienen que tener la misma lógica configurada, así que pon en X_MIN_ENDSTOP_INVERTING lo mismo que tiene Y_MIN_ENDSTOP_INVERTING.
En todo caso, no debería darte error al compilar sea cual sea el valor colocado en X_MIN_ENDSTOP_INVERTING, así que algo de lo que estás haciendo o comentando no está correcto.
Si al ordenar el home se comienza el proceso, pero al llegar al final de carrera no se detiene el movimiento, probablemente el problema sea del hardware: o bien el interruptor o su conexión está mal; o bien está mal el circuito que controla ese final de carrera en la placa.
Para comprobarlo, conecta la impresora por USB y con Pronterface envía el comando M119, que responde con el estado de los finales de carrera: para cada final de carrera indicará open si no está activado y TRIGGERED si lo está.
Con las respuestas del comando M119, se puede determinar dónde se encuentra el problema, si en el interruptor o en la placa.
Los finas de carrera de X e Y son de los que están abiertos asta que no les cierra el extrusor o la cama, al probarlos me dan OPEN los dos.
Z es el que me da TRiGGERED porque es el que está conectado a PROBE. Z_MIN_ENDSTOP_ INVERTING están en FALSE los dos.
Si los interruptores de X e Y son como indicas (del tipo NO), deben configurarse en Marlin como true y, si no se activan al hacer home, es que no funcionan bien.
Para probarlo, primero debes enviar el comando M119 cuando están sin pulsar (que por lo que dices indica open, lo que es correcto) y después pulsados, que debería indicar TRIGGERED.
Cuando lanzo el comando M119, sí X e Y están activados (osea en posición de salida) están en open los dos, si los desplazo un poco, cambian a Triggered
X e Y, lo que indica que están bien, pero si hago homing, en vez de desplazarse en sentido contrario (osea hacia la derecha X e Y hacia adelante) no se mueven y los motores de X e Y empiezan a vibrar y a meter ruido, lo que indica que tienen la lógica cambiada, o por lo menos es lo que a mí me parece. Este es el problema que
no puedo cambiar la lógica.
No se a qué te refieres con "sí X e Y están activados (osea en posición de salida)": los interruptores de final de carrera están pulsados o no lo están y para probarlos debes lanzar el comando M119 cuando no estén pulsados y después mientras los pulsas tú mismo, no es necesario mover los ejes.
Si los motores no se mueven, vibran y meten ruido, el problema no tiene nada que ver con la lógica de los finales de carrera, sino con ellos mismos, probablemente su conexionado: esos síntomas que indicas suelen ser debidos a una fase desconectada, aunque también podría deberse a una regulación inadecuada de los drivers.
Seguimos sin entendernos. Desde hace un año que puse la placa a la impresora , todo ha ido bien incluido los motores que no los e tocado. Cuando mando al moto que se mueva 10 cm del eje X a la derecha este se mueve 10 cm, pero cuando le digo que lo haga en sentido contrario ( osea hacia el fin de carrera) este llega y empieza a vibrar, y el eje Y hace lo mismo, por lo que entiendo que la lógica de los dos fines de carrera está cambiada.
Cuando lanzo un M119 X e Y están en open y Z en Triggered (porque no tiene fin de carrera)
¿Dónde puedo cambiar la lógica de los motores X e Y para que no se me estrellen contra el fin de carrea y estos desconecten?
Yo entiendo perfectamente lo que dices, pero te repito que no tiene sentido: los finales de carrera solo intervienen durante el homing, fuera de ese proceso no hacen absolutamente nada, por lo que difícilmente pueden influir en el movimiento de los ejes (fuera del homing, vuelvo a repetir).
Por tanto, si los ejes se mueven bien en una dirección pero no en la contraria, las únicas causas que se me ocurren es que los motores tengan floja alguna conexión o que haya algo mecánico que lo impida.
La lógica de los finales de carrera solo le dice al firmware, cómo debe considerar los estados del pin al que se conectan: cuando se configura en false, el estado alto (HIGH) del pin, se corresponde con el estado activado del final de carrera y el estado bajo (LOW), con el estado desactivado del final de carrera; cuando se configura en true, justo al contrario.
El firmware solo comprueba esos pines cuando realiza el homing, el resto del tiempo los ignora: en decir, el movimiento de un eje no se para por pulsar un final de carrera, excepto durante el homing.
¿La impresora hace el home? Si lo hace bien, entonces los finales de carrera funcionan correctamente; si no lo hace bien, dependiendo de lo que haga al ordenar el homing, puede haber algún problema con los finales de carrera o que la causa sea el problema de movimiento de los ejes.
Hola de nuevo, sigo rompiéndome la cabeza y no consigo hacer nada. Pero e descubierto que lo mismo que con la pantalla TFT 35 que en Pronterface
cuando hago un M119 no me reconoce el eje X y en su lugar lo cambia por Y, mira lo que sale:
SENDING:M119
Reporting endstop status
y_min: open
y_min: open
z_min: TRIGGERED
>>> M119
SENDING:M119
Reporting endstop status
y_min: TRIGGERED
y_min: TRIGGERED
z_min: TRIGGERED
Esto no sé si será la causa que los motores X e Y no paren al llegar a homing incluso cuando hago homing el carro del eje X empieza a vibrar y no sale de su posición.
E testeado los fines de carrera, los cables y los pulsadores funcionan bien, no encuentro nada por lo cual me haga esto, además no e tocado a nada porque antes funcionaban bien, solo cambie en marlin lo que había que cambiar y en la placa los dos conectores, el probe y el servo y los cables están como tu me dijistes, además
no creo que el CR Touch sea el culpable. Gracias por atenderme asta ahora, pero es que estoy colgado.
Hola, no indicas en qué situación están los interruptores de final de carrera cuando envías los M119, por lo que no puedo decir si esas respuestas son incorrectas.
En todo caso, si tienes configurado el CR Touch, también te debería reportar la respuesta para el z_probe, que no pones ahí.
Como ya he dicho antes, los síntomas que indicas de vibraciones y falta de movimiento al iniciar el homing, no son consistentes con una causa en los finales de carrera.
Cuando los finales no funcionan, lo que suele suceder es que el eje no se detiene al pulsar el interruptor y se estrella contra él; cuando están activados de forma continua, Marlin intenta desactivarlos moviendo el eje hacia el lado contrario y si no lo consigue se interrumpe el proceso con un error de homing.
Por cierto, ¿qué versión de Marlin estás utilizando? Porque precisamente hace unos días instalé en una de mis impresoras la última versión (2.1.2.7) y he tenido que volver a la que tenía porque no detecta el final de carrera del eje Z (sin tocar nada, con la antigua sí funciona y con la nueva no).
Hola de nuevo, como me comentastes que no iba bien el marlin 2.1.2.7 , lo primero que hice fue cambiarlo por el 2.1.2.6, y si el anterior no me detectaba
cuando hacía un M119 el eje X con este sí. Me comentas que como funcionan los fines de carrera, son los normales, los de la ruleta, que cuando los pulsas
se desconectan (osea se corta la corriente) y cuando no se tocan deja pasar la corriente (osea que cuando el carro del eje X no esta en homing están activados)
Cuando hago un M119, estando en homing (osea el carro a la izquierda) el fin de carrera está desactivado para que el carro no siga y golpe
y esto es lo que me da:
X_MIN open
Y_MIN open
Z_MIN Triggered
Cuando separo el carro de homing y la cama esto es lo que me da:
X_MIN triggered
Y_MIN triggered
Z_MIN triggered
Pero sigue X e Y al hacer homing estrellándose con los fines de carrera y metiendo ruido, sobre todo el eje X que es el que primero inicia a moverse.
Los ejes funcionan bien en su dirección cuando los muevo con las flechas. En teoría si al eje X le digo que se mueva con la flecha hacia la derecha
¿Por qué no lo hace al hacer homing? A no ser que en marlin halla al guna linea que se pueda cambiar el sentido de homing que yo desconozca.
Hola, parece ser que la última versión de Marlin tiene algún error en el tema de los finales de carrera.
Debería haberte pedido que adjuntases los archivos de configuración que estás utilizando, para revisar como tenías configurado todo, porque en lo que indicas hay bastantes cosas que pueden ser la causa de tus problemas.
Si tus interruptores de final de carrera están conectados como indicas (de tipo NO), la lógica que se debe colocar en Marlin para X e Y es true y por lo que arroja el comando M119 están en false, por lo que siempre los detecta como activados (olvídate de si pasa o no la corriente, lo que importa es si Marlin dice que están open=sin activar o TRIGGERED=activados).
Para el eje Z, dado que supongo que tendrás conectado en Z-MIN el CR Touch, ambos deben estar en false, tanto el del eje Z como el del PROBE.
Como ya indique en otra respuesta, si Marlin detecta al iniciar el homing que un final de carrera está activado, moverá ese eje en dirección contraria para intentar desactivarlo y si no lo consigue, se parará indicando error de homing: como en tu caso están TRIGGERED sin estar pulsados, eso es lo que debería estar pasando.
Por otra parte, claro que hay un parámetro que indica en qué dirección se debe hacer el homing de un eje, es *_HOME_DIR, donde * representa el eje correspondiente: si el final de carrera esta conectado en el conector MIN, su valor debe ser -1 y si está conectado en el MAX, 1.
En tu caso y suponiendo que el CR-Touch está conectado en Z-MIN (cables blanco y negro), la configuración que deberías poner es la siguiente:
#define USE_XMIN_PLUG
#define USE_YMIN_PLUG
#define USE_ZMIN_PLUG
#define X_MIN_ENDSTOP_INVERTING true
#define Y_MIN_ENDSTOP_INVERTING true
#define Z_MIN_ENDSTOP_INVERTING false
#define Z_MIN_PROBE_ENDSTOP_INVERTING false
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define BLTOUCH
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1
#define Z_SAFE_HOMING
La configuración anterior es solo lo relacionado con los finales de carrera y el homing.
|
