tema Re: Solución al problema a los colapsos de SAC en Civil 3D - Foro en Español

Solución al problema a los colapsos de SAC

joantopo — Fri, 16 Mar 2018 23:51:22 GMT

Hola a todos.

Llevo unos cuantos años trabajando con SAC y ahora que empiezo a hacer subensamblajes que tienen bastantes cosas, llegado a un punto, SAC empieza a hacer flashes de pantalla y empieza a advertir que está ya saturado con ese archivo.

Puedes ir añadiendo código, pero cada vez más, saldrá en cada paso el mensaje de "No responde" y tendrás que esperar 2-5 minutos a que vuelva a estar activo SAC.

Incluso yo tengo en el segundo monitor, la ventana de "Monitor de recursos" de Microsoft para ver cuando SAC vuelve a estar activo para continuar.

El consumo de la CPU no llega ni al 20%..........

Total que se hace insufrible trabajar así, aunque puedes ir añadiendo más cosas al archivo PKT, porque no se corrompe, pero vas a perder muchísimas horas con tanto parón.

Incluso me ha pasado una cosa realmente curiosa:

He grabado el archivo PKT y lo he importado a Civil 3D y resulta que al cambiar algún parámetro de entrada, el subensamblaje no respondía (pero con otros parámetros que cambiaba, sí).

Y haciendo lo mismo en SAC con el archivo, cambiando los mismos parámetros, iba perfectamente.

Al cabo de un rato, lo que he hecho, ha sido un "Save as.." y guardar el archivo con otro nombre para el PKT y lo he vuelto a importar.

Eso quiere decir, que cuando se va haciendo guardados sobre el mismo archivo PKT y con esto de los parones "No responde", tal vez se corrompe algo el archivo y lo suyo es hacer un "Save as" para guardarlo en otro archivo.

Y tengo un procedimiento para probar (AVISO QUE ES NIVEL AVANZADO.. ), que creo que resultará exitoso cuando estás haciendo un subensamblaje y ya no puedes seguir añadiéndole más cosas porque se colapsa SAC.

La idea es añadir "Set Mark point" en tu subensamblaje pesado.

Como los mark names se buscan en todo el ensamblaje, ante la duda, he puesto un "Decision" del tipo "Side=Left" de modo que doy un name mark diferente dependiendo de si está al lado izquierdo o derecho.

Estos mark points los pongo en puntos clave y estratégicos, como por ejemplo, la cabeza y pie de talud (o 2 puntos que marquen un peralte o pendiente), etc..

Y luego, ya desde otro subensamblaje (que sería para programar la continuación del primero), le pongo "Get mark points" (también poniendo el Decision para comprobar si está a la izquierda o derecha), y a partir de recrear de nuevo esos puntos (que los pondré como auxiliary points), puede obtener valores de talud, pendientes, cotas (incluso de Enumeration, utilizando la coordenada X del punto, con clave de índice: 0,1,2,3,........)

Así me ahorro de tener que poner algunos parámetros de entrada que ya se pidieron en el primer subensamblaje y a su vez obtengo datos para poder seguir programando en este segundo subensamblaje.

De hecho, usando mark points, evito tener que usar los "parámetros de salida" y pasar datos entre los subensamblajes, porque lo haría internamente mediante la comuniación de set/get mark points.

Re: Solución al problema a los colapsos de SAC

arturopolanco — Sat, 17 Mar 2018 04:43:12 GMT

Hola @joantopo

Has tomado en cuenta estos detalles:

Subassembly Composer freezes when trying to delete a parameter

Very slow Subassembly Composer

Osea guardar y volver a reiniciar normalmente es la única opción cuando la herramienta no responde.

Re: Solución al problema a los colapsos de SAC

joantopo — Sat, 17 Mar 2018 09:41:50 GMT

Hola Arturo.

Sí, eso ya lo sabía de hace mucho tiempo y siempre guardo antes de eliminar un parámetro.

Curiosamente, por lo que he visto, siempre se elimina también el parámetro que hay por encima de él en la lista y luego daría error si ese parámetro está citado en el código. Se soluciona volviendo a añadir ese parámetro.

Pero si lo has guardado antes y cierras, vuelves a abrir, lo soluciona.

Lo de la caída de rendimiento en SAC es otra cosa y tengo comprobado que siempre pasa llegado un punto en que el archivo empieza a ser "grande" (sobre los 40 kb).

No es cosa del pc.

Tim Yarris lo sabe, en Beta Autodesk porque no soy el único que experimenta esto.

