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).
|
