Hola de nuevo, Me cuesta resumir, pero lo voy a intentar:
Estimado
@Luna: Sobre cuanto dura mi simulación, Tiene intención de que transcurra durante una hora. Es por eso por lo que ayer lo comenté
El número doce en parámetro, sólo lo uso para igualar expresiones.
Sin embargo, pienso que no es lo más importante.
Voy a esforzarme al menos sólo en la mención sobre "inestabilidad"
El usuario puede ser el causante, y otras veces puede ser Catia (pero en cualquier caso, Es el usuario el que debe discernir si lo es (o no).
el_juanri escribió: ↑Vie Ago 25, 2023 9:37 am".....sea inestable...veo, en directo una simulación y la veo que gira en sentido de...
No me pasó en el contexto de indicar dirección mientras se edita el joint, sino después de cerrar la sesión de Catia. Y al comprobarla días después
Intentando distinguir Inestabilidad: Experimenté que:
Hay joints que son parecidos, por ejemplo: El Joint Gear y el Joint Cable Joint, ambos son una relación entre otros dos como enseñásteis ambos dos, pero. Son Joints que tiene relacionado un campo llamado (ratio).
1) Me explico: Es verdad que Catia no es un matalobos, sino herramienta:Es similar a la teoria, pero no igual, pues necesita siempre de la intención del usuario.
1.1) Por ejemplo, durante los Gear Joints, pasó que escogí marcar (opposite) en uno. Terminé y cerre sesión, continué otro día, previsualize y KIN habia cambiado el sentido. Supuse que pudo ser por causas que yo no advertí (me llevo varios días, por ejemplo durante repaso de las condiciones de un engrane) y concluí que voy a intentar prevenir. Y es por ello que "aconsejé" que ese campo (ratio) de joint Catia, si es negativo, lo asegure mediante fórmula (dividiendo Z de conductora/Z rueda dirigida), pero para asegurarme que después de cerrar sesión se mantenga, a esa fx la aseguro multiplicandola por (-1); y así se mantenga después de cerrar sesión.
1.2) Otros "estimo" no eran debidos a Catia sino a que en los planos originales algunas circunferencias primitivas no eran tangentes.
No era culpa de CatiaKIN
Caramba, Jobase !! incumplía y es por eso que perdí confianza en según que guiones se me aconsejaban, y eso que el hilo es antiguo
-Por favor, no es critica negativa-aunque yo supiera que eran buenos consejos.!! perdí confianza, honestamente lo digo y con independencia de que el nucleo del guión fuera lógico.
Es cierto y correcto que aconsejárais que se puede conseguir el mismo efecto de engrane con el joint de (circunferencias tangentes, Joint RollCurve) el cual no necesita (ratio), pero lo más relevante y valioso, es que cumple una de las reglas de engrane: Para sus detalles remito a Juan, para que recuerdes donde pueda aquel trabajo que aportaste. Por ejemplo, en ese trabajo (fue muy buena observación) que (en el propio part donde cada diametro primitivo esté, asegurarse que el sentido de la circunferencia sea el pretendido según su conducción).
2 )Hubo otra inestabilidad, pero esta vez a favor -según parece-:
Un día, necesité distinguir en arbol cuales constaints eran propiedad de Joints (y el caso es que borre dos de un Joint tipo Gear, el cual agrupa dos Revolutes, pero no editables después de efectuarlo). El caso a mi favor, curioso, es que KIN consideró que seguía funcionando.
3) Y hubo otra, pero relacionada con ¿Como restaurar la posición cero, en un comando de longitud por ejemplo?
Ocurrió durante un Joint Prismatic -Para movimiento recto- en otro sub-ejercicio de estudio: Y está en el contexto de los límites que ayer tuvísteis a bien detallar, en el cuadro de diálogo (simulación con comando). Limites tras el subcuadro accesible en el boton puntos suspensivos, aledaño (...). -
El suceso fue que: Efectivamente el alcanze del movimiento era el comprendido entre los límites. Pero sucedió durante el contexto de un fallo (mio) quedó latente en el campo de longitud (un valor que no era cero), es decir perdió su cero.
La pesa alcanzo su longitud, pero sobrepaso la posición pretendida en la que debía quedar más baja, después de una hora de simulación.
3.1) Haí, la documentación de Catia, entendí en ella, que podía devolverla mediante el botón (reset). Es cierto, pero:
Como estaba yo muy nervioso, las propias partes del mecanismo, no quedaban en la posición de inicio que yo pretendía.
Honestamente, pienso que no es una inestabilidad, pues la repuse (pero fue por casualidad que acerté) es decir, valoro lo que aportastéis sobre prevenir o bien
3.2) Mediante constraints solo de assembly y que la repongan.
3.3) O previniendo una escena de assembly, que las devuelva a su sitió.
Finalmente aunque el botón (reset) quedo a cero, quiero decir que, la pieza pretendida a mover debe estar antes de pulsar el boton, ella antes, debe estar en el lugar que el usuario pretende que sea cero.
En otras palabras, KIN fue estable. aunque lo pareciera. ¿sabéis?, por eso doy tanto la tabarra,
antes de simular.
Finalmente, mi caso que comparto fue, que esa configuración cero, fue restaurada mediante constraints preventivas de assembly, que me aconsejástéis.
Conclusión sobre Inestabilidad: Honestamente su resumen pienso es: El usuario necesita discernirlo -
aunque sea obvio-
Recuerdo que el sentido del movimiento es según intención del usuario, por eso escribo tanto arriba, previniéndolo mediante relations, que tengan en cuenta el factor, si se pretendiese (-). Por ejemplo: La pesa, durante el sentido en que el tambor trabaja (Clock), la propia pesa, es movimiento recto, pero hacia abajo (aunque sea obvio, necesito (yo) prevenir, que la pesa cae, en sentido negativo).
Lo destaco una y otra vez, , por que una vez hecho el Joint, sus dos joints quedan embebidos dentro de el y no son editables).
Juan, serías tan amable de poner en otro post, el catproduct que aportste en el mensaje nº 69?, por favor?
Este, aunque no sea igual que el clock, me interesa estudiarlo.
...como véis...sigo escribiendo pesado; por favor. Tener paciencia.
@el_juanri Sobre el resto de tu aporte, honestamente necesito tiempo, pero las tengo muy presentes como al resto de compañeros, y las aprecio.
Saludos