Para mí realmente es un incordio porque precisamente gran parte de mi trabajo profesional con civil 3d es justamente hacer subensamblajes personalizados a la medida de cada proyecto.

Me gustaría que por tu parte, les insistieras mucho en esto.

Saludos.

Re: Solución al problema a los colapsos de SAC

arturopolanco — Sat, 17 Mar 2018 11:57:12 GMT

Definitivamente hay un problema con SAC. Es decir, cuando los diagramas de flujos se vuelven muy complejos causan problemas y hay un lag o retraso que hace difícil su manejo. Me imagino que es tratar de simplificar los los procesos en el flowchart por el momento.

Aun así es una situación conocida como indicas. Vi que se hizo un reporte hace unas pocas semanas de parte de Pascal Wesolek y colgó el PKT que estuvo usando. Estoy siguiendo ese reporte para ver la respuesta de Tim.

Re: Solución al problema a los colapsos de SAC

joantopo — Sat, 17 Mar 2018 11:53:13 GMT

Sí, de hecho yo también participé en ese foro y también subí algunos de mis archivos PKT que dan problemas.

Pero vamos... que podría subirle bastantes más archivos porque me pasa con todos al momento que empiezan a tener bastantes cosas.

Re: Solución al problema a los colapsos de SAC

calderg1000 — Sat, 17 Mar 2018 12:59:04 GMT

Estimado @joantopo

Es muy apreciable tus opiniones y experiencias con esta herramienta auxiliar del C3D, nos da muchas luces a los que como en mi caso estamos iniciando en este tema. Debo indicar que a mi también me ha pasado que cuando voy a hacer ediciones de algún archivo *.pkt, aun siendo relativamente simple, me reporta errores al momento de importarlo, por tanto debo eliminar el archivo previamente importado, guardarlo con otro nombre de archivo y también del subensamblaje para volverlo a importar; con esto lo de la perdida de tiempo, es evidente.

En cuanto archivos muy grandes, uno de los principios en programación es que el todo es igual a la suma de muchas partes, tal vez es eso lo que estas aplicando con lo del "Set Mark point", estoy todavía tratando de interpretarlo, agradecería tu aclaración de ser posible en forma gráfica.

Saludos cordiales

Re: Solución al problema a los colapsos de SAC

joantopo — Mon, 19 Mar 2018 02:00:38 GMT

Me he percatado de otra cosa curiosa.

Si resulta que te has dejado de añadir un punto o link y lo quieres poner, obviamente primero tienes que romper los conectores (ramas), para colocarlo y luego conectar con el elemento anterior y posterior.

Pues bien, si haces esto al principio del código, SAC no se cuelga ni cuando eliminas las ramas ni cuando pones los conectores. Obviamente, cuando vuelves a poner el conector que conecta con todo el resto del código, pues se vuelve a saturar.

Pero eso es un indicativo, de en qué parte del código, podría estar el problema y es a partir de ahí que SAC empieza a sufrir. (cuando eliminas una rama y SAC sigue quedándose colgado)-- señal entonces de que el problema viene muchas líneas antes de código.

Si tenéis que poner código y no importa si debe estar al final del código o no, ponerlo al principio de la estructura de código, ganaréis algo de tiempo..

Re: Solución al problema a los colapsos de SAC

joantopo — Mon, 19 Mar 2018 11:18:54 GMT

Otra cosa para apuntarse a la lista, que me ha roto un poco la cabeza aunque he entendido el funcionamiento respecto al uso de "Set" y "Get" marked points.

Si en nuestro subensamblaje tenemos por ejemplo un Enumeration (caso 1,caso 2, caso 3,....) y luego los usamos por condicionales, si después de los condicionales se crean los puntos (ya fuera de los condicionales), es decir, sería el mismo punto para cualquiera de los casos, y luego le asignamos a ese punto, el "Set mark point", resulta que otro subensamblaje que trate de analizar dicho punto con "Get mark point", va a obtener diferentes resultados de la posición del punto según la condición (enumeration) que se eligió en el primer subensamblaje que contenía los Set marked point.

Para solucionar esto en el primer subensamblaje, la clave está en crear el punto antes de poner los Decision que utilizan los enumeration.

El "set mark point", se puede poner al final del código si se quiere, no importa, pero lo que importa es que la posición del punto quede fijada antes de empezar a usar condicionales.

Si por aquellas cosas, no puedes crear el punto antes de los condicionales, porque está a expensas del resultado que ofrezca el condicional, entonces uso los output parameters y le paso como parámetro de salida para que lo tome el segundo subensamblaje.

Voy a ver si pulo más esto, pero en principio no he encontrado otra alternativa para hacerlo funcionar bien.