TFG Borja Jesus Fernandez Lopez

Desarrollo de software para la
generación automática de
elementos mecánicos en
Borja Fernández López

Solid Edge.
Junio 2018
TRABAJO FIN DE GRADO PARA Borja Fernández López

LA OBTENCIÓN DEL TÍTULO DE
GRADUADO EN INGENIERÍA EN DIRECTOR DEL TRABAJO FIN DE GRADO:
TECNOLOGÍAS INDUSTRIALES Enrique Chacón Tanarro
Software para la generación automática de elementos mecánicos en 3D
RESUMEN
Con motivo del constante incremento de demanda que actualmente está presente en las
distintas ramas de la ingeniería, surge la necesidad de ofertar herramientas de diseño rápi-
das, útiles y cada día más capaces de facilitar los distintos aspectos de diseño ingenieril.
Este hecho es especialmente importante en los campos de la ingeniería mecánica y el dise-
ño de máquinas y sus componentes, siendo las áreas de trabajo en torno a los cuales este
proyecto se fundamenta. En gran medida una buena parte del tiempo de diseño se centra en
la repetición de trabajo ya realizado previamente, como sería el caso del diseño de ejes mo-
trices y engranajes y su posterior representación en un medio de diseño por ordenador. De
manera conjunta, todo desarrollo técnico conlleva igualmente una mejora del marco didácti-
co, capaz de suplir las necesidades de aprendizaje y de aportar herramientas que faciliten la
inclusión de nuevos profesionales en estos campos.
La forma de resolver dicha disyuntiva por parte del departamento de Ingeniería de Maquinas
(ETSII, UPM) fue el desarrollo de un software interactivo, centrado en el diseño y cálculo de
elementos mecánicos. Este software se llama EDIMPO y es actualmente utilizado como
medio de aprendizaje por los alumnos de las asignaturas de Diseño de máquinas I y II. La
introducción de un programa como EDIMPO aporta al alumno de una herramienta para la
verificación y diseño de árboles transmisores de velocidad, engranajes y todos los elemen-
tos secundarios asociados. EDIMPO es un software en constante actualización que plantea
como objetivo final, la constitución de una herramienta comparable a software de diseño
comercial y propietario de una estructura centrada en el aprendizaje de quien la usa.
Es esta conjunción de realidades la que motiva el desarrollo de este proyecto, cuyo fin es la
creación de un módulo capaz de generar de forma automática modelados 3D de elementos
mecánicos básicos y su posterior utilización como herramienta interactiva de aprendizaje en
EDIMPO. Esta funcionalidad no se encuentra incluida en ninguna versión anterior de EDIM-
PO y es materia exclusiva de este proyecto. El módulo planteado gestionará en junto con un
módulo de diseño de Elementos Finitos y una estructura completamente renovada de
EDIMPO, el proceso de aprendizaje del alumno.
Con este software se busca facilitar el proceso de diseño de reductores de velocidad, pro-
porcionando al usuario la oportunidad de agilizar su trabajo y de establecer un entorno de
aprendizaje que permita la rápida comprobación de los diseños realizados y afianzar de una
manera más consolidada los conceptos expuestos en las asignaturas de Diseño de máqui-
nas.
Para lograr esta meta se proporciona una herramienta basada en el lenguaje Visual Basic
de Microsoft, que en conjunción a un programa mayor actúa sobre el entorno de modelado
3D Solid Edge de Siemens y genera aquel conjunto de árboles engranados que el usuario
demande.
El alumno dispondrá de una herramienta capaz de generar rápidamente los modelos bases
de una reductora y de proporcionar de un medio para la comprobación de los diseños, con-
siderablemente más intuitiva y sencilla.
La elaboración del módulo planteado, ha basado su desarrollo en un proceso de construc-
ción y comprobación iterativa de los modelos generados. Al ser Solid Edge un programa
complejo, las particularidades de cada operación han de ser comprobadas con cada nueva
iteración, garantizando que los pasos tomados fuesen exitosos y no revirtiesen el progreso
conseguido. Toda interacción establecida entre Solid Edge y el programa EDIMPO ha nece-
sitado igualmente del diseño de protocolos de intercambio de datos completamente nuevos.
Borja Fernández López 1

RESUMEN, PALABRAS CLAVE, CODIGO UNESCO
Para la generación de los modelos, se ha hecho uso de una estructura de gestión de datos,
de elaboración propia, capaz de coordinar varios programas simultáneamente y cuya arqui-
tectura resulta modular y extrapolable a la realidad. El proceso de construcción de la misma
se ha basado en el uso extensivo de las funcionalidades aportadas por Visual Studio.
Es importante recalcar que la mera inclusión de dichas funcionalidades aun siendo objeto de
apoyo didáctico al alumno, no constituyen una herramienta ideal para el proceso de aprendi-
zaje del mismo. Es por ese motivo por el cual, se ha añadido la capacidad de generar un
informe PDF automático con resultados obtenidos y parámetros utilizados. De esta forma se
garantiza la existencia de un medio para la fácil comprobación del trabajo realizado.
Los resultados mencionados pueden ser observados en la ilustración presentes a continua-
ción:
Ilustración 2: Eje de transmisión.
Ilustración 1: Rueda Engranada.
Como parte final del proyecto se sitúa la correcta incorporación del módulo desarrollado al
programa EDIMPO y su posterior validación, como herramienta a ser utilizada en las asigna-
turas de Diseño de máquinas I y II.
CODIGO UNESCO
331002, 331309, 331315, 330323, 120309, 120310, 120326.
2 Escuela Técnica Superior de Ingenieros Industriales (UPM)

AGRADECIMIENTO
Este documento va dedicado a todas aquellas personas que han hecho posible que este
proyecto haya sido posible:
Enrique Chacón, por la dedicación y el aguante inhumano que le tiene que haber supuesto
leer las primeras versiones de este escrito y por el apoyo a lo largo de todo un año de traba-
jo. Muchas gracias.
Javier Echevarrí, por las ayudas académicas y por las clases tan interesantes que han des-
pertado en mí el interés por el diseño de máquinas.
Adrián y a Raúl Nnang por el sufrimiento compartido y la experiencia única que ha sido tra-
bajar con vosotros. Compañeros de batalla, de risas y sobretodo lágrimas, muchas lágrimas.
Alvaro, por las incontables horas de trabajo necesarias para llevar a cabo este proyecto y el
apoyo técnico y humano que ello ha supuesto. Esa botella de champán gigante más vale
que este el día de la presentación.

INDICE
TABLA DE CONTENIDO
1. GLOSARIO ..................................................................................................................... 6
2. INTRODUCCIÓN ............................................................................................................ 8
2.1. Motivación Académica ......................................................................................... 11
2.2. Motivación Personal ............................................................................................ 12
3. OBJETIVOS.................................................................................................................. 13
3.1. Planificación temporal ............................................................................................. 14
3.2. Presupuesto ............................................................................................................. 15
4. METODOLOGÍA ........................................................................................................... 16
4.1. Proceso de recogida de datos e Investigación previa ....................................... 17
4.2. Recursos necesarios ........................................................................................... 18
4.2.1. Microsoft Visual Basic .Net 2017.................................................................. 18
4.2.2. Solid Edge ST9/ST10 ..................................................................................... 20
4.2.3. Microsoft Office Excel ................................................................................... 21
4.2.4. Mathworks Matlab ......................................................................................... 21
4.2.5. Spy for Solid Edge ........................................................................................ 22
4.2.6. PDF Sharp...................................................................................................... 23
4.3. Esquemática de la utilización de recursos ......................................................... 24
4.3.1. Interacción con Solid Edge .......................................................................... 24
4.3.2. Interacción con Microsoft Excel................................................................... 27
4.3.3. Interacción con Matlab ................................................................................. 28
4.4. Nociones previas ................................................................................................. 30
4.4.1. Gestión de datos ........................................................................................... 30
4.4.2. Tecnología VB.NET ....................................................................................... 43
4.4.3. Secuencia de trabajo con Solid Edge. ......................................................... 46
4.4.4. Principios del modelado de ejes motrices .................................................. 52
4.4.5. Principios de Modelado de engranajes ....................................................... 54
4.4.6. Creación informe PDF: ................................................................................. 62

5. IMPLEMENTACIÓN ...................................................................................................... 65
5.1. Funciones de interacción con Solid Edge. ......................................................... 65
5.2. Funciones de interacción con archivos.............................................................. 67
5.3. Creación de ejes de transmisión ......................................................................... 72
5.4. Creación de Ruedas engranadas ........................................................................ 76
5.5. Función de interacción con objetos COM .......................................................... 78
5.6. Función Main ........................................................................................................ 78
5.7. Release ................................................................................................................. 79
5.8. Algoritmos descartados. ..................................................................................... 80
6. RESULTADOS ............................................................................................................. 83
7. CONCLUSIONES Y LINEAS FUTURAS ...................................................................... 89
7.1. Conclusiones........................................................................................................ 89
7.1.1. Didáctica ........................................................................................................ 89
7.1.2. Optimización ................................................................................................. 90
7.1.3. Solid Edge como plataforma ........................................................................ 90
7.1.4. Seguimiento de objetivos ............................................................................. 90
7.2. Líneas Futuras...................................................................................................... 91
8. ANEXOS ....................................................................................................................... 92
9. TABLA DE ILUSTRACIONES ...................................................................................... 93
10. REFERENCIAS BIBLIOGRÁFICAS .......................................................................... 95

GLOSARIO
1. GLOSARIO
API
Application Programming Interface, término utilizado para designar a un conjunto de
bibliotecas de funciones, datos, clases o demás tipos de elementos informáticos listos para
ser utilizados por otro software, constituye una unidad funcional por si misma .....................17
VB.NET
Visual Basic. Net. Tecnología propia de Microsoft para el desarrollo de aplicaciones. Sus
principales fuertes son el procesamiento simultáneo de varios lenguajes de programación
distintos y la programación por objetos.................................................................................17
DIM
Departamento de Ingeniería de Maquinas, ETSII UPM ........................................................17
Macros
Serie de instrucciones que se almacenan para que puedan ser ejecutadas de forma
secuencial mediante una sola llamada u orden de ejecución. .................................................. 17
Interfaz gráfica
Programa o entorno gráfico encargado de gestionar la actuación de un usuario mediante
menús, imágenes, desplegables y demás elementos visuales .............................................18
Formularios
Un formulario es un documento o tipo de archivo, diseñado para que el usuario introduzca
datos estructurados en campos prestablecidos o defina algoritmos de ejecución, para ser
posteriormente almacenados y procesados .........................................................................18
CAD
Computer Aided Design. Término utilizado para designar todo programa de diseño por
ordenador .............................................................................................................................20
Programación por objetos
Estilo de programación basado en la agrupación de conjuntos complejos de información en
unidades manejables, jerarquizables y heredables entre sí. Permite el establecimiento de
estructuras de datos extrapolables a la realidad ...................................................................24
Almacenamiento por referencia
Tipo de interacción entre datos que permite la modificación de valores y propiedades de un
dato cualquiera, actuando directamente sobre su posición en memoria ...............................27
Clase
Modelo o plantilla utilizada para la definición de propiedades, funcionalidades y reglas de
interacción generales que sigue un tipo de dato ...................................................................34
Namespace
Medio informático utilizado para la organización por etiquetas de clases según un orden
jerárquico .............................................................................................................................43
Keypoint
Tipo de dato/restricción interna de Solid Edge que permite la conexión de elementos de
dibujo y su administración como un único conjunto ..............................................................49

INTRODUCCIÓN
2. INTRODUCCIÓN
Actualmente el mundo educativo hace cada día un mayor hincapié en la necesidad de

combinar una enseñanza con fuertes fundamentos teóricos y las nuevas tecnologías. El
objetivo es el de fomentar el aprendizaje del alumno y aportar al mismo de herramientas
altamente visuales para la tarea docente. Al mantener un enfoque exclusivamente teórico,
se elimina uno de los pilares principales del aprendizaje, la interacción entre el alumno y la
materia que se pretende aprender. Es con la introducción de software de este tipo que esta
realidad, problema crónico en la enseñanza, puede ser atajada.
Cuando un alumno encuentra un problema que ha de resolver y dispone de una herramienta
que dinámicamente le ofrezca consejos e información en lo relativo al problema, un incentivo
es introducido hacia la exploración de nuevos conceptos y soluciones alternativas a las
ofertadas en un ámbito meramente teórico.
Todo concepto que sea adquirido a través del descubrimiento propio y de la
experimentación será considerablemente mejor afianzado y por lo tanto, un mayor grado de
permanencia de los mismos es garantizado en la mente del alumno.
El campo de estudio de este proyecto se centra en todo el proceso seguido para el diseño
de conjuntos mecánicos de transmisión de velocidad. Atendiendo a aspectos meramente
técnicos la resolución del problema planteado, tiene su correspondencia en el uso de
software comercial. Uno de los principales ejemplos de Software comercial sería KissSoft,
este software de diseño de componente mecánicos encuentra dentro sus capacidades la
realización de análisis del contacto entre elementos, tensiones, vibraciones, lubricación y
criterios de selección y diseño de dichos elementos.
Dichos programas cumplimentan toda necesidad técnica presentable en un ambiente de
trabajo. La utilización de este tipo software en un ambiente didáctico es sin embargo poco
recomendable. La propia naturaleza de un software tal como el de ámbito comercial hace
que aunque la precisión técnica y la información puramente aportada al usuario sea de
calidad comprobable, esta tienda a ser mejor enfocada a un uso en el ámbito profesional y
carecen de los medios necesarios para un aprendizaje efectivo.
Los usuarios a los que este tipo programas están destinados se suponen ya versados en los
conocimientos técnicos necesarios para el uso de los mismos. En consecuencia no se
puede controlar de una forma efectiva el proceso de aprendizaje, pues la mera aportación
de información, especialmente si esta es de alta complejidad técnica, no va a facilitar en la
mayoría de los casos la asimilación de conceptos.
El objetivo de todo software educativo se mantendrá en la emulación efectiva de aquellas
funcionalidades encontradas en un software técnico pero con la debida adición de
herramientas, conceptos teóricos y el correspondiente guiado del alumno hasta la final
comprensión de los mismos.
Toda solución tanto comercial como de ambiente educativo actual bien carece de unas
bases técnicas suficientes o no constituye un buen medio de aprendizaje. Para la
cumplimentación de este objetivo ideal el Departamento de Maquinas diseño el software
EDIMPO.
La asignaturas que se pretenden completar con el desarrollo de EDIMPO son Diseño de
Maquinas I y II. En dichas asignaturas se obtienen los conocimientos básicos de diseño de
sistemas de conexión mecánica, cálculos de lubricación, elementos de frenado, esfuerzos
en ejes y efectos del rozamiento en máquinas. La labor docente de la misma se divide en 2
bloques fundamentales: conceptos teóricos y trabajo práctico de elaboración de una
reductora.

Son asignaturas que por la naturaleza teórica de las mismas hacen especial hincapié en el
aprendizaje y efectuación de unos cálculos numérico largos y complejos que aun
necesarios, no son especialmente constructivos para el aprendizaje efectivo de como
diseñar un sistema de transmisión.
La versión actual de EDIMPO es utilizada como medio básico de desarrollo, en las prácticas
de la asignatura de Diseño de Maquinas I y II. Esta labor práctica contempla el proceso
completo de diseño de una reductora, tomando como base una máquina ya conocida. La
intervención del alumno en estas prácticas va desde el cálculo de rodamientos a utilizar,
esfuerzos y picos de tensión en los ejes motrices, diseño de sistemas de engrane,
lubricación de la maquina hasta la elaboración de planos y aquellos modelos en 3D que
sean necesarios para la completa definición de la máquina.
La adición de un software didáctico aporta al alumnado la opción de comprobar como la
importancia de los conceptos no se encuentra en los cálculos realizados, siendo estos
mismos la parte más intensivas de las asignaturas, sino en aquellos conceptos en torno a
los cuales se basan estos mismos.
Con cada actualización este programa ha ido añadiendo nuevas funcionalidades y su
interfaz gráfica ha sufrido un proceso de mejora continuo. Actualmente EDIMPO es un
software basado en la plataforma de cálculo numérico de Matlab cuyas funcionalidades se
dividen en:
 Recogida de parámetros de diseño.
 Pre dimensionamiento de la máquina.
 Selección de rodamientos.
 Interfaz de diseño de parámetros de los árboles de transmisión.
 Selección de las uniones.
Este software a pesar de aportar una base de cálculo, la fiabilidad de la misma es discutible.
Se puede afirmar adicionalmente que el uso de la misma no resulta intuitivo y presenta
grandes carencias a nivel funcional, tales como lentitud de procesamiento, falta de claridad
en las gráficas expuestas, imágenes de baja resolución o la incapacidad de las ventanas de
ser modificadas en tamaño.
Se puede afirmar que aun siendo un programa que facilita enormemente el proceso de
diseño, es un software altamente limitado como programa informático. Esta serie de
problemas técnicos interfieren enormemente en el proceso de aprendizaje, pues pueden
convertir algo que debería de surgir por la propia curiosidad del alumno en un proceso a
veces tedioso y frustrante. Luego la renovación del software era de necesidad inmediata. Es
en este punto en el cual se plantea cual es la reforma planeada para EDIMPO 2018.
El proyecto aquí descrito se realizará como un proyecto colaborativo de desarrollo,
implementado como parte de un marco superior al contemplado por este.

INTRODUCCIÓN
Ilustración 3: Arquitectura EDIMPO 2018
En la Ilustración 3 explica de una forma sencilla el proceso de intercambio de información

para la reforma planteada. Por un lado, EDIMPO va a ser objeto de una reforma de su
código, en búsqueda de posibles problemas no detectados anteriormente, la mejora del
funcionamiento general de mismo en conjunto con una restructuración de la interfaz gráfica
completa.
La mencionada reforma es acompañada de la adición de dos nuevos módulos, uno
destinado a la elaboración de análisis por elementos finitos de los modelos generados y otro
dedicado a la generación paramétrica de modelos en Solid Edge. Ambos módulos actuarán
como una extensión natural de EDIMPO, trabajando eso si por separado del mismo. El
objetivo es garantizar que el uso del programa resulte altamente intuitivo y atractivo para el
alumno.
Existirá un proceso de intercambio de información constante, de forma que el alumno
realizará el proceso de diseño apoyándose en el EDIMPO reformado, para posteriormente
analizar por elementos finitos los resultados obtenidos y finalizar con la generación
automática de estos modelos. El proceso no se limita sin embargo a este orden,
suponiéndose que existirá un proceso cíclico de diseño de modelos, análisis y validación de
los mismos, hasta que se obtengan resultados satisfactorios.
Actualmente las funcionalidades que se pretenden añadir a EDIMPO son perfectamente
realizables mediante Solid Edge, pero la consecución de las mismas no aporta nada al
aprendizaje del alumno y suponen un gasto de tiempo importante. Este proyecto plantea el
proceso de trabajo necesario para la construcción del módulo de generación automática de
modelos paramétricos.
Especialmente destacable es la cantidad de tiempo invertida por el alumnado en la
realización de modelos y planos durante el proyecto. Esta tarea puede llegar a suponer,
según lo estimado por el profesorado de las asignaturas, aproximadamente un 50% o más
del tiempo total dedicado de trabajo, incluyendo horas de estudio. Añadidamente la
generación de modelos en un entorno CAD no se considera temario de la asignatura y se
supone una competencia ya adquirida previa curso de la misma.
El objetivo último del módulo es acelerar exponencialmente el proceso de diseño y montaje
del modelo final. Un uso correcto del programa ha de ir acompañado de ese intercambio de
información entre las distintas partes de EDIMPO para garantizar el mejor aprovechamiento
de la herramienta.

Las funcionalidades que se pretenden añadir mediante este módulo se corresponden a:

 Generación de forma básica de árboles motrices.
 Generación de ruedas engranadas.
 Elaboración de un auto informe de los modelos obtenidos.
Es por lo tanto un proyecto destinado a que el alumno ahorre el máximo tiempo posible en el
proceso de modelado, aportándole una base de trabajo fácilmente modificable. Es de
especial mención el tiempo que deja de ser invertido en la formación de las ruedas
engranadas proceso altamente complicado de realizar manualmente. Al disponer el alumno
de una serie de modelos ya formados, el proceso de reconstrucción de los mismos pasa por
el simple cambio de parámetros en el programa principal, aportando de esta forma al
alumno de una herramienta que facilitará su aprendizaje.
Con el informe, se pretende acelerar todavía más ese proceso, disponiendo de una
herramienta para comprobar los resultados obtenidos, sin necesidad de entrar en Solid Edge
y validar uno a uno los modelos generados. El informe aportará todo el conjunto de
parámetros necesitados para la elaboración de dicho modelo, facilitando la comprobación de
posibles errores humanos. El proyecto se considera finalizado con la verificación de
resultados y final implementación en EDIMPO.
2.1. Motivación Académica
La motivación a nivel académico detrás del desarrollo de este proyecto se puede resumir
esencialmente en la necesidad de aportar a un alumnado, que actualmente da uso a una
herramienta mejorable, de unos medios de calidad, destinados a fomentar su aprendizaje.
Es por lo tanto un proyecto que va a repercutir positivamente en los medios de enseñanza
de la universidad y que en última instancia facilitará la tarea lectiva del profesorado.
No limitándose exclusivamente al ámbito académico se puede afirmar que con la correcta
implementación de este proyecto, la universidad adquiere conocimientos efectivos en la
automatización de programas de diseño por ordenador, campo poco explorado y cuyo
número expertos es muy limitado. Ofrece por lo tanto una ventaja a nivel competitivo con
otras instituciones y aporta las bases para el desarrollo de nuevos proyectos en este campo.
Por ultimo dado que el objetivo final del proyecto tanto individual como colectivo del grupo
de desarrollo en el que este ha sido ejecutado, es la mejora y final implementación de
EDIMPO como una herramienta comparable a software comercial, existe la posibilidad de
una final venta y distribución del mismo.

INTRODUCCIÓN
2.2. Motivación Personal
Para poder explicar porque personalmente he elegido este proyecto de fin de carrera
primero debo hacer una pequeña introducción a mi interés personal en el desarrollo de
código y el modelado 3D.
Como entretenimiento personal he convertido la modificación de videojuegos en una de mis
principales formas de entretenimiento desde hace varios años. Estas modificaciones
implicaban el desarrollo de modelados en 3D y en muchas ocasiones la modificación del
código del propio juego para poder adaptarlos mis propias visiones personales.
Como consecuencia de ello me vi naturalmente atraído hacia este proyecto, pues
combinaba dos de los que creo que son algunos de mis mayores puntos fuertes: el
desarrollo de modelos en 3D y la programación en plataformas con las que he tenido poco o
ningún contacto.
En consecuencia la principal dificultad que planteaba este proyecto, el aprendizaje e
investigación de un medio viable para la elaboración de un programa complejo a través de
plataformas que en su momento me resultaban desconocidas, no ha constituido un
problema para mí. Este proyecto llego a mis oídos gracias a mi propio interés en buscar un
trabajo relacionado con el diseño de máquinas. Desde el primer momento que supe de su
existencia, quise participar en él, independientemente de las posibles dificultades que este
pudiese aprender.
Es importante mencionar que dado que el proyecto presentado implica un trabajo de
desarrollo real en equipo con otras personas a las que en su momento conocía poco, me ha
supuesto además un beneficio en experiencia de desarrollo en equipo, la cual en otro tipo de
trabajo hubiese sido difícil de encontrar.
Es por lo tanto un proyecto que no solo me ha llamado la atención desde mis gustos
personales, sino que además me ha aportado experiencia real y tangible a nivel profesional
y una serie de competencias difíciles de encontrar en el ámbito profesional tales como
aprender a utilizar Visual Basic, mejorar mis habilidades en desarrollo de modelos 3D y
conocimientos de desarrollo de aplicaciones y especialmente conocimiento de primera mano
en la automatización de procesos constructivos en un entorno CAD.

3. OBJETIVOS
El módulo a crear ha de ser ante todo momento un elemento de software de ámbito

académico. Este por lo tanto debe ser sencillo de utilizar y debe constituir una herramienta
intuitiva, capaz de facilitar el trabajo del alumno y fomentar su aprendizaje. No obstante se
contempla la posibilidad de una futura implementación como software profesional y por lo
tanto es de especial importancia la eficiencia del código programado.
Leyenda: AZUL – Objetivo principal. Verde – Objetivo secundario.
Se identifican como objetivos:
OBJETIVO A: Creación automática de modelados 3D de árboles motrices y ruedas
engranadas en reductoras.
Objetivo A.1: Elaboración de algoritmo de generación de árboles motrices y sus

elementos asociados.
Objetivo A.2: Elaboración de algoritmo de generación de ruedas engranadas.
Objetivo A’1: Establecimiento de un protocolo de intercambio de datos entre
programas utilizados.
Objetivo A’2: Implementación de parámetros constructivos mediante programación
por objetos.
OBJETIVO B: Estudio de herramientas de trabajo en la API Solid Edge ST10 de cara a usos
futuros.
Objetivo B.1: Adquirir conocimientos de programación en software Solid Edge PLM.

Objetivo B.2: Estudio de herramientas y guías de utilización de las mismas de
modelado paramétrico en Solid Edge.
Objetivo B.3: Obtención de conocimientos en manejo de bases de datos.
OBJETIVO C: Verificación e integración de la herramienta diseñada en software EDIMPO.

Objetivo C.1: Análisis de resultados y verificación de dimensiones y modelos
generados.
Objetivo C.2: Implementación de la herramienta de automatización al modelado en
EDIMPO.
OBJETIVO D: Actualización de los modelos creados de una forma eficiente y en la que la

interacción del usuario con Solid Edge se limite a la modificación de datos en el programa
principal.
OBJETIVO E: Elaboración de auto-documento PDF de modelos y parámetros de especial

importancia para los mismos.

METODOLOGÍA
3.1. Planificación temporal

La planificación del presente proyecto se ha llevado a cabo según el siguiente diagrama de
Gantt.

3.2. Presupuesto
El proyecto ha seguido la relación de presupuesto presentada en la siguiente tabla:
Concepto Coste unitario N.º Unidades TOTAL

I. PERSONAL
Desarrollo del producto
Ingeniero principiante 16 €/h 390 h 6240 €
Dirección de proyecto
Ingeniero experimentado 30€/h 70 h 2100 €
II. Inversiones
Amortización equipos 120€/u 1u 120 €
informáticos
Documentación
COSTE TOTAL 8460 €

IMPLEMENTACIÓN
4. METODOLOGÍA
Para la realización de este proyecto se ha planteado la siguiente guía de actuación como

bases previas a la ejecución del mismo.
 Se elaborará un listado previo de capacidades que debe cumplir cada parte
individual del módulo a desarrollar.
 Se organizarán todos los datos a manejar en cada uno de estos sub-objetivos y se
planteará una estructura para el uso de los mismos que facilite el proceso
constructivo.
 Se estudiara el algoritmo de dibujado y construcción de los modelos a generar
previamente en el entorno Solid Edge.
 Se hará un estudio de las funciones necesarias para la consecución de este mismo
algoritmo dentro de la API de Solid Edge.
Esta ha constituido el esquema de trabajo seguido durante la elaboración del proyecto. El
objetivo último buscando con esta guía de actuación era garantizar que en todo momento
cada uno de los pasos a seguir, eran viables técnica y temporalmente. Para una mejor
comprensión del mismo se aporta el siguiente mapa conceptual.
Ilustración 4: Guía de actuación.
A continuación se explicaran las bases de trabajo en torno a las cuales se fundamenta el

proyecto incluyendo nociones necesarias para la ejecución del mismo, planteamiento
organizativo necesario para consecución ultima del proyecto y una breve explicación de
ciertos algoritmos de importancia destacada.

4.1. Proceso de recogida de datos e Investigación previa
Una vez definidos los objetivos de una forma unívoca es necesario plantear las posibles vías
de solución de cara al problema planteado.
El módulo debe permitir la interacción entre dos programas ya existentes, EDIMPO y Solid
Edge y por lo tanto previo planteamiento a cualquier solución a la problemática es necesario
conocer bajo que medios ambos trabajan y que posibles dificultades puedan surgir de la
interacción entre ambos. Es por lo general una de las mayores problemáticas presentes en
cualquier proceso de diseño de aplicaciones, pues una vez alcanzada una mínima
complejidad la interacción entre aplicaciones no desarrolladas por el mismo equipo es
inevitable.
No todos los programas funcionan mediante el mismo lenguaje de programación ni bajo el
mismo régimen de administración de datos, realidad que creará numerosas dificultades. El
lenguaje en el cual una aplicación es construida, constituye el medio lógico bajo el cual,
cualquier tipo de acción que esta ejecuta es regulada y determinará en consecuencia las
posibles interacciones con otras aplicaciones.
El caso concreto que se maneja en este proyecto se corresponde con la interacción entre un
programa basado en el lenguaje propio de la plataforma Matlab de Mathworks S.L y una
API [1] cuyo funcionamiento se debe a la tecnología VB.NET [2]. EDIMPO es un programa
propio del departamento DIM [3] de la ETSII UPM, cuyo código se basa en el lenguaje
utilizado por Matlab. Por el contrario, Solid Edge tiene su código construido con Microsoft
Visual Basic.
El hecho de que ambos programas presenten distintos lenguajes de programación no
tendría por qué suponer una dificultad en caso de que se hubiesen creado previamente
medios específicos para su interconexión. Este el caso por ejemplo entre el propio Matlab y
los productos de Microsoft Office, aun basando estos últimos igualmente su código en
lenguaje Visual Basic.
El problema surge del hecho de que Matlab por sí solo no es capaz de ejecutar código
proveniente de Visual Basic, condición necesaria para poder efectuar cualquier tipo de
acción sobre la API de Solid Edge. Como se pretende elaborar un programa capaz de
coordinar de forma automática estas plataformas, al no existir ninguna herramienta oficial
capacitada para traducir la información manejada por ambos sistemas, se hace necesaria la
intervención de medios terceros. La fase preliminar de investigación se centró por lo tanto en
determinar una forma efectiva de comunicar ambos programas.
Tras un estudio básico de las funcionalidades que presenta Matlab y de las características
propias de programas comunes basados en Visual Basic, se observó que un medio efectivo
para poder realizar esta misma interconexión vendría de la mano de los productos de
Microsoft Office. Más concretamente a través de Excel, el programa de manejo de datos
más extendido en la actualidad.
El paso posterior a la determinación de un posible medio de comunicación entre programas
consistió en un estudio de qué posibilidades presenta Solid Edge a ser automatizado. Por lo
general la mayoría de programas de diseño por ordenador tienen como funcionalidad
incluida, la capacidad de ejecutar piezas de código propias del usuario. Estas son las
llamadas Macros [4].
Siemens con motivo de potenciar las herramientas ofertadas en su plataforma, ofrece a los
usuarios de Solid Edge una guía básica pero de gran utilidad para la iniciación en
programación de dichas macros.

IMPLEMENTACIÓN
A pesar de que el código de las rutinas que Solid Edge contiene no está ofertado al usuario,
sí que se le da la opción de utilizar las mismas herramientas de desarrollo que permiten el
funcionamiento de dichas rutinas.
Una vez determinado que el proyecto podía ser llevado a cabo, el siguiente paso en la
investigación concernió la adquisición de conocimientos en programación de Visual Basic.
Esta labor fue realizada mediante la consulta de guías online y de libros de programación en
Visual Basic indicados en referencias.
Por último se destaca que los algoritmos descritos a lo largo de este documentos al igual
que ha sido aclarado mediante la guía de actuación han sido previamente emulados de
forma manual en Solid Edge. Una vez determinado el procedimiento manual a seguir se ha
intentado emularlo mediante código, proceso que por dificultades expresadas
posteriormente no ha sido posible en la mayor parte de los casos.
4.2. Recursos necesarios
En este capítulo se ofrece una breve introducción de cada uno de los programas o recursos
utilizados durante la elaboración de este proyecto y una introducción a los motivos por los
cuales han sido necesitados.
4.2.1. Microsoft Visual Basic .Net 2017
El entorno de programación de Microsoft Visual Basic, es una herramienta que permite a un

usuario la sencilla creación de programas capaces de interactuar con dispositivos móviles,
páginas web o el propio PC. Uno de sus principales atractivos es la completa compatibilidad
de los distintos lenguajes de programación que soporta, principalmente un lenguaje propio
denominado Visual Basic y da soporte para el lenguaje C++. Dicha capacidad se traduce en
la habilidad que presenta Visual Basic para poder interpretar código de ambos lenguajes sin
la necesidad de instalar ningún parche o paquete adicional. Ambos lenguajes son
completamente intercambiables internamente y permiten una gran flexibilidad durante el
trabajo con esta plataforma. Otros lenguajes son igualmente soportados solo previa
instalación de herramientas preparadas para habilitar la mutua interacción, como sería el
caso de Python.
Esta plataforma es por lo general gratuita, ofreciendo un paquete básico muy completo y
capacitado en su totalidad para la elaboración de aplicaciones y programas que hagan uso
de interfaces gráficas. Solo mediante pago las herramientas más potentes son accesibles
sin embargo las restricciones presentadas no suponen un obstáculo para elaboración de
este proyecto.
Este entorno de programación ofrece al usuario la capacidad de crear programas de
interfaces graficas (GUI) [5] de relativa complejidad gracias a un esquema de funcionamiento
altamente modular. La gran mayoría de aplicaciones de complejidad media que vayan a
interactuar dentro de un sistema operativo Windows hacen uso de esta plataforma.
Dentro de las capacidades contempladas por esta Visual Studio se encuentran, la creación
de diversos tipos de paquetes informáticos, tales como aplicaciones de consola, páginas
web, elaboración de librerías, formularios [6] y demás piezas de código destinadas a facilitar
la programación.

Resultan especialmente útiles los formularios. Estos actúan como base sobre la que se
podrán disponer módulos de texto, cajetines a rellenar, botones y diversas plantillas de
trabajo que permiten la fácil elaboración de interfaces. Constituyen en sí mismos las bases
con las que cualquier programa complejo será construido.
El uso de estos módulos se

centra en la aportación al
usuario de una serie de
herramientas intercambiables,
que permiten al usuario elaborar
los bloques constructivos de un
programa de una forma sencilla
y fácilmente transferible. Estos
fueron creados por la
desarrolladora de la plataforma,
con el objetivo de limitar la
interacción del usuario al diseño
de bloques con los que se irán
completando las funcionalidades
de cualquier programa.
Ilustración 5: Tipos de proyectos predefinidos
La interacción con los mencionados bloques se lleva a cabo mediante asignaciones de

variables y la modificación de una serie de propiedades preestablecidas por la
desarrolladora. Dichas propiedades determinan las reglas de interacción de los bloques,
siendo estos altamente modificables, existiendo incluso la posibilidad de añadir nuevas
propiedades con las que diseñar bloques de construcción personalizados.
La plataforma Visual Basic oferta una amplia selección de paquetes diseñados para facilitar
la coordinación con programas de uso extendido, como los productos de Microsoft Office o
de Adobe. Dichos paquetes constituyen los paquetes de interoperabilidad, que como se verá
en futuros apartados resultan fundamentales para el establecimiento de un correcto
funcionamiento entre aplicaciones carentes de un desarrollo común.
El programa que se busca crear en este proyecto actuará en cambio principalmente como
aplicación de consola y por lo tanto no será necesaria la inclusión de ningún elemento de
tipo grafico como los formularios, siendo la interfaz gráfica dependiente del programa madre
y establecida en lenguaje Matlab.
Adicionalmente la propia plataforma constituye la base con la que la API de Solid Edge fue
desarrollada. Este es el motivo por el cual se ha elegido Microsoft Visual Basic como
entorno de desarrollo principal del programa propuesto en este proyecto.
Visual Studio como medio de programación, hace especial énfasis en la capacidad de crear
tipos de datos propios, diseñados para una mejor optimización del manejo de la información
y para facilitar la comprensión de código por parte del programador. Esta es la llamada
programación por objetos y constituirá uno de los principales apoyos sobre los que se
sustenta la elaboración de este proyecto.
Finalmente esta plataforma aporta la posibilidad de crear librerías propias con relativa
facilidad, permitiendo de esta manera la creación de un cumulo de funciones ordenadas y
fácilmente exportables que podrán ser utilizadas en nuevos proyectos o intercambiadas
entre módulos. Dicha capacidad se hará especialmente útil en la coordinación entre módulos
del programa EDIMPO.

IMPLEMENTACIÓN
4.2.2. Solid Edge ST9/ST10
El entorno de diseño en 3D de Siemes PLM Software o Solid Edge, es un sistema de diseño

asistido por ordenador (CAD) [7] para producción de dibujos y el modelado de conjuntos de
piezas mecánicos, capacitado para la elaboración de estudios y simulación de los mismos.
Al ser una herramienta CAD moderna, su estructura interna fue diseñada para que los
comandos que el usuario necesite le sean fácil acceso. Solid Edge dispone de entornos
separados para crear piezas, construcción de conjuntos y producción de planos. Cada
entorno ha sido diseñado para su utilización por separado e independientemente, aunque
existe la posibilidad de su funcionamiento en conjunción.
Solid Edge es una plataforma pensada para aportar al usuario de una herramienta de diseño
modular. El usuario dispone de la posibilidad de modificar y de adaptar con una amplia
libertad el entorno de diseño, desde la organización interna de funciones, menús
contextuales, a la capacidad de completar las funcionalidades internas del programa.
Su estructura interna se basa en las normas de funcionamiento impuestas por la plataforma
Visual Basic. Esto implica que todo elemento que Solid Edge utiliza para la elaboración de
modelos o el funcionamiento interno del mismo está basado en la programación por objetos.
En consecuencia su estructura ha sido diseñada para que sea fácilmente modificable y por
lo tanto constituye un medio ideal para plantear el proyecto.
Es actualmente la plataforma de diseño por ordenador preferida por la institución
universitaria, siendo el acceso a la misma habilitado para todo el alumnado. Al disponer la
totalidad de los posibles usuarios del programa a diseñar de esta plataforma, se elimina la
posibilidad de que la herramienta no sea accesible a alguno de os usuarios finales. La
licencia de la que dispone la universidad es actualizada todos los años y se corresponde con
un paquete especialmente pensado para el uso universitario.
Una de las ventajas principales de las que Solid Edge dispone sobre cualquier otro tipo de
plataforma de diseño por ordenador actualmente habilitada por la universidad, tales como
Catia, es la alta disponibilidad de información en comparativa, aunque esta resulte escasa
de cara a la automatización del mismo.
Siemens durante el desarrollo de la plataforma hizo especial hincapié en garantizar que los
usuarios que fuesen a utilizar la plataforma dispusiesen de herramientas lo suficientemente
potentes como para fomentar el desarrollo de la misma a nivel individual. De esta forma
promoviendo la constante mejora de la plataforma por sus propios usuarios y garantizando
que se desarrollase un entorno de intercambio de información natural entre los mismos.
Esto es especialmente notable en la existencia de un foro de intercambio de código y
desarrollo exclusivamente pensado para la automatización de Solid Edge. En este medio
existe una amplia selección de preguntas realizadas por usuarios, junto con una extensa
gama de tutoriales destinado a ayudar a nuevos desarrolladores en la tarea de automatizar
la plataforma.
En consecuencia por todos los motivos mencionados Solid Edge constituye un medio ideal
para el desarrollo del proyecto planteado.

4.2.3. Microsoft Office Excel
Microsoft Office es un paquete de programas de edición de texto, cálculo y organización en

claves generales destinado a un entorno de trabajo de oficina. Debido a la gran extensión y
uso de las distintas versiones de este paquete, resulta ideal para la utilización en el
desarrollo de aplicaciones. Se puede asumir correctamente que la mayor parte de los
posibles usuarios dispondrán de alguna versión de esta herramienta.
Más concretamente al ser un programa destinado al uso en el ámbito académico de la
universidad politécnica de Madrid y al ser la licencia de utilización del mismo gratuita para
todo el alumnado es posible afirmar que no existirán problemas de acceso al mismo.
De cara a este proyecto al ser soportado como medio de acceso a información tanto por
Matlab como por Visual Studio, Excel constituye una plataforma ideal para la comunicación
entre los programas que se pretenden coordinar. Por si mismo Excel se presenta como una
herramienta capacitada para el manejo de grandes cantidades de información, la
elaboración de bases de datos, representación gráfica a incluso desarrollo macros en
programas de gran complejidad. Esta última capacidad será aprovechada en el desarrollo
del proyecto.
4.2.4. Mathworks Matlab
La plataforma de cálculo numérico Matlab de Mathworks fue originalmente diseñada bajo la

premisa de aportar una herramienta de modelización matemática precisa y de sencilla
operación. A lo largo de su desarrollo y tras diversas actualizaciones, esta ha adquirido una
complejidad muy por encima de su objetivo inicial.
Matlab permite así mismo la elaboración de aplicaciones de naturaleza sencilla pero
especialmente pensadas para el cálculo numérico. Es por esta razón por la que en su primer
momento fue elegida como plataforma de desarrollo inicial para el programa EDIMPO.
Dentro de las capacidades que Matlab incluye se encuentran las siguientes:
 Lenguaje de alto nivel pensando para el cálculo numérico.
 Entorno de escritorio desarrollado para la el fácil diseño y solución de problemas
 Herramientas de visualización gráfica y representación de diagramas altamente
modificables.
 Paquetes de herramientas complementarias para una amplia variedad de
aplicaciones científicas y de ingeniería
 Herramientas para crear aplicaciones con interfaces de usuario personalizadas.
® ® ®
 Interfaces para C/C++, Java , .NET, Python, SQL, Hadoop y Microsoft Excel .
De cara a este proyecto la interacción con el mismo se limitará a la elaboración de una

interfaz gráfica breve, destinada a la recogida de datos y a la aportación de información
esencial de cara a la utilización del módulo.

IMPLEMENTACIÓN
Es sin embargo importante tener en cuenta las capacidades y limitaciones de la propia

plataforma para la elaboración de un proyecto exitoso. Como ya ha sido mencionado
previamente, Matlab es incapaz de trabajar con código proveniente de otros lenguajes de
programación ajenos al propio, aparte de la activación remota de ejecutables o la interacción
con archivos que la práctica totalidad de aplicaciones de Windows ya realizan por sí
mismas.
4.2.5. Spy for Solid Edge
Esta aplicación constituye una herramienta indispensable para la programación de cualquier

tipo de código que utilice como base la API de Solid Edge. Su origen se remonta a la
necesidad por parte de los usuarios más avanzados de Solid Edge de una herramienta que
les permitiese el discernir el funcionamiento interno de la propia API. A pesar de los
esfuerzos por parte de Siemens las guías disponibles no aportan toda la información
necesaria para la correcta utilización de las herramientas aportadas por Solid Edge. Hecho
especialmente notable en el desarrollo de cualquier programa de relativa complejidad, como
es el caso de este módulo.
Dado que en todo momento el número de elementos a manejar durante la automatización
de Solid Edge puede llegar a resultar inabordable, Spy for Solid Edge aporta una
herramienta capacitada para un desarrollo más sencillo y cercano al usuario.
Ilustración 6: Spy for Solid Edge
Es una aplicación de código libre desarrollado como parte de un esfuerzo comunitario. La

comunidad de desarrolladores de Siemens ideó está plataforma como un medio en el que la
visualización de las tareas que Solid Edge ejecuta en todo momento sean de fácil rastreo.

Entre las distintas capacidades que esta herramienta aporta al usuario se encuentran las
siguientes funcionalidades:
 Control instantáneo sobre los distintos objetos usados en todo momento por la
aplicación Solid Edge en tiempo real.
 Explicación detallada y jerárquica de las relaciones entre los elementos que Solid
Edge utiliza.
 Recopilación de las librerías de Solid Edge, junto a una breve explicación de su
utilización (a veces), relaciones mutuas entre funciones y elementos necesarios para
su definición.
 Historial de comandos de Solid Edge utilizados en orden temporal.
 Modificación de parámetros de internos de funcionamiento del programa en el
momento.
 Buscador interno de todos los procesos ejecutados por Solid Edge en tiempo real
junto a que librearías estos están asociados.
Está a herramienta se ha demostrado de grandísima utilidad para la elaboración de este

proyecto, pues aun existiendo guías de utilización de la API de SE estas cubren solo los
aspectos más básicos y mínimos para la iniciación en la plataforma. La mayor parte de
tiempo de trabajo ha sido destinado en una forma u otra a la averiguación de que funciones
a utilizar en cada momento y como definirlas.
A pesar de que Siemens ha pretendido aportar todos los medios necesarios para la
utilización de su plataforma, una gran cantidad de veces, los nombres de las propias
funciones no son auto explicativos, o la utilización de las mismas no es clara.
Esta problemática se hace especialmente notable cuando se pretende interactuar con
objetos de alta complejidad como la definición de planos sobre superficies, operaciones de
construcción del modelo 3D o más concretamente el uso de tipos predefinidos de datos,
numerando estos mismos en las centenas y sin explicación clara de cuándo o como
utilizarlos en cada momento. Los problemas aquí brevemente expuestos serán detallados
más ampliamente en apartados posteriores.
4.2.6. PDF Sharp
PDF Sharp constituye un conjunto de librerías de uso libre, que permiten la elaboración de
documentos PDF de forma automática, mediante la codificación bien en lenguajes C++ o
Vb.net. Dichas librerías se encuentran facultadas de una gama de funcionalidades que aun
ligeramente más limitadas que las herramientas originales de elaboración de texto propias
de Adobe o Microsoft, sí que permiten la construcción automática de documentos complejos.
Esta es una de las limitaciones más destacables de las herramientas de formateo de texto
más expandidas, lo que hace necesario apoyarse en medios terceros como sería PDFS-
harp.
Existe la posibilidad de la elaboración automática de documentos en formato de bloc de no-
tas mediante la propia plataforma de desarrollo Visual Basic, pero la complejidad de las
mismas palidece en comparación con las utilidades aportadas por PDF Sharp. Por este
mismo motivo y gracias a ser código de uso libre, fue elegido como base para la elaboración
automática de informes. En siguientes apartados se explicará en detalle el funcionamiento
de la librería junto al formato y objetivos que se pretenden conseguir con la elaboración del
informe de post-modelado.

IMPLEMENTACIÓN
4.3. Esquemática de la utilización de recursos
En este apartado se explicaran una serie de bases fundamentales en el proceso de

desarrollo del programa en relación con las herramientas de mayor importancia utilizadas. El
objetivo es aportar una idea general de cuál es el punto de vista del programador y cuáles
son las consideraciones de mayor importancia de cara a la interacción con dichos recursos.
4.3.1. Interacción con Solid Edge
Solid Edge constituye una herramienta de diseño de

modelos 3D que se beneficia ampliamente de la
programación por objetos [8] de la que hace gala Visual
Basic.
El programa funciona mediante una API que agrupa
todas las rutinas, de las que dispone Solid Edge, de una
forma ordenada y parcialmente intuitiva en la que
aspectos tales como tipos de documentos, elementos de
trabajo en la construcción de modelos, geometría o
herramientas de administración de datos son separados
en librerías concretas.
Dichas librerías de funciones agrupan las partes
constitutivas del programa, como toda librería, pueden
Ilustración 7: Librerías Solid Edge.
ser exportadas para su uso fuera del código propio de
Solid Edge.
Mediante las mencionadas librerías se pueden definir variables de tipos ya especificados por
Solid Edge, capaces de interactuar entre sí por unas reglas de funcionamiento internas,
determinadas por la definición de cada tipo de dato. Como ejemplo de esto mismo se puede
mencionar como los elementos de dibujado, deben de ir asociados a planos, perfiles o
demás superficies.
Cada unidad operativa que es utilizada en este entorno CAD tienen por lo tanto una
representación a nivel de código en forma de un tipo de dato, caracterizado por sus
propiedades, formas en las que interactúa con el resto de elementos del programa o
funciones de las que está capacitado para usar. En consecuencia Solid Edge organiza su
funcionamiento en torno a unidades de información próximas a la realidad y que son
interpretables como una extensión de aquello que el usuario percibe durante la elaboración
de modelos. Esta es la principal ventaja de la llamada programación por objetos.
Uno de los aspectos fundamentales respecto al funcionamiento de Solid Edge es el modo de
generación de modelos con el que se trabaja, pues este determinará como se debe de
proceder a la hora de construir dichos modelos. Naturalmente esto implica que dependiendo
de cuál es el modo con el que se desea trabajar, la propia simulación interpretará la
información contenida en el código de forma distinta.
En definitiva, el modo de trabajo atenderá a distintas normas internas de funcionamiento,
aspecto fundamental a entender previa elaboración de cualquier solución. Los principios
más básicos de estas serán explicados brevemente a continuación.

Modos:
 Ordenado.
 Síncrono.
Solid Edge es capaz de funcionar en dos modos

principales. Cada modo tiene una serie de
particularidades, pero la principal diferencia que
estriba entre estos es que en el modo síncrono,
carece de un historial de operaciones. Esto significa
que las operaciones se definen por los elementos que
intervienen en las mismas y no por el orden sucesivo
con el que estas han sido ejecutadas. Elementos
tales como caras, líneas, aristas, perfiles y relaciones
entre ellos, serán lo que defina como se interpreta
cada modificación realizada al modelo. El orden es Ilustración 8: Modo de operación SE
importante, pero en ningún momento este será
prioritario a las relaciones establecidas.
El programa interpreta el resultado final no tanto como una consecución de operaciones sino
como una suma de las mismas. De esta capacidad es de donde proviene su nomenclatura.
El modo síncrono nos aporta una gran facilidad a la hora de construir modelados
manualmente, gracias a poder modificar operaciones ya realizadas sin necesidad de ir a la
operación concreta sobre la que hay que actuar
Este comportamiento es de extrema importancia pues ello implicará que no se pueda
mantener un control natural sobre la jerarquía entre operaciones. Aun siendo posible realizar
modificaciones a los modelos con unas restricciones mucho menos estrictas, esto implica
igualmente que se pierde gran parte de la intuitividad que se pueda tener programando las
operaciones. En cierto modo ello acarrea que siempre y cuando aquellas operaciones
pedidas al programa no sean incompatibles con sus criterios de verificación, las últimas
operaciones realizadas no tienen por qué ser prioritarias a las acometidas anteriormente,
siendo posible cambiar la jerarquía de las mismas mediante código.
En apariencia esto puede suponer una ventaja de cara a crear un programa destinado a
automatizar el proceso de construcción de modelos. Esto sin embargo no es así, pues
naturalmente todo algoritmo es una consecución en orden de operaciones y el proceso
necesario para idear uno que sea la suma de las mismas y no, un orden de ellas es
considerablemente más complejo. Es en última instancia una herramienta que Solid Edge
ofrece para facilitar el trabajo de diseño gráfico, haciendo el proceso más natural delante de
la pantalla, pero no más intuitivo a través de código.
Por el contrario el modo ordenado, como su nombre indica basa toda su lógica de
funcionamiento en mantener un orden jerárquico claro. La utilización del modo síncrono a
pesar de tener ventajas propias, no resulta aconsejable a nivel código. Cuando se programa
el tener claro en todo momento que es posible y que no, es fundamental.
Contrariamente el modo ordenado sí que actúa como un historial de operaciones, siendo la
ordenación de los mismos clara y concisa, sabiendo en todo momento que operación tiene
jerarquía u orden de preferencia sobre cual, pues nosotros mismos elegimos esta
subordinación al seguir un orden concreto. Dicha ordenación es secuenciada de manera
automática por Solid Edge, guardando las operaciones del documento en los ya explicados
objetos o unidades básicas de información que estos contienen.

IMPLEMENTACIÓN
El almacenamiento de los mismos se lleva a cabo por relaciones de referencia [9]. Todo
objeto o dato que sea manejado por dichas relaciones es controlado no a través de su valor
sino de la posición en memoria que este tenga. En consecuencia, se puede actuar sobre el
valor de una propiedad a través de todo el código del programa sin verse limitado por
definiciones concretas de datos.
En una función por ejemplo, a no ser que sea una información transmitida por referencia,
todo cambio que se realice en la misma no va ser objeto de interpretación fuera de esa
unidad de código. Al almacenar la información por referencias, el orden en que estas han
sido añadidas, a los conjuntos concretos encargados de almacenar cada tipo de dato cobra
una importancia suprema. El modo síncrono no nos garantiza conocer dicho orden aunque
podamos controlarlo.
Por esta misma razón junto a lo explicado anteriormente todo el proyecto se realiza en el
modo Ordenado. Salvo indicación concreta este será igualmente el modo predeterminado
de funcionamiento de Solid Edge. Existe la posibilidad de trabajar de forma conjunta con
ambos modos, pero ante la complejidad asociada a dicha tarea se ha preferido evitar la
mezclar de los mismos.
Una vez definido bajo qué modo de funcionamiento se trabajará, el siguiente paso es la
elaboración de un protocolo de actuación sobre Solid Edge. Dado que el programa a diseñar
pretende actuar de la forma más eficiente posible, se debe evitar salvo que sea
estrictamente necesario iniciar más de una vez Solid Edge, de esta forma acelerando el
proceso de generación de modelos.
Como no siempre existirán los
documentos sobre los que se
va a trabajar, es necesario
además crear una serie de
funciones destinadas a la
coordinación de archivos. El
protocolo de actuación será el
siguiente.
Una vez es iniciado EDIMPO,
el usuario ejecutará el módulo
de automatización.
Inmediatamente el programa
comprobará si ya existe una
sesión previamente abierta de
Solid Edge y en caso de que
esto sea verdad, no se iniciará
el proceso de apertura de este
mismo. El objetivo es ahorrar
considerablemente en tiempo
de ejecución.
En caso de no ser así se inicia
una sesión de Solid Edge y a
posteriori se comprueba si
existe o no un documento
abierto de pieza.
Ilustración 9: Protocolo de actuación sobre documentos.

Dicho documento es controlado por una posición conocida en los archivos de EDIMPO, en
caso de que no haya ningún documento que se corresponda con el nombre utilizado
internamente se creará uno nuevo. Si este existe y no se encuentra abierto, se iniciará su
apertura y si existe y se encuentra abierto este será utilizado para la ejecución del módulo.
El resto de operaciones a realizar con Solid Edge se encuentran comprendidas dentro del
algoritmo concreto desarrollado para la generación de ambos modelos y su proceso de
guardado. Ambos aspectos serán explicados en gran profundidad en futuros apartados.
4.3.2. Interacción con Microsoft Excel
La aplicación de Microsoft Office Excel será utilizada como plataforma intermedia de

comunicación entre aplicaciones junto a su uso como base común de recogida de datos.
El proceso comienza primero partiendo de la base de que el usuario ha elaborado una
solución a la problemática planteada, mediante el programa principal EDIMPO. Este
programa se encargará de otorgarle al usuario de los datos necesarios para la posterior
elaboración de los modelos, desde criterios de diseño, recomendaciones e información de
los distintos parámetros que deben de ser utilizados.
El usuario consecuentemente aprovecha toda esta información y aporta al programa los
datos que ha de utilizar, en todo momento siendo estos introducidos con un patrón que es
indicado al usuario. Indicando unidades de medida o información esencial para la definición
de los modelos que se buscan crear. De no cumplirse este requisito no se garantiza el
correcto funcionamiento del programa pues la introducción de datos que no se correspondan
con lo especificado al usuario, resultará en modelos inválidos, tales como diámetros de
sección nulos o radios negativos.
Ilustración 10: Diagrama de lógica del módulo de generación paramétrica.
Toda esta batería de datos es posteriormente guardada por EDIMPO en un archivo EXCEL
madre, archivo que aporta la información necesaria para cada módulo de EDIMPO. El
motivo por el cual la información es almacenada conjuntamente es para garantizar que

IMPLEMENTACIÓN
cualquier modificación realizada por el usuario se extienda a todos los módulos incorporados
al programa.
De cara a la construcción gráfica de los modelos solo algunos de los datos contenidos en
este archivo Excel serán utilizados y por lo tanto es necesario elaborar una subrutina que
ataque este problema. La explicación de la mencionada rutina y la estructura de datos se
explicarán en mayor detalle en los apartados 4.4.1 y 5.2.3.
La mencionada subrutina, se encarga de la organización interna de los datos constructivos
de los modelos, datos que han sido leídos previamente del archivo Excel madre y de un ar-
chivo auxiliar utilizado exclusivamente para la determinación de los parámetros de las rue-
das engranadas.
Este último archivo es actualizado cada vez que vaya a ser necesario el uso de los paráme-
tros de construcción para los engranajes. Internamente el archivo ha sido programado en el
propio sistema Excel para que con los parámetros fundamentales del conjunto engranado,
previamente leídos en el archivo madre, se construya la curva necesaria para la elaboración
del diente. Este proceso será explicado en mayor detalle en futuros apartados. Al guardar
todos los datos en un formato conocido se permite una programación considerablemente
más intuitiva y organizada.
Por lo tanto la interacción con Excel se basará en un proceso constante de entrada y salida
de información a estos dos archivos, producido sin intervención directa por parte del usuario.
El esquema funcionamiento representado en la ilustración 10, explica la lógica que seguirá
la interacción usuario-módulo.
Primeramente el usuario introduce a través de EDIMPO los parámetros iniciales de cons-
trucción que crea convenientes y estos mismos son almacenados por el programa en el ar-
chivo común de datos. A continuación dichos datos son leídos por parte del protocolo de
administración de datos y estos mismos son almacenados en una base interna, pensada
para una mejor administración de los mismos durante la automatización de Solid Edge.
Los datos son posteriormente utilizados por parte de las sub-rutinas creadas para la genera-
ción de los modelos y estos una vez finalizados son almacenados. La información pertinente
al usuario es consecuentemente visualizada a través de un informe en PDF que el individuo
consultará para comprobar el resultado final que los parámetros introducidos han dado lu-
gar.
De esta forma se evita la innecesaria interacción directa con los modelos y se aportar al
usuario de una herramienta que facilitará su proceso de decisión. Una vez comprobado se
realizan las modificaciones pertinentes a través de EDIMPO y el ciclo se inicia de nuevo. En
caso de no detectarse ninguna modificación a los modelos, estos no serán generados de
nuevo.
4.3.3. Interacción con Matlab
A pesar de que la plataforma Matlab de Mathworks constituye el medio sobre el que se basa
el código del programa principal EDIMPO, la interacción con la misma de cara a este pro-
yecto se limita al proceso de decisión inicial para afrontar el diseño del programa y a la ela-
boración de una interfaz gráfica con la que el usuario interaccionará con el módulo propues-
to.Matlab se encargará de la tarea de comandar la ejecución del módulo de automatización.

Aun siendo imposible la interacción directa entre el código de Matlab y una aplicación basa-
da en Visual Basic si es posible la iniciación de ejecutables independientemente de la plata-
forma en la que estos fueron diseñados, debido a que el formato de cualquier ejecutable
depende no de la plataforma de diseño sino del sistema operativo, este caso Windows.
La orden de ejecución será impartida por el usuario, que previa introducción de los paráme-
tros de diseño, según la ilustración 10, comandará la activación del módulo al presionar un
botón en la interfaz gráfica. Dicho botón tiene asociada la orden de activar el ejecutable.
Como toda la interfaz gráfica de EDIMPO, aquella asociada al módulo de este proyecto se
basa en las herramientas gráficas del propio Matlab. La elaboración de dicha interfaz gráfica
no se encuentra incluida dentro de los objetivos de este proyecto pero si su diseño.
Ilustración 11: Interfaz módulo.
En la ilustración 11, se muestra la interfaz gráfica planeada para el módulo automático de

generación paramétrica.
Por motivos de optimización en memoria utilizada por el programa se ha optado por la sepa-
ración en la ejecución de árboles motrices y ruedas engranadas. Dado que las ruedas en-
granadas suponen un peso en memoria muy importante se ha optado por separar su gene-
ración de una en una. De esta forma se evita que el ordenador tenga que emplear tiempos
de ejecución innecesarios cuando solo se pretende modificar o generar ciertos modelos y no
todo el conjunto y se evita un posible desbordamiento de la memoria del ordenador.
Cuando el usuario seleccione la pestaña correspondiente a cada grupo de modelos, un des-
plegable aparecerá y pedirá al usuario la introducción de los parámetros necesitados para el
proceso de generación. Existe la posibilidad de indicarle al programa que los nuevos mode-
los sobre-escriban aquellos generados previamente o que sean guardados conjuntamente a
los anteriores, tarea encargada de un botón especifico.

IMPLEMENTACIÓN
En dicha interfaz gráfica se incluye igualmente la opción de visualizar los informes genera-
dos por el programa, para facilitar el proceso de diseño y validación al usuario. Esta capaci-
dad es considerada como prioritaria pues el enfoque del programa ha de ser ante todo mo-
mento de ámbito educativo.
4.4. Nociones previas
En este apartado, se presentarán ciertas nociones importantes relacionadas con el

desarrollo del proyecto, divididas por campos principales de actuación. Algunos de los
problemas encontrados serán explicados y se aportarán posibles soluciones a dichos
problemas, comparando ventajas, desventajas y finalmente que solución se ha elegido para
la resolución de los mismos.
4.4.1. Gestión de datos
La naturaleza del proyecto elegido exige el uso efectivo y ordenado de una gran cantidad de
datos numéricos, que sí no son propiamente gestionados conducirían a un peor
funcionamiento del programa y a una mayor lentitud del mismo.
Como se mencionó anteriormente, la principal dificultad presente ante la interacción entre
plataformas que no fueron diseñadas específicamente para hacerlo, son todo el conjunto de
incompatibilidades que puedan surgir de su interacción. Para el caso que trata este
proyecto, dicha dificultad se traduce en incompatibilidad de lenguajes entre programas. La
plataforma en la que el programa madre se basa y el entorno de modelado 3D no pueden
establecer una comunicación directa entre ellas, haciendo necesario el uso de herramientas
intermedias en el proceso de gestión de datos. Esto es debido a que el código de EDIMPO
funciona en base al lenguaje Matlab y Solid Edge en base Microsoft Visual Basic .NET.
Ambos lenguajes no disponen de herramientas que habiliten su interoperabilidad como si
ocurriría entre códigos en C++ y lenguaje Visual Basic. Programas terceros serán utilizados
para establecer dicho puente de conexión.
Más concretamente dicha tarea la efectuará Microsoft Office Excel. Otro tipo de medios
podrían ser utilizados para resolver esa misma dificultad, pero la extensión y facilidad de
acceso a los productos Microsoft implica que cualquier otra solución no sería óptima. En
todo momento se pretende evitar la necesidad de utilizar programas que no sean de
creación propia cuando se trate de la utilización normal de EDIMPO.
Visual Studio, al ser una plataforma de desarrollo de aplicaciones es capaz de generar un
ejecutable, que siempre y cuando sea distribuido con el código utilizado para su creación, no
necesitará la descarga de la propia plataforma para su utilización una vez distribuido. Por lo
tanto lo mencionado anteriormente no constituye un problema de cara a la futura distribución
del programa.
El módulo de automatización de Solid Edge que buscamos desarrollar recibe toda la
información que el usuario ha generado previamente en la plataforma principal, EDIMPO,
mediante un archivo de datos Excel. El módulo no participará en el proceso inicial de diseño,
siendo simplemente el recipiente de los parámetros calculados por el alumno y por lo tanto
se limitará a actuar como una extensión de la labor realizada por el programa principal.

El archivo de datos no sufre en consecuencia ninguna modificación, salvo aquella que el

propio usuario fuerce durante la utilización de EDIMPO y por lo tanto no entra dentro del
alcance de este proyecto la gestión de esas posibles modificaciones. Se asume de
antemano que el archivo no será modificado por el usuario salvo previa utilización de
EDIMPO.
Debido a que conocemos de antemano que información habremos de necesitar para el

funcionamiento de cada uno de los módulos, en este archivo Excel encontraremos dicha
información con un formato y orden conocido. Este hecho facilita ampliamente el proceso de
recogida de datos, dado que al conocer donde está dicha información almacenada en todo
momento, la obtención de la misma se realiza mediante un simple proceso de lectura,
recogiendo datos celda a celda.
Para cumplir dicho objetivo se diseñó una subrutina capaz de abrir archivos Excel y de
efectuar una lectura de los mismos. Excel presenta la ventaja de que el posicionamiento de
los datos que están almacenados en un archivo de este tipo, es determinado de la misma
forma que estos estarían posicionados en caso de utilizar el programa de forma manual.
Esto significa que Excel trata la información como elementos que rellenan una matriz,
formada por tantas filas y columnas como sean utilizadas por el archivo.
Un aspecto particular de este método de almacenamiento de información es el hecho de que
Excel utiliza además de aquellas celdas que sí que contienen información, una fila y
columna extra para definir la extensión de dicha matriz. Por lo tanto durante la lectura de un
archivo de Excel estas deben ser ignoradas para obtener solo datos significativos. Este
hecho se hace especialmente importante en el proceso de dibujado de la curva evolvente de
los dientes engranados, pues una fila y columna de ceros extra provocará la obtención de
un perfil incorrecto.
El módulo que se pretende diseñar ha se ser capaz de funcionar en la mayor parte de

dispositivos posibles, especificación que hace necesaria la utilización de versiones antiguas
de Excel. Dado que no se puede garantizar que todos los equipos que vayan a hacer uso de
EDIMPO dispongan de la última versión de Microsoft Office, la apertura de los archivos
Excel se realizará en las versiones más antiguas posibles, más concretamente Excel V.7.
Para generar modelos de cierta complejidad como los que se pretenden abarcar en este
proyecto, la cantidad de información a manejar por el módulo, numera en las centenas de
datos, siendo esta asignada a elementos mecánicos bien diferenciados. Por lo tanto la
simple lectura del archivo Excel no constituye una solución adecuada, pues utilizar tanta
información sin conocer exactamente en todo momento que parámetro se está definiendo,
haría el proceso de diseño considerablemente más complicado e inclinado a errores. Es en
ese punto donde las capacidades que brinda Visual Basic cobran especial importancia. La
programación de objetos.
Cada objeto constituye una unidad de información de la que podemos mantener control
absoluto, desde propiedades, capacidades o funciones de las mismas a la relación mutua
que existe entre cada uno de estos objetos. La mejor forma de entender este concepto es la
visualización de algo que se quiera describir, por ejemplo el eje motriz a generar:

IMPLEMENTACIÓN
Ilustración 12: Ejemplo de división por objetos
Dicho eje presenta una serie de características generales tales como sus dimensiones,
posición relativa de los rodamientos respecto a la sección de engrane, radios de acuerdo,
elementos a los que está unido, etc…
Este eje está formado por secciones y cada de estas secciones dispone de elementos
igualmente que las caracterizan. Cada sub-nivel que se pueda establecer constituirá un
elemento que podemos describir y por lo tanto tratar como un objeto completamente
definido. Las relaciones a establecer entre dichos objetos dependen completamente de
cómo se relacionen en la realidad, siendo posible partir de elementos más generales como
sería un animal a elementos más concretos y definidos como sería un perro o bien
elementos que coexistan pero no se relacionen jerárquicamente, como serían los
componentes de un coche.
Cada una de estas características constituye propiedades a definir durante la generación del
modelo y por lo tanto tienen una serie de parámetros asociados, en definitiva datos a
controlar. Aquella información que sea relevante para formación del eje, será
consecuentemente almacenada en el archivo Excel general. Este archivo contendrá
información de naturaleza muy distinta, la cual se organiza con una estructura de datos
completamente paralela a lo observable en la realidad. Los objetos son por lo tanto un lienzo
en blanco sobre el que podremos definir las distintas interacciones posibles entre los datos
que llegaremos a utilizar. En definitiva los datos serán agrupados en unidades fáciles de
comprender para el programador y que permiten conocer en todo momento donde los
parámetros a utilizar se encuentran almacenados. Esto permite tratar la información
relevante para cada uno objetos y la gran cantidad de parámetros asociados como parte de
unidades conocidas.

Estructuración interna de datos
Para averiguar que objetos deberemos de crear basta con dividir la reductora que
procuramos modelar en unidades físicas más básicas. La reductora dispone de tres árboles,
cada árbol dispone de una serie de secciones y finalmente cada sección dispone de una
serie de características propias tales como sus dimensiones o sí presentan chavetas o no.
Cada una de estas divisiones imaginarias constituyen por lo tanto, unidades de información
definibles por si solas. De esta forma se permite el trato de una gran cantidad de datos de
una forma compartimentalizada. En consecuencia una vez analizados bajo que unidades se
pueden agrupar los distintos datos a almacenar se llegó a la siguiente estructura:
Ilustración 13: Esquema de datos.
En la ilustración 12 se puede observar el orden jerárquico y que objetos han sido necesarios
para la completa definición del problema a tratar. Cada sub-apartado de la estructura elegida
recoge toda la información pertinente a la generación del modelo al que está asociado, de
esta forma garantizamos que en todo momento aquellos parámetros constructivos a utilizar
han sido correctamente recogidos y el proceso finalice con un modelo exitosamente
construido.
Generación de objetos
Una vez se ha decidido cuál es la estructura organizativa de datos, el siguiente paso es la

definición de los objetos de programación que usaremos, que expresado en otras palabras
se corresponde con los elementos físicos que deseamos que el programa modele.

IMPLEMENTACIÓN
Para programar dichos objetos se tendrán en cuenta dos detalles:

 No se conoce cuántos de estos objetos serán necesarios de antemano, pues el
usuario será el que tome la decisión final acerca de la construcción del modelo.
 Visual Basic, no conoce este tipo propio de datos y por lo tanto debemos de hacerle
conocer a la plataforma aquello que define este tipo concreto de estructura.
La primera afirmación implica que la cantidad de información que debemos manejar no es

conocida y por lo tanto el código debe de poder adaptarse al aumento o disminución del
número de objetos que debe utilizar. En consecuencia no es posible asignar estos datos a
variables definidas directamente por identificadores, motivo por el cual se eligió el uso de
listas de datos como elemento de recogida de los mismos. La lista tiene la particularidad de
poder almacenar información de tipos datos no preestablecido y cuyo tamaño no ha sido
previamente definido.
Cada nueva interacción añadirá a la lista un elemento, en consecuencia permitiendo a la
estructura interna del programa adaptarse a los posibles cambios que realice el usuario.
Como este programa está destinado a un uso académico concreto, durante la recogida de
datos no permitiremos una extensión del eje engranado de más de 7 secciones cilíndricas.
En cuanto a lo pertinente de la segunda afirmación, dicha realidad se traduce en que el
algoritmo de creación de nuevos objetos, definido en Visual Studio presenta una estructura
de trabajo clara. El algoritmo que permitirá generar cada nuevo objeto a necesidad del
programador, seguirá siempre un esquema concreto. Estas son las llamadas funciones de
construcción.
Dichas funciones son iniciadas cada vez que se exige al programa la creación de un nuevo
objeto y se encargará de rellenar las propiedades de dicho objeto con la información que se
ha decidido transmitirle.
Definición de una clase
Para la creación de los objetos mencionados, primero se inician las llamadas clases, nombre
genérico utilizado por Visual Basic para definir elementos informáticos de diversa naturaleza,
entre los que se encuentra la definición de objetos. El nombre de la misma será el que
determinará la etiqueta de toda variable del tipo asociado a esa clase [10].
Ejemplo:
Public Class Arbol (Cabecera)
…
End Class (Final)
En medio de la apertura y cierre de la clase, se situará toda aquella información que defina
la clase. Se puede dividir dicha información en propiedades, también llamadas campos de
información y las funcionalidades que se desea que esta clase pueda ejecutar.

Ilustración 14: Propiedades de un objeto.
En la ilustración 14 se ofrece un ejemplo de una clase junto a las propiedades utilizadas

para su definición. El programador puede elegir a conveniencia que propiedades son
naturales de la clase bien por definición propia o por herencia. La herencia es un concepto
basado en dar el permiso a un tipo de dato a compartir por lo menos las mismas
propiedades que otra clase.
Esta particularidad hace que Visual Basic sea altamente modular, pues se puede definir una
clase con todas las propiedades que se necesiten, para posteriormente completar otra clase
sin necesidad de volver a definir cada una de estas. Este concepto cobrará especial
importancia en apartados posteriores.
Una vez se ha determinado que propiedades definen una clase, el siguiente paso es la
definición de las ya mencionadas funciones constructoras. Estas son piezas de código
encargadas de crear el objeto cada vez que se realiza un llamamiento al tipo de dato que se
ha definido.
Ilustración 15: Función constructora.
Dicha función se encarga de asignar la información de la llamada a los campos o

propiedades del tipo de dato, aportándole valor a los mismos en consecuencia y generando
una clase todavía sin asociar a ninguna etiqueta con la que esta pueda ser identificada.
De asignar dicha etiqueta se encarga otra función. Aquella será la subrutina a la que el
programa llamará cada vez que un objeto nuevo es definido, incorporando la información
que se le introduce en sus campos y asociándola al objeto que la función constructora ha
creado.

IMPLEMENTACIÓN
Ilustración 16: Diagrama creación objetos.
Mientras que la función constructora realiza la asignación a los campos del tipo de dato, la
función creadora se encarga de pedirle al usuario la información necesaria para definir el
tipo de dato. Dentro de las posibilidades que se encuentran abiertas al programador se
situaría la opción de hacer la asignación a ciertos campos obligatoria u opcional.
Ilustración 17: Función creadora.
En caso de ser opcional, dicha preferencia ha de ser indicada específicamente y se le

asignará un valor provisional, bajo el que trabajará el campo siempre y cuando no se haya
definido un valor específico.
Tipos de datos y parámetros utilizados
Una vez se conoce el proceso de generación de clases y que estructura de datos

considerada como más apropiada. Se pasa al proceso de definición de cada uno de estos
objetos de programación. A continuación se muestra la estructura interna y una breve
explicación de cada uno de estos objetos en la ilustración 18:

Ilustración 18: Objetos y sus parámetros
Colección de árboles:
Este objeto se encarga de guardar todo el conjunto de datos necesarios para la creación de
la reductora, hace de nexo de unión de toda la estructura de datos y constituye el elemento
final a ser transmitido por parte de la función encargada de crear dicha estructura.
Lista de arboles
Colección de árboles
Colección de modelos.
Árbol:
Dentro de árbol se definen aquellos parámetros que establecen las características generales
de la construcción del mismo y recogerá en su interior la lista de secciones que lo forman.
Lista secciones árbol
Árbol Posición Rueda y (o) Piñón
Modelo Árbol
Sección Del Árbol (SeccionDelArbol):

En sección del árbol, se recogerá aquella información que establece las dimensiones de
cada sección individual y de las posibles chavetas que esta contenga.
Radio
Longitud
Sección Árbol
Chavetas (lista)
Radios Acuerdo

IMPLEMENTACIÓN
Chavetas (ShaftKeys):
Parámetros necesarios para definir las dimensiones y tipo de chaveta (Tipo A o B):
Altura
Longitud
Chavetas Profundidad relativa (T1)
Ancho
Tipo
Ilustración 19: Dimensiones chavetas.
Engranaje:
En este objeto se almacenan todos aquellos parámetros constructivos de un engranaje. La
información aquí contenida será utilizada durante el dibujado de la curva evolvente de cada
diente.
Radio de cabeza. (Ra)

Radio de pie. (Rf)
Diámetro primitivo. (D)
Radio base. (Rb)
Módulo normal (mn)
Paso hélice. (p)
Engranaje
Número de dientes. (Z)
Ángulo de presión. (αn)
Ángulo de inclinación diente. (β)
Ancho rueda. (b)
Radio Interno Rueda.
Orientación hélice. (derechas o izquierdas)

Recogida y lectura de datos
La información que el programa ha de utilizar provendrá de dos archivos Excel distintos, uno
encargado de la recogida de toda la información con la que el usuario interactúa dentro de
EDIMPO, común por lo tanto para todo el programa y cada uno de sus módulos y otro
encargado de la generación de los parámetros constructivos de los dientes engranados.
Para poder efectuar dicho intercambio de datos se han elaborado numerosas subrutinas,
limitando la interacción con el archivo general a su lectura. Mientras que el archivo
pertinente a los dientes de engrane obtendrá la información gracias a la introducción de
nuevos parámetros elegidos por el usuario, destinados a la formación de la evolvente del
diente.
El archivo de datos común de todo EDIMPO presenta una estructura tal que divide por
modelo, todos los posibles parámetros que intervengan en la construcción del mismo,
separando datos de Árboles, Piñones y Ruedas engranadas. El proceso de lectura se limita
a la recopilación de datos parámetro a parámetro y su posterior asociación a los objetos
creados anteriormente.
Debido a las importantes particularidades del proceso de obtención de engranajes se ofrece
una explicación del algoritmo seguido. Para la estimación de las curvas evolventes del
engranaje, se hizo uso de un archivo de Excel utilizado por los alumnos de la asignatura de
Diseño de Maquinas I. Este archivo mediante los parámetros básicos de diseño de un
engranaje, calcula los puntos en coordenadas del plano XY, que definirán la curva
evolvente.
El proceso de cálculo es el siguiente:

1. El usuario introduce dentro del archivo los valores de módulo normal (mn), ángulo
inclinación (β), nº de dientes (Z), ángulo de presión (αn) y factor de desplazamiento
δx.
2. El archivo Excel calcula el valor de la curva evolvente y de las circunferencias
propias del elemento de engrane utilizando los parámetros introducidos.
3. A continuación elabora un gráfico que representa los valores obtenidos y la subrutina
asigna los valores contenidos en las celdas del archivo a los parámetros
correspondientes, previamente no definidos.
4. Finalmente el archivo es guardado y cerrado.
Este proceso de entrada y salida de datos se realiza por cada elemento engranado que vaya
a ser construido. En la siguiente imagen se adjunta un ejemplo de la gráfica obtenida
durante el cálculo de la curva evolvente. Dicho gráfico se genera internamente en el archivo
Excel para mostrar las posiciones relativas de las curvas principales del engranaje.

IMPLEMENTACIÓN
Ilustración 20: Curva Evolvente y circunferencias de engrane.
Bases teóricas y Procesos de cálculo
Previa explicación del proceso seguido en el interior del mencionado archivo Excel se aporta
una descripción breve de los principios básicos entorno a los cuales se elabora el diseño de
una rueda engranada.
En la ilustración 21, se representa el perfil de contacto entre dos piezas de engrane. En él se
pueden observar los radios de cabeza, primitivos y de base de cada una de las piezas
engranadas.
Todo conjunto engranado efectúa idealmente su conexión en el llamado diámetro primitivo.
La conexión que realizan las ruedas dentadas depende en su mayor medida del ángulo de
presión (αn). Este equivale al ángulo entre la dirección de la fuerza de contacto (normal
común en el caso sin rozamiento) y la dirección de la velocidad en el sólido conducido. Este
parámetro en el tipo de engranajes tratados (cilíndrico helicoidal o recto) se mantiene
constante para toda la circunferencia de engrane.
Como no siempre se puede garantizar que el proceso de mecanizado de los engranajes sea
el correcto, a veces es necesario incluir un factor que tenga en cuenta esta desviación.
Dicha labor es realizada por el factor de desplazamiento (δx), el cual modificará parámetros
fundamentales tales como los radios de cabeza o de pie, número ideal de dientes para
efectuar la conexión pero más importantemente modificará las tensiones sufridas por el
diente.
En azul se representa la llamada línea de engrane, lugar geométrico de los puntos del plano
que coincide en cada instante con el punto de conexión entre ambos engranajes. El diente
ha de seguir dicha línea de engrane en todo momento, siendo el punto de conexión del
mismo con su homólogo, variable en posición. El seguimiento de esa serie de puntos
constituye el llamado perfil evolvente del diente y es en definitiva la forma que debe de tener
el perfil en caso de haber sido perfecta la conexión. Un ejemplo de involuta o evolvente
puede ser observado en la ilustración 20.

El ángulo de presión determinará por lo tanto cual será la línea de engrane y en definitiva
cual será la forma ideal del perfil de diente.
Ilustración 21: Perfil de engrane.
Ahora bien dicho ángulo de presión no se corresponde con el ángulo real que percibe el
diente en caso de ser la conexión oblicua (β ≠ 0), por lo tanto este ha de ser corregido. Se
puede afirmar lo mismo para el ángulo β, de inclinación.
cos( β) (1)
αt = arccos(cos(αn) · )
cos( βb )
βb = arcsen(cos(αn) · sen( β )) (2)

IMPLEMENTACIÓN
Una vez obtenidos estos dos parámetros el proceso de cálculo interno del archivo pasa por
la determinación de las circunferencias del engranaje. Usualmente el proceso de diseño de
engranajes, dependerá de aquella potencia o velocidad que se quiera transmitir a través de
estos elementos y de las condiciones de trabajo bajo las cuales el conjunto creado trabajará.
Con la especificación de estas variables, se determina en consecuencia que tren de
engranajes será el necesario y por lo tanto que relaciones de transmisión se utilizarán y los
parámetros de contacto del conjunto.
Mediante las ecuaciones (3-6) se realiza el cálculo de las circunferencias principales del
engranaje. Siendo almacenados los valores obtenidos en el archivo.
D = (mn · Z)/cosβ (1)
Rb = (D · cos(αt))/2 (4)
Ra = Rb + (1 + δx) · mn (5)
Rf = Rb − (1.25 − δx) · αt (6)
El siguiente y último paso se corresponde con la determinación de la curva evolvente. Para

la construcción de la curva mencionada, se utiliza una batería de valores angulares [0º, 90º]
con los cuales se calculan las coordenadas de la curva en el plano XY.
Angulo para el intervalo = Φ
X = Rb · [ cos(Φ) + Φ · sen(Φ) ] (7)
Y = Rb · [ sen(Φ) – Φ · cos(Φ) ] (8)
Una vez obtenidas dichas coordenadas, estas son almacenadas y el archivo es cerrado y
guardado.

4.4.2. Tecnología VB.NET
Visual Basic. Net constituye una adaptación del antiguo lenguaje Visual Basic a la tecnología
framerwork.Net. La tecnología framework.Net fue la respuesta que desarrolló Microsoft al
creciente mundo de desarrollo de aplicaciones Web tales como Java, es el llamado Visual
Studio. Constituye un componente adherible al sistema operativo Windows y ofrece una
gama amplia de soluciones predefinidas junto con un medio de verificación y desarrollo de
ejecutables altamente completo. Dicha tecnología, utiliza un lenguaje de programación
nuevo, no-retro compatible con versiones anteriores de Visual Basic. Todo programa que
hiciese uso de la versión 2006 de Visual Basic, no puede ser ejecutado dentro del entorno
de Visual Studio.
Visual Studio es en esencia una herramienta de desarrollo de aplicaciones. Las principales
fortalezas de este son el uso de un lenguaje de programación común (CLP) y la posibilidad
de crear una biblioteca de clases, concepto explicado en el apartado anterior.
La inclusión del llamado lenguaje común o CLP es el factor principal de diferenciación que
aporta Visual Studio respecto otros entornos de desarrollo de aplicaciones. Este lenguaje
aporta la posibilidad de coordinar numerosos lenguajes de programación distintos, sea
Python, C++ o VB entre otros, de forma simultánea. Dicho hecho permite que aplicaciones
que hayan sido programadas en lenguajes distintos, pero soportados, pueden interactuar a
nivel de código y no limitándose al tipo de archivo, como ocurre con Matlab y Solid Edge. El
uso de CLP solo es posible gracias a la inclusión dentro de Visual Studio de los llamados
paquetes de interoperabilidad.
Interoperabilidad entre librerías de funciones
Dado que el programa que se pretende diseñar es de distribución pública, todas las librerías
que son utilizadas por el mismo deben de ser incluidas en los archivos del programa durante
la descarga. La determinación de que librerías se incluyen durante la elaboración del código
y para su posterior distribución depende principalmente de dos factores:
 Criterios de compatibilidad interna con la aplicación.
 Criterios de distribución del código.
El primer criterio se corresponde con la capacidad de una pieza de código a ser ejecutada
dentro de un entorno concreto. Este entorno es determinado por el tipo de aplicación que se
vaya a generar. Cada tipo de aplicación funciona en torno a una serie de reglas internas,
encargadas de determinar la lógica de la misma. Ciertas librerías no son compatibles con la
lógica interna del programa y por lo tanto no pueden ser incluidas en el. Visual Studio se
encarga automáticamente de la realización de dicha gestión, impidiendo la inclusión de
librerías no correspondientes al tipo de aplicación que se esté programando.
La determinación de que librería de funciones o clases es adecuada o no se realiza
mediante los tipos de interoperabilidad. Este concepto puede ser simplificado a la capacidad
o no por parte de una función de operar en distintos modos de funcionamiento, en definitiva
la lista de tipos de aplicación en las que la lógica interna es compatible. Aplicaciones de
consola o archivos diseñados para páginas Web no siguen la misma lógica y por lo tanto
necesitan de un medio que permita su adaptación.

IMPLEMENTACIÓN
Los paquetes de interoperabilidad permiten el establecimiento de dichas vías de conexión

lógica, no solo extendiéndose a tipos aplicación sino también al lenguaje utilizado por las
mismas.
De forma predeterminada Visual Studio dispone de la capacidad de adjuntar paquetes
encargados de habilitar dichas interacciones con una mera descarga. Estos paquetes sin
embargo solo funcionan como vía de conexión mientras, se disponga en el propio equipo de
dichos paquetes. Es en este punto donde cobra importancia el segundo criterio.
No todos los desarrolladores de Software permiten la libre distribución de su trabajo y o bien
no se permite directamente la inclusión en código ajeno o es necesario la obtención de
permisos. Por lo tanto la inclusión de dichos paquetes no siempre es una opción. El no
incluirlos implicaría que el programa funcionaría solo en equipos que tengan Visual Basic
instalado y actualizado con los paquetes que hacen posible esa adaptación lógica.
La forma de sortear esta complicación es la utilización de solo librerías que se conozca de
antemano que vayan a funcionar en el entorno concreto para el que se diseña el programa y
que no necesiten de paquetes de interoperabilidad. Esto se consigue bien estudiando una a
una si estas son válidas para la tarea concreta o permitiendo la descarga de la librería como
parte de los archivos a distribuir con el programa. En caso de que haya alguna
incompatibilidad, la propia plataforma informará de ello para que se hagan las correcciones
necesarias.
El caso concreto de este proyecto, carece de estas complicaciones pues todas las librerías
utilizadas han sido diseñadas para su trabajo conjunto, tales como la capacidad interna de
Solid Edge de procesar archivos de Microsoft Office.
Al utilizar propiedad intelectual de terceros desarrolladores cualquier pieza de código que no
sea propio debe ser adecuadamente atribuido a su propietario. Es fundamental garantizar
que no se produzcan ninguna de las incompatibilidades mencionadas previo diseño del
algoritmo de trabajo. De lo contrario todo el trabajo que se realice puede fallar en la fase de
verificación final, impidiendo por lo tanto el objetivo final que se persigue, la distribución del
programa.
Definición de librerías.
Mediante librerías todo desarrollador puede crear una serie de funcionalidades que puedan
ser posteriormente compartidas con otros desarrolladores o con nuevos programas de
diseño propio. El objetivo de las mismas es facilitar el proceso de desarrollo, eliminado la
necesidad de que cada vez que se creé algo nuevo sea necesario rehacer el trabajo previo y
reestablecer las bases de funcionamiento en cada proyecto.
De cara a este proyecto y al módulo de análisis procedural de elementos finitos, la
elaboración de librerías permite la agrupación sencilla de las rutinas creadas por campos,
diferenciando claramente unos de otros. En definitiva constituyen un sistema de
organización interno.
El proceso de elaboración de una librería es el siguiente:
I. Se desarrollan las funciones que vayan a constituir la librería.
II. Estas son agrupadas en los llamados NameSpace [11] o espacios de nombre.
III. Son compiladas seleccionando la opción de elaborar librería en Visual Studio.

La función que cumplen los espacios de nombre es la de aportar a un código constituido por
muchas subunidades de una etiqueta común entorno a la cual ser agrupados. En el caso de
querer agrupar todas las funciones de un tipo, basta con definir un espacio de nombres,
incluir las funciones deseadas y otorgarle una etiqueta.
La definición de funciones puede ser controlada de forma que estas solo sean capaces de
trabajar en entornos concretos. Dicha definición del medio de trabajo se realiza mediante las
etiquetas de Privado o Público.
Visual Studio internamente organiza la información de forma que si el desarrollador le indica
que una pieza de código no debe de ser compartida entre partes del programa, entonces
esa información aunque sea accesible para ejecutar, no lo sea para modificar. Es en
definitiva el permiso de solo lectura o escritura y lectura. Dicha diferenciación existe con el
motivo de impedir que ciertas propiedades de especial importancia sean modificadas
accidentalmente sin el control del desarrollador. Los motivos pueden ser varios pero
normalmente se deben a motivos de seguridad y motivos prácticos, tales como garantizar un
buen funcionamiento del programa. En el caso de querer construir una librería este hecho es
de especial importancia.
Como se ha indicado, no todo código tiene que surgir del mismo desarrollador. En caso de
necesitar de funcionalidades más básicas que las que se pretendan construir, basta con
incluir esas mismas importándolas. Es aquí donde se revela la especial importancia de las
librerías en proceso de desarrollo. En el caso concreto de este proyecto, dado que se ha de
trabajar con una aplicación previamente construida, estas librerías han de ser importadas a
cada parte del código donde vayan a ser utilizadas, pues la inclusión de librerías en un
proyecto no implica que estas estén disponibles para su uso. Solo con la importación de las
librerías se activan los mecanismos internos que permiten su interpretación y llamada.
Otro aspecto importante en el proceso de creación de librerías es el concepto de herencia
explicado en apartados anteriores. Toda clase dispone de propiedades y funcionalidades,
pero estas se limitan a la propia clase a la que están asociadas. Si se desea que otra clase
disponga de las mismas propiedades y funcionalidades, es necesario indicarlo mediante la
sentencia inherits.
Con inherits se establece una conexión entre clases, permitiendo la herencia de toda
propiedad o función que defina la clase que se herede. De esta forma se puede separar
etiqueta a utilizar para nombrar un grupo de funciones del nombre de la clase con la que
esta ha sido definida y se evita la repetición de trabajo. Efectivamente separando las clases
en las que han sido definidas las funciones de las clases utilizadas para nombrar los grupos
de estas mismas.
Namespace Functions
Public Class FuncionesCreacionModelo

Inherits CreacionModelos
End Class
Public Class FuncionesInteraccionSolidEdge
Inherits InteraccionSolidEdge
End Class
Public Class FuncionesInteraccionArchivos
Inherits InteraccionArchivos
End Class
Public Class FuncionObjetosCOM

Inherits InteraccionObjetosCOM
End Class
End Namespace

IMPLEMENTACIÓN
En la pieza de código superior se indica cual es la estructura utilizada para la agrupación de

las funciones creadas. De esta misma solo surgirá una única librería, cuyo nombre será
Functions.dll, pero que contendrá funciones de distinto ámbito, permitiendo seleccionar cada
función según la etiqueta que defina el campo sobre la que esta actué. La explicación de
estos campos será realizada en el apartado 5.
4.4.3. Secuencia de trabajo con Solid Edge.
El proceso de formación de modelos en cualquier plataforma de diseño por ordenador se

basa en la ejecución de operaciones repetitivas de arranque y adición de material. Este
proceso realizado de forma manual parte de la creación de unos perfiles que definen las
formas básicas de los modelos. Cuando la interacción con la plataforma de modelado se
realiza de forma automática, ese mismo proceso es realizado mediante líneas de código
siguiendo por lo general el mismo orden de ejecución que se realizaría de forma manual,
esto sin embargo no ocurre en todos los casos, consideración importante en futuros
apartados.
Proceso de creación de modelos:
Para iniciar el modelado de una pieza se debe previamente abrir Solid Edge y el documento
a utilizar. La realización de esta tarea sigue el esquema organizativo indicado en el apartado
4.4.2. Una vez dispuesta la estructura de apoyo, se inicia la secuencia de dibujado,
partiendo esta de un esquema fijo:
 Se selecciona un plano de trabajo.
 Se define un perfil sobre dicho plano.
 Se extruye el perfil, obteniendo en el proceso un volumen con el que trabajar.
Toda operación consiguiente, partirá del trabajo realizado en esta fase inicial. Como ya se
ha mencionado previamente, Solid Edge trabaja con varios tipos de documentos, cada uno
de ellos destinados a una fase concreta del diseño en 3D por ordenador. Bien sea la
definición de una pieza (.par), la creación de un conjunto (.asm) o la elaboración de planos.
Dependiendo de la complejidad del modelo a generar se irán acumulando operaciones
sobre el volumen inicial generado.
Este proyecto apunta a generar dos tipos concretos de modelos, arboles motrices por un
lado y por otro las ruedas engranadas que serán conectadas a los mismos. Se hace inciso
en el hecho de que la extensión del proyecto se limita a la generación de la forma básica del
árbol, sin añadir a esta el talle de los piñones, que servirían de elementos conectores con
las ruedas engranadas. El motivo por el cual se hace esta excepción será explicado en
futuros apartados en detalle.
Para poder entender de forma efectiva el algoritmo de creación de los modelos que este
proyecto pretende generar es necesario contemplar las bases de generación de modelos en
Solid Edge. Como ha sido mencionado el proceso de generación de modelos parte de la
previa selección del plano sobre el que se trabajará.
Solid Edge dispone de una serie de planos preestablecidos, asociados al sistema
coordenado predeterminado por el programa, tales como los planos ortogonales XY, XZ, YZ
del sistema cartesiano.

A falta de determinar un nuevo plano o sistemas coordenadas, se partirá de cualquiera de

estos. La selección de los mismos, se realiza estableciendo una referencia al conjunto de
planos predeterminados, seleccionando el deseado mediante la posición que este ocupa en
la lista. El orden en que son guardados no es indicado sin embargo en ninguna de la
documentación aportada por Siemens. El plano una vez definido sirve de base de dibujo del
perfil a utilizar.
Al igual que con cualquier tipo de unidad de modelado que Solid Edge maneja, los distintos
perfiles se almacenan en colecciones o listas. Estas contienen todo el conjunto de perfiles
que se han definido durante la utilización del documento en orden de adición.
Ahora bien la estructura utilizada por Solid Edge en el caso concreto de los perfiles difiere
del resto de elementos propios del documento en la mayor complejidad de la misma. No
disimilar a la estructura de un árbol, existe un elemento común o lista general (ProfileSets)
encargada de guardar otras listas de listas (ProfileSet), actuando estas como las ramas
principales de dicho árbol. Cada una de estas ramas se divide igualmente en otras sub-
ramas (Profiles) las cuales tendrán asociadas un número potencialmente infinito de perfiles
(Profile). Para mayor clarificación se presenta a continuación el siguiente esquema
organizativo:
Ilustración 22: Estructura interna de perfiles en un documento.
Solid Edge utiliza esta estructura particular debido a la versatilidad que esta aporta. Al poder
agrupar los perfiles utilizados en tantas listas de objetos se da la posibilidad de trabajar de
una forma compartimentalizada, diferenciando fácilmente entre aquellos perfiles utilizados
para cada tipo de operación y aportando al usuario una herramienta que le permite tratar los
objetos implicados por conjuntos significativos. De esta forma el proceso de construcción de
modelos muy complejos puede ser organizado de una forma más intuitiva.
Tanto los ejes motrices como las ruedas engranadas carecen de la complejidad necesaria
para justificar la utilización de una estructura tan compleja, resultando más simple la
asociación de todos los perfiles a una única colección. Sin embargo la comprensión de este
esquema es fundamental para evitar errores durante la escritura del código.
Los perfiles participan de otra particularidad a diferencia del resto de elementos de dibujado.
Un perfil bien puede ser definido para un exclusivamente local o bien pueden estar
asociados a bocetos (skectches).

IMPLEMENTACIÓN
El boceto es aquel objeto que el usuario utiliza para la acumulación de todos los elementos
de dibujo que constituyen un perfil. Al realizar una operación manualmente, siempre se
generan perfiles asociados a bocetos. Internamente estos funcionan en cierto modo como si
de un tipo de documento especial se tratasen, siendo su definición común a todos los tipos
de documentos que utiliza Solid Edge y teniendo estos un menú contextual propio. El hecho
de que un perfil sea asociado o no a un boceto implica un cambio interno de funcionamiento,
permitiendo la realización de ciertas operaciones y el bloqueo de otras. Esta particularidad
se revelará especialmente importante en las operaciones de modificación de volumen.
Librerías Solid Edge:
Previo paso a la elaboración de código, es necesario entender la estructura interna con la

que Solid Edge organiza todas sus funcionalidades. Como se ha indicado, esta organización
interna es controlada mediante librerías.
Solid Edge maneja dos tipos principales de librerías, por un lado las llamadas librerías de
utilidad (3 primeras en la tabla) y por otro las librería nucleares del programa. Ambos tipos
de librerías atienden aspectos completamente distintos. La explicación de cuáles son los
usos de las mismas se realiza en la tabla siguiente.
Para el proyecto afrontado las librerías de utilidad no han sido necesarias pero sí que es
importante conocer el motivo de su existencia. Con ellas el usuario puede controlar aspectos
fundamentales del funcionamiento de Solid Edge sin necesidad de automatizar el mismo o si
quiera tener que abrir el programa.
Librería Descripción
Manejo de propiedades de archivos.
{ } Revision Manager Manejo de información de conexiones entre datos.
Integración con Insight.
{ } SEInstallDataLib Información de la instalación de Solid Edge
Leer y escribir sobre las propiedades de archivos fuera de
{ } SolidEdgeFileProperties
Solid Edge.
Base de datos de enumeraciones
{ } SolidEdgeConstants (constantes que controlan el funcionamiento de ciertas
rutinas)
{ } SolidEdgeDraft Administra la creación de planos.
Librería principal de Solid Edge, base de todas las
{ } SolidEdgeFramework
funcionalidades básicas.
{ } SolidEdgeAssembly Controla documentos de conjunto.
Control de todas las interfaces comunes, no especificas a
{ } SolidEdgeFrameworkSupport
un entorno concreto.
{ } SolidEdgeGeometry Administra la geometría de los modelos y conjuntos.
Control de documentos de pieza.
{ } SolidEdgePart Control de documentos de placa metálica.
Control de documentos de soldaduras.
En color azul claro se indican las que se constituyen como librerías principales de Solid
Edge, el núcleo del programa. Estas serán entorno a las cuales cualquier proceso de
automatización va a revolver.

Como mínimo para poder interactuar con Solid Edge se debe hacer referencia a la librería
de SolidEdgeFramework, pues esta controla la administración de todos los entornos de
desarrollo de Solid Edge, procesos principales de la aplicación y procesos generales de
cada entorno. Constituye en definitiva el núcleo principal de Solid Edge del cual se desligan
las distintas ramas de funcionamiento del mismo.
Ciertas operaciones que son de uso común a cada entorno serán controladas con su
homóloga en SolidEdgeFrameworkSupport, tal sería el caso de elementos de dibujo,
bocetos, variables, dimensiones, restricciones y demás utilidades que pueden ser utilizadas
en todo documento.
En tono más específico las librerías a utilizar principales serán SolidEdgePart se encarga del
manejo de documentos de pieza y sus elementos constitutivos, como ejes coordenados,
planos, ejes de referencia, perfiles, etc. Esta constituye la librería con la que este proyecto
interactuará más.
Otra serie de librerías tales como SolidEdgeGeometry serán utilizadas en menor medida
para tareas específicas. Dado que la estructura interna de datos que Solid Edge utiliza es
muy compleja, para comprender plenamente esta misma se aporta en anexos un gráfico que
recoge los aspectos principales de la misma (Ver Anexos).
Elementos de dibujo:
Estos constituyen la base con la que todo perfil y boceto será realizado. Un elemento de
dibujo es en definitiva un tipo de dato interno al que Solid Edge asigna unas dimensiones y
normas internas de funcionamiento. Pueden ser de 2 o 3 dimensiones y dependiendo de
esto la relación que tendrán con el resto del documento será distinta, siendo posibles
operaciones únicas para cada tipo y cambiando las relaciones de funcionamiento en base a
las cuales estos elementos trabajan. En este proyecto no ha sido necesario sin embargo la
utilización de elementos de dibujo 3D.
Los elementos de dibujo, al igual que el resto de tipos de datos que Solid Edge maneja, son
almacenados en colecciones, encargadas de agrupar todos los elementos del mismo tipo de
dato. Las interacciones cono estos objetos se realizan estableciendo referencias a los
elementos de la lista que sean necesarios. En caso de querer añadir nuevos elementos
cada uno de ellos dispone de una o varias funciones encargadas de crearlos, en definitiva
de funciones constructoras.
En el caso de elementos en 2D a partir de la definición del plano de trabajo se puede iniciar
el algoritmo de dibujado haciendo referencia al plano deseado. Las funciones constructoras
generan los elementos de dibujo mediante los parámetros que se le aporten. Manualmente
este proceso se realiza mediante la selección de puntos característicos o mediante
parámetros tales como longitudes o ángulos. Internamente Solid Edge traduce dicha
información y la adapta al formato utilizado por las funciones creadoras.
Siguiendo el algoritmo que se determine adecuado el perfil deseado es terminado y
guardado. El proceso de cierre de un perfil sin embargo no se limita a la simple conexión de
líneas, pues este ha de ser validado. Este proceso es de extrema importancia pues es solo a
través de la confirmación de este estado, que Solid Edge puede interpretar que toda
operación en la que el perfil intervenga pueda llegar a ser exitosa. De lo contrario Solid Edge
no garantiza que no puedan aparecer internos.

IMPLEMENTACIÓN
Para validar un perfil es necesario asignar los llamados Keypoints [12] a las esquinas del
mismo. Estos puntos clave son los encargados de efectuar la conexión lógica entre
elementos de dibujo, de forma que puedan ser tratados como extensión los unos de los
otros. La asignación de los puntos clave ha de ser realizado elemento a elemento y en un
orden concreto, dependiente del orden constructivo del perfil. Solo si esta asignación ha sido
realizada correctamente, el perfil podrá ser dado como válido. Este proceso aun siendo
ejecutado sin intervención del usuario durante la utilización manual de Solid Edge, no lo es
en cambio cuando se busca la automatización del mismo mediante código.
Es importante tener en cuenta que la restricción aportada por dichos puntos clave es
considerada como prioritaria a todo el resto de restricciones que puedan ser aportadas a los
mismos. Las dimensiones por ejemplo serán subordinadas a los puntos clave, salvo que se
indique una excepción a esta regla mediante código. Esto implica a efectos prácticos que si
se produce algún equivoco durante la asignación de los mismos, la forma del perfil que
surgirá bien será completamente distinta a la que se buscaba crear o simplemente dará
lugar a formas con errores internos. Es por ello que se ha hecho hincapié en la necesidad de
seguir un orden de asignación concreto. Una vez validado el perfil este podrá ser utilizado
en operaciones posteriores.
Unidades internas vs unidades deseadas por el usuario:
El manejo de las unidades de trabajo constituye una de las limitaciones más importantes a
tener en cuenta durante la generación automática de modelos.
Solid Edge tiene como particularidad el hecho de que las unidades que son aportadas al
usuario son distintas a las que el propio programa utiliza. En cierto modo Solid Edge no
entiende de unidades, sino de valores numéricos que disponen de una serie de etiquetas
asignadas, cuyo uso es meramente estético.
En definitiva, Solid Edge diferencia entre unidades internas y externas, existiendo la
posibilidad de modificar las segundas pero no las primeras. El motivo por el cual Solid Edge
trabaja de esta forma es que muchas veces los usuarios utilizaran sistemas de medida
distintos y las etiquetas asociadas a los mismos, llevan como parte de su definición unas
reglas de conversión interna. Como sistema predefinido, Solid Edge, utiliza valores
asociados al Sistema Internacional, haciendo ciertas excepciones tales como el uso de
milímetros en vez de metros.
Dado que el usuario ha de tener la posibilidad de interactuar con el modelo a posteriori de la
generación del mismo las unidades que este va a percibir han de ser igualmente las
correctas, pues de lo contrario el módulo dejaría de ser intuitivo. Este hecho hace necesaria
la aclaración previo uso del programa de que unidades son las correctas.
Dimensiones, variables y relaciones geométricas:
Mediante el uso de variables, Solid Edge permite la modificación de modelos de una forma
significativa con el simple cambio de valores numéricos. Este hecho es especialmente útil
durante la automatización del programa, pues liga cambios de la geometría del modelo a
variables en vez de ser necesario actuar elemento a elemento.

El proceso usual de generación de modelos de forma manual pasa primero por la

elaboración de los perfiles que definirán las formas básicas del mismo, con sus
correspondientes cotas geométricas y las posteriores operaciones que vayan a ser
realizadas sobre el material base.
Todo este conjunto de cotas, constituyen internamente una lista de restricciones de tamaño
y ángulos, orientación y en general geometría del modelo. Con ellas se define unívocamente
que dimensión ha de tener el mismo en cada de una sus partes constituyentes. Esto implica
que cualquier cambio efectuado a las mismas igualmente se verá reflejado en la geometría
del sólido.
Los tipos de dimensiones que Solid Edge maneja internamente son tres:
 Dimensiones lineales
 Dimensiones radiales
 Dimensiones angulares.
Dichas dimensiones manualmente son establecidas mediante la selección interactiva de

aquellos elementos entre los que se pretenda acotar. Esta tarea elaborada automáticamente
difiere en el hecho de no pueden ser establecidas sin haber dispuesto previamente
restricciones de tipo Keypoint.
Todas y cada de una de las dimensiones asociadas a un modelo pasan automáticamente a
estar contenidas dentro de lo que se llama tabla de variables. Las dimensiones como tales
no constituyen variables perse, pero sí que pueden administradas como si tales fueran.
Estas serán agrupadas junto a las variables por lo tanto en la tabla de variables.
Una variable constituye una característica encargada de controlar un determinado aspecto
del modelo. Como ejemplo claro de esto mismo, es mediante variables que propiedades
tales como la densidad, masa, rigidez y otro tipo de parámetros físicos que Solid Edge
puede utilizar en sus simulaciones.
En definitiva, constituyen una herramienta con la que se puede modificar remotamente
geometría y propiedades del modelo. Dicha capacidad será utilizada ampliamente durante el
algoritmo de creación de ruedas engranadas.

IMPLEMENTACIÓN
4.4.4. Principios del modelado de ejes motrices:
Ilustración 23: Ejemplo Eje producido por programa.
Un eje motriz es un elemento mecánico constituido por un número variable de secciones

sobre las que irán talladas o montadas elementos de tales como ruedas de engrane
mecánico o rodamientos.
Cada sección sufrirá debido a las condiciones de uso distintos esfuerzos y en consecuencia
las exigencias a cumplir por cada sección son variables. Para poder garantizar que los
diseños producidos cumplen dichas exigencias, pruebas tales como el análisis por
elementos finitos se aplican a su geometría. El estudio de cada sección puede llegar a
realizarse por separado, siendo sin embargo los resultados obtenidos por dicha
simplificación no ideales. Para poder garantizar que el análisis realizado por elementos
finitos no disponga de discontinuidades y por lo tanto zonas peligrosas por falta de
aproximación a la realidad, el modelo a generar ha de ser generado como una única pieza.
Esta exigencia descarta la posibilidad de construir el modelo mediante la unión de distintos
sub-modelos, formados por tantas secciones cilíndricas como sea necesario. La generación
del modelo por lo tanto ha de provenir de operaciones de sustracción de material, partiendo
de una forma base. En este caso cilíndrica de revolución.
Como el modelo ha de aproximarse lo máximo posible a un diseño real las uniones entre
secciones han de disponer siempre que sea necesario de radios de acuerdo, limitando de
esta forma la acumulación de tensiones producida en cambios de sección y en
consecuencia reduciendo las posibilidades de rotura.
Igualmente importante de cara al análisis del comportamiento del eje como lo son los
cambios de sección, se sitúan las zonas de unión. Para poder garantizar la mejor
aproximación posible a lo que constituiría un diseño real, se da la posibilidad de realizar la
unión entre rueda engranada y eje mediante chavetas. Dichas chavetas son esculpidas una
vez el modelo de revolución ya haya sido formado.
Como ya ha sido explicado, las operaciones de trabajo sobre el material de la pieza precisan
por lo general de la utilización de perfiles sobre los que apoyar dichas mismas operaciones.
En el caso de la creación de las chavetas, dichos perfiles han de ser dibujados sobre planos
que no han sido definidos previamente. Por lo tanto es necesario definir manualmente los
mismos.

Como es sabida la posición de la chaveta en el eje, al haber sido esta especificada por el
usuario en EDIMPO, la determinación del plano a utilizar pasa por la identificación de
aquella cara o superficie sobre la que el plano ha de apoyarse. Al tratarse de superficies
cilíndricas, el plano ha de ser tangencial a la misma en un punto.
Solid Edge administra todos los elementos generados de una forma progresiva según estos
van siendo creados y almacena cada elemento en listas del mismo tipo. Se supone que
como se conoce el número de superficies que contendrá el modelo del eje, se puede
determinar fácilmente donde se situara en la lista de objetos la cara deseada.
La determinación de la misma pasa por primero garantizar que la superficie sea del tipo
buscado (cara lateral, cilíndrica, cónica, etc…), en caso de no corresponder al tipo de
elemento geométrico necesario las operaciones pueden dar lugar a error. Por lo tanto al
igual que con la definición de perfiles, para poder garantizar la correcta operación con las
mismas, se ha de verificar que los elementos que se están tratando son los elementos sobre
los que se interactuará.
Esta obviedad, no lo es tanto para el propio Solid Edge, pues aquello que al ojo humano es
una superficie, salvo determinación específica, Solid Edge no es capaz de realizar dicha
clasificación y a veces almacenará elementos que no corresponden dentro de dichas listas.
De ahí la importancia de dicha verificación.
Es de especial importancia un error particular que Solid Edge presenta cuando se trabaja
con superficies de forma codificada. En ocasiones el propio programa genera superficies y
bordes que no son visualizables en el modelo y que aparentemente no deberían de existir.
Este error se debe probablemente a la existencia de superficie infinitesimales que bien si no
son visualizables sí que entorpecen enormemente el proceso de determinación de
superficies concretas. Al incluirse dichas superficies de área nula en las listas de elementos,
aquello que podía ser determinado por simple algoritmo, hace necesaria la identificación de
las superficies mediante etiquetas. Dichas etiquetas son los números de identificación que
Solid Edge asigna a cada elemento interno del documento.

IMPLEMENTACIÓN
4.4.5. Principios de Modelado de engranajes
Ilustración 24: Ejemplo Rueda generada por programa.
La complejidad que presenta la creación de las ruedas engranadas implica que para poder
afrontar la creación de los modelos, será necesario partir de una base con la que poder
trabajar. Para poder definir la forma de un de diente engranado, se necesita determinar
primeramente la curva evolvente.
Dibujado de la evolvente para los engranajes:
Cuando se desea construir un sistema engranado, debemos a posteriori de haber elegido

los parámetros a utilizar, tales como el paso, número de dientes o ángulo de cabeza, la
trayectoria a seguir por parte de los dientes ha de ser definida. Esta es dependiente de los
parámetros mencionados y constituye una representación de la curva que seguirán los
dientes engranados al estar conectadas ambas parejas de ruedas. Constituye en definitiva
el propio perfil que define la forma externa del diente engranado.
Dado que se busca la elaboración de los modelados 3D con una cierta precisión es
inevitable la construcción de dicho perfil, evitando el uso de aproximaciones. Para afrontar la
tarea de su dibujado surgen varias alternativas, de entre las cuales son destacables dos:
 Dibujado de la curva aprovechando una función propia de Solid Edge que lee
directamente de un archivo Excel una lista de coordenadas cartesianas y dibuja una
curva conectando estos mismos puntos.
 La introducción manual de una línea curva o spline punto por punto.

Idealmente la solución a utilizar sería la primera, pues esta aprovecha las funcionalidades ya
ofertadas por el propio Solid Edge, haciendo innecesario el paso de lectura del archivo Excel
por código propio. Sin embargo esta alternativa se demostró imposible debido a una
dificultad particular.
Solid Edge permite el dibujado de curvas mediante la lectura de documentos Excel, sin
embargo esta propia herramienta aun siendo capaz de ejecutar el dibujado de la evolvente,
no se ha demostrado apta para la formación del perfil de diente. Esto se debe a que el
objetivo buscado con el dibujado de la curva, es la obtención de un perfil que pueda ser
utilizado como base en una operación de corte de material.
Para que este sea válido para la tarea, es necesario que todos los elementos del mismo
constituyan una única unidad. Al utilizar la sub-rutina mencionada, la curva es dibujada, pero
esta misma no está asociada a ningún perfil previo y por lo tanto habrá de ser incluida en
otro boceto. La curva se comporta como un boceto en 3D, que a pesar de haber utilizado
exclusivamente coordenadas XY para su dibujado, su comportamiento es el de un elemento
de dibujo no asociado a plano ninguno. Si se desea trabajar con la curva conseguida esta ha
de ser proyectada sobre un plano, en este caso aquel sobre el que se pretende trabajar.
Bajo cualquier otra circunstancia esta tarea debería de ser posible pero por razones
desconocidas al intentar hacer la proyección mediante código la curva no es capaz de ser
asociada al perfil. Al fallar dicha asignación, este método se convierte en inviable.
La otra alternativa al método mencionado sería el dibujado de la misma curva punto por
punto, tarea que resulta considerablemente más trabajosa pero presenta la ventaja de
resultar más óptima de cara a la velocidad de procesamiento.
El algoritmo a seguir sería el siguiente:
I. Una sub-rutina es llamada y se introducen los parámetros de construcción de la

evolvente en el archivo Excel.
II. El archivo calcula las coordenadas de la nueva curva y dichas coordenadas son
leídas por otra subrutina, la cual cierra el archivo y guarda los cambios.
III. Las coordenadas obtenidas se utilizan para generar la curva evolvente.
El algoritmo mencionado en apariencia es sencillo de ejecutar pero ha demostrado presentar

ciertas dificultades técnicas para su final resolución. Dicha dificultad surge a consecuencia
de un fallo de lectura de valores interno del propio Solid Edge.
Al utilizar como base de trabajo un perfil de evolvente generado por cálculo numérico de alta
precisión, los datos obtenidos para el dibujado de la curva alcanzan un elevado número de
decimales.
Solid Edge al tratar de dibujar curvas con esta cantidad de decimales genera elementos con
errores internos e indeterminaciones, por lo tanto es necesario un ajuste de precisión. Para
la definición de la curva evolvente el número de cifras significativas no debe superar el límite
interno propio de Solid Edge, el cual se sitúa en un orden de magnitud de 10 e-09. Esto se
debe a que Solid Edge cuando realiza el dibujado de las curvas mediante puntos, en el
momento que encuentra ciertas incongruencias numéricas llega a indeterminaciones y la
curva generada deja de ser válida.
La solución más natural a este problema sería truncar los valores generados por el archivo
Excel en ese mismo orden de magnitud. Ahora bien esa posibilidad, al utilizar unos

IMPLEMENTACIÓN
parámetros de desconocido valor, la cantidad de valores del intervalo de dibujado que vayan
a superar dicho límite es desconocido de antemano.
Al ser la curva evolvente una curva de decrecimiento muy rápido en aquellos valores
angulares cercanos al 0, la realización de aproximaciones en valores decimales tan
cercanos entre sí puede conllevar la perdida de información significativa. Tras numerosas
pruebas de ensayo y error se observó que redondeando el valor de la curva en el octavo
decimal el problema mencionado no se presentaba y constituye la solución más
comprometida posible.
El siguiente paso a seguir consistiría en la determinación del punto de corte entre la curva
evolvente y el diámetro primitivo. Solid Edge carece de sub-rutinas establecidas para la
determinación de puntos de corte entre elementos de dibujado en un perfil, a pesar de que
esta misma capacidad es demostrada cuando se efectúan recortes de elementos de dibujo.
Ante la falta de herramientas capaces de obtener las coordenadas del punto deseado, la
intersección entre ambas curvas ha de ser realizada manualmente.
Este proceso pasa por la comparación de valores entre la ecuación de un círculo de
diámetro igual al del primitivo y los valores que definen la evolvente, que recordamos han
sido obtenidos en intervalo de ángulo de 0 a 90º. Dado que los valores propios de la curva
evolvente son limitados, no disponiendo en todo momento de más de 90 datos, la
determinación del punto de corte es por si misma altamente aproximada.
La curva evolvente dibujada en Solid Edge, es elaborada mediante una aproximación entre
puntos que sigue una interpolación cuyo orden podemos determinar en el propio proceso de
dibujado. Se optó por una ecuación de orden 3 para la elaboración de dicha curva, al ser la
solución obtenida de una precisión aceptable y por motivos de optimización del proceso,
siendo órdenes más elevados considerablemente más lentos de ejecutar.
Para garantizar un mínimo de precisión en el cálculo, es necesario hacer una comparación
valor a valor de la curva evolvente con la batería de valores procedentes de la ecuación del
círculo. El círculo primitivo fue construido con 1000 puntos, de los cuales solo unos cientos
serán utilizados para el cálculo.
El proceso de comparación parte del siguiente principio, al ir comparando punto a punto de
la curva evolvente con los valores de las coordenadas que definen el círculo primitivo, el
punto de corte de ambas curvas se situará en aquel valor de la evolvente cuya diferencia
respecto a un punto cualquiera del círculo en coordenadas no valga más de un cierto valor.
Se consideró como una solución aceptable la determinación del punto de corte con una
precisión del 0.1%, pues los valores angulares en torno a los que se producirá dicha
intersección no disponen de más de 3 cifras significativas.
Una vez ha sido obtenido el punto en que ambas curvas cortan, se debe dibujar una curva
evolvente simétrica a la primera, tomando como eje de simetría una recta que se encuentra
desplazada angularmente un valor dependiente del número de dientes del engranaje.
𝑎𝑛𝑔𝑢𝑙𝑜 = 360/4 · 𝑍 (9)
Se puede observar en la Ilustración 25 un ejemplo de lo anteriormente descrito. Las curvas

evolventes, representadas en naranja, cortan al diámetro primitivo en un punto, sirviendo
este de base para la construcción de una línea recta desde el centro geométrico a dicho
punto. Esta recta, verde en la ilustración, permite establecer el eje de simetría utilizado para
la determinación del lado opuesto del diente. El motivo por el cual se sigue este algoritmo es

el hecho de que debemos garantizar el paso angular existente entre los puntos del diente
contenidos en la circunferencia primitiva, definiendo de esta forma el ancho del diente.
La ejecución de este mismo paso parte del trabajo realizado previamente en el modelo base.
Dicho modelo contiene todas las circunferencias necesarias para la definición de una rueda
engranada junto con una pareja de curvas evolventes separadas mutuamente por un ángulo
concreto en la misma medida que se ha indicado en el párrafo anterior. El motivo por el cual
se utiliza dicho modelo base, es la posibilidad de facilitar el código del programa y a que al
partir de modelos previamente creados, se acelerará igualmente la velocidad con la que el
programa se ejecuta.
Todos los elementos mencionados, son controlados por medio de dimensiones o cotas
previamente establecidas y la modificación del modelo base para que sea adaptado a las
dimensiones deseadas pasa por la simple modificación de las mismas. Naturalmente dichas
modificaciones se ejecutan al principio de la función encargada de la construcción de las
ruedas engranadas.
Como se pretende garantizar que el perfil obtenido pueda ser cerrado, el punto de corte
obtenido anteriormente, será aproximado a aquel punto del intervalo de valores, que el
archivo Excel ha generado, que más se aproxime a las coordenadas reales de intersección.
Ilustración 25: Intersección evolvente y diámetro primitivo.
Una vez establecidas ambas curvas, la determinación del perfil final del diente pasa por el
cierre de los extremos de su base. En determinados casos en los que el diámetro de pie del
diente sea mayor al diámetro de base del mismo, el cierre de la base no se realiza utilizando
los extremos interiores a la curvatura de la evolvente, sino de unas curvas que extiendan
este mismo hasta el diámetro de base. Se puede tomar como aproximación valida la
utilización de líneas rectas debido a la muy corta extensión de las mismas en comparación
con el tamaño de la rueda engranada.
Esta consideración es importante tenerla en cuenta durante la elaboración del programa,
pues su omisión implicaría la obtención de un perfil invalido.
El proceso de construcción del perfil inicial del diente finaliza con el redondeo de los
extremos de la base, tomándose de forma aproximada una semicircunferencia de diámetro
igual a la separación entre puntos de la base.

IMPLEMENTACIÓN
La incorporación de dicha curvatura se podría realizar manualmente asignando un arco que

conecte con los puntos extremos especificados y posteriormente cerrando el perfil
asignando los ya mencionados puntos clave o keypoints.
La asignación de estos mismos ha de ser realizada punto a punto, conectando elementos de
dibujado en aquellos puntos que correspondan. Dicho proceso sin embargo se ha probado
como infructuoso debido a un error interno del propio Solid Edge.
Se da la particularidad de que Solid Edge al tratar de conectar elementos de dibujo a los
extremos de curvas por puntos también llamada Splines, no es capaz de diferenciar
correctamente extremos iniciales de finales. Esto lleva como consecuencia que al realizar la
asignación del punto correspondiente, es decir el extremo interno del mismo al arco con el
que se pretende cerrar, este último es colocado en el extremo contrario de la Spline. Por lo
tanto independientemente de lo que se le comande por código al programa, la curva será
situada en el extremo opuesto al que debería. Dado que las restricciones asociadas a los
Keypoints son consideradas como prioritarias sobre el resto de restricciones, igualmente las
dimensiones de dicho perfil son modificadas para acomodar a la posición a la que este es
restringido.
El mencionado error de Solid Edge, ha obligado a la necesaria elección de un método
alternativo para resolver el problema. Esa solución pasa por el aprovechamiento de una
capacidad secundaria asociada a las herramientas de corte que Solid Edge presenta a la
hora de modificar perfiles.
Cada vez que se recorta un elemento, los extremos de ese mismo elemento, cuando en
contacto con terceros elementos de dibujo, se les son asignados unas restricciones de
Keypoints automáticamente. Esto abre la posibilidad de resolver el problema mediante la
definición de una circunferencia que tenga por centro el punto medio entre los extremos de
la base y por radio la distancia media entre estos mismos.
Una vez dicha circunferencia ha sido dibujada, conociendo por lo tanto que esta misma pasa
por los puntos que se desean conectar. Basta con eliminar la mitad externa de la misma
para obtener el arco deseado, el cual ya ha recibido las correspondientes restricciones de
Keypoints. Permitiendo en este sentido el cierre y validación posterior del perfil.
En la ilustración 26, aquí presentada se visualizan los puntos extremos a conectar que se
han descrito anteriormente.
Ilustración 26: Puntos a conectar manualmente.

Una vez obtenida la forma final del perfil, todas aquellas líneas no necesarias para el mismo
son eliminadas. Tales como las circunferencias de base, pie y primitivas junto a toda línea
recta de apoyo.
Este último paso ha constituido uno de los principales problemas encontrados durante la
generación de los perfiles engranados debido al distinto comportamiento del programa en
sus modos manual y automático.
El proceso de obtención del perfil, pasa por la eliminación de todo elemento de dibujo que
no constituya parte final del perfil. Para la construcción del perfil de diente, de las curvas
dispuestas en el modelo base utilizado, sola serán necesarias ambas curvas evolventes, el
arco de cierre y la circunferencia de cabeza del diente. El resto de elementos han de ser
eliminados.
La principal dificultad presentada en este paso surge del algoritmo de recorte que Solid
Edge utiliza. Para efectuar el recorte de cualquier elemento de dibujo, Solid Edge exige de la
introducción de elementos auxiliares que intersecten con aquel elemento que se pretenda
recortar. El proceso de corte depende de un vector encargado de determinar aquella parte
del elemento que ha sido intersectado, como sujeto de ser eliminado.
Dicho proceso de corte genera nuevos elementos de dibujo, pasando de un elemento
original a otro nuevo cuya posición en la lista de elementos del mismo tipo no conocemos.
Para poder entender esta dificultad se presenta un ejemplo:
En la ilustración aquí presente se
observa la existencia de un círculo y
dos líneas rectas. Dichas líneas
representan aquellos elementos de
dibujo que utilizaremos como apoyo
para recortar el círculo.
Manualmente bastaría hacer pasar el

cursor del ratón, dibujando una
trayectoria de recorte que pase por
cualquiera de estos elementos. En caso
por ejemplo de hacer pasar dicha
trayectoria sobre el círculo fuera de la
zona contenida por las rectas, se
eliminará el arco que no esté contenido
en el interior de dichas líneas.
Ilustración 27: Ejemplo perfil a recortar.

Con motivo de ello, lo que antes
constituía un círculo, elemento de tipo
preestablecido en Solid Edge, pasa a convertirse en un arco. Dicho arco será almacenado
automáticamente en la posición final de la lista de elementos de arco, la cual se recuerda ha
sido generada automáticamente por Solid Edge para contener todos aquellos elementos del
mismo tipo que sean utilizados en el documento activo.
El problema surge cuando se trata de replicar este mismo proceso mediante código. Aquella
operación que puede ser realizada con el simple pasaje del cursor por encima del elemento
que se deseé recortar, ha de ser realizada por tantos elementos de apoyo al recorte como
sean necesarios, en el caso presentado las dos líneas rectas y un vector a determinar. El
vector efectuará la misma función que la trayectoria dibujada en caso de ejecutar el proceso
manualmente. La complicación surge, del hecho de que no se recorta elementos tan simples

IMPLEMENTACIÓN
como los del ejemplo, sino que esa misma tarea ha de ser realizada apoyándose en muchos
más elementos y teniendo que determinar de una forma aproximada los puntos de corte de
los mismos.
Dado que este proceso sería altamente ineficaz se optó por una simplificación del perfil que
se debe de recortar. Como solo ciertos elementos constituirán parte del perfil final, se
genera un nuevo perfil auxiliar, que contenga esos elementos necesarios y ninguno
adicional, reduciendo considerablemente la dificultad de la tarea a realizar.
Para ello los elementos necesarios son copiados al perfil auxiliar serán recortados aquellas
partes del mismo que no se deseen. El modelo a generar será guardado sin efectuar
modificación alguna al modelo base, evitando la pérfida por lo tanto de la plantilla de trabajo
en el proceso.
El perfil obtenido al final de este algoritmo será utilizado consecuentemente como base de
las operaciones de recorte que definirán la forma final de la rueda engranada. Dicha
operación dependiendo del tipo de engranaje que se trate habrá de efectuarse con una
trayectoria perpendicular al lateral de la rueda si se trata de un engranaje recto o con una
trayectoria helicoidal si es oblicuo.
Si dicha operación fuese realizada manualmente las funciones a ejecutar serían distintas, al
hacer dicha misma operación por código, basta con la introducción de un ángulo de diente
igual a 0 en caso de diente recto o distinto para el oblicuo.
Extrusión helicoidal del engranaje:
Tratando el caso más general de engranaje, de diente oblicuo, la operación a realizar para
obtener el modelo final es un corte helicoidal. Como ya se parte de un modelo previo, no es
necesaria la extrusión de nuevo material, bastando solo con el cambio de dimensiones del
mismo en función de los parámetros introducidos.
La ejecución del mencionado corte helicoidal utilizará el perfil creado en el apartado anterior
y posteriormente será repetida dicha operación tantas veces como le sea indicado.
Siguiendo un patrón circular, el número de repeticiones es igual al número de dientes de la
rueda.
Dicha operación ha constituido con diferencia la mayor dificultad presentada durante la
elaboración de un algoritmo capaz de generar modelos de engranajes. Para poder entender
la problemática es necesario comprender una serie de puntos básicos en lo relacionado a
las operaciones de construcción de volúmenes en Solid Edge.
Toda operación de construcción en Solid Edge, parte de utilizar perfiles cerrados (dibujos
esquemáticos de la forma a construir) que sean interpretados como correctos por el propio
programa, siendo estos perfiles ajustados, aplicando cotas donde sean necesario.
De cara al usuario, Solid Edge ofrece dicho perfil como un elemento perteneciente a los
llamados Sketches (Bocetos) con los cuales se podrá trabajar directamente sin la necesidad
de realizar acción alguna. En toda operación volumétrica se escoge el boceto con el que se
desea trabajar y se seleccionan los parámetros de la operación según necesidad del
usuario. Más concretamente en el caso de operaciones de corte helicoidal los parámetros
pedidos serían tales como el eje entorno al cual se elaborará la operación, el paso de la
misma, la longitud y el perfil a utilizar.

La dificultad a la hora de realizar dicha operación mediante código y no manualmente, se

presenta ante el hecho de que se trabaja con un modelo previamente generado y que por lo
tanto tendrá ya una serie de bocetos sobre los que haremos las modificaciones
convenientes. Tales como modificación de ángulos, dibujado de nuevas curvas evolventes y
operaciones en general de dibujado del perfil a recortar.
Como estos Sketches están ya incluidos en elementos de
tipo boceto, cuando se pretenden utilizar a nivel de
código, se estarán seleccionando igualmente no un perfil
sin ligaduras a elementos existentes sino uno ya ligado a
un elemento tipo sketch. Es aquí donde surge la principal
dificultad, pues aun no siendo aparente la necesidad de
utilizar perfiles sin ligaduras, esta es la única forma de
conseguir que la operación sea exitosa.
Dicho requerimiento resulta altamente contra-intuitivo
pues de nuevo aquello que es posible de forma manual,
no lo es mediante código. Este particular problema surge
del sistema interno que Solid Edge utiliza para determinar
el perfil con el que se vaya a operar. Por motivos de Ilustración 28: Perfil finalizado.
flexibilidad los perfiles manualmente son seleccionados
elemento a elemento de dibujo, constituyendo lo que Solid Edge llama cadena. Estas
cadenas pueden ser abiertas o cerradas, pertenecer o no a un boceto o ser un elemento
geométricos del modelo tales como las aristas del mismo.
Al ser la selección de la cadena que vaya a ser recipiente de la operación de forma manual,
Solid Edge utilizará perfiles locales y no asociados a un boceto, aunque estos puedan ser
seleccionados de uno. Esta particularidad no viene recogida en ninguna guía ofertada por
Siemens, sin embargo se ha probado como fundamental para poder llegar a ejecutar el
objetivo marcado.
Si se pretende seleccionar directamente un perfil asociado a un boceto, como sería el caso
del algoritmo por el cual ha sido obtenido el perfil con el que se trabajará, las operaciones de
construcción darán un fallo interno y no se ejecutarán de forma satisfactoria. A consecuencia
de ello el perfil previamente generado ha de ser copiado íntegramente a un perfil auxiliar
vacío.
Se puede extraer una conclusión altamente importante de esta dificultad: si se desea
realizar operaciones constructivas de volúmenes, solo mediante perfiles libres, no
asociados a ningún boceto estas operaciones podrán dar lugar a modelos libres de
errores. Una vez sorteada esta dificultad la operación de corte resulta trivial.
Para finalizar el proceso general de creación de modelos engranajes, la misma operación de
corte se repetirá mediante un patrón circular. Dicho patrón utilizará como círculo de apoyo la
circunferencia de cabeza del engranaje, al ser esta la más externa del mismo.
Esta fase de construcción del modelo engranado es aquella que conlleva con diferencia el
mayor tiempo de ejecución y es un proceso altamente intenso en la memoria RAM del
ordenador.

IMPLEMENTACIÓN
4.4.6. Creación informe PDF:
La elaboración de un informe post-generación de los modelos, ha sido considerada como

prioritaria debido a la naturaleza docente que persigue este proyecto. Con la elaboración de
dicho informe se pretende aportar al usuario de una herramienta capaz de reunir toda
aquella información considerada como vital para la generación del modelo así como una
visualización rápida de los modelos generados. La última afirmación cobra especial
importancia cuando se refiere a los modelos de las ruedas engranadas. Estos últimos son
modelos que manejan una gran cantidad de polígonos y elementos de dibujo, provocando
por lo tanto que su visualización una vez construidos sea un proceso largo y exigente para el
ordenador.
Con el objetivo de eliminar la necesidad de
consultar manualmente los modelos generados
para introducir posibles mejoras, se aporta una
descripción detallada de aquellos parámetros
que han hecho posible la formación del modelo,
junto a una pre visualización en forma de
imágenes del propio engranaje.
El formato a buscar con este informe es por lo
tanto una visualización clara de aquellas vistas
consideradas como más importantes para el
modelo, junto a una tabla con los parámetros
constructivos de cada uno de los arboles
motrices y ruedas engranadas.
Para elaborar documentos en formato PDF es
necesaria la utilización de librerías de terceros
desarrolladores, pues dicha capacidad no es
ofertada por las funcionalidades presentes en
Microsoft office. Alternativamente el uso del
editor de texto propio de equipos Microsoft
representaría una opción viable para el
cumplimiento de este mismo objetivo, sin
embargo ante la falta de modularidad y la mejor
presentación visual ofertada por un formato
Ilustración 29: Modelo de informe. PDF esta opción fue desestimada.
Como ya ha sido mencionado, dado que este proyecto pretende ser distribuido a terceros
usuarios, es imperativo el uso de productos que no requieran el pago de derechos de autor.
Siendo por este motivo el producto de Migradoc Corporation, PDF Sharp, la alternativa
finalmente considerada como más ideal. Migradoc Corporation exige únicamente la
correspondiente acreditación de toda pieza de código aportada en sus librerías de libre
distribución siempre y cuando estas sean utilizadas, sin ningún tipo de recargo económico.
Atendiendo a aspectos técnicos el uso de PDF Sharp implica la utilización de un producto
constantemente en desarrollo y de capacidades limitadas por ello. La utilización de este
recurso conlleva la particularidad de que por cada elemento a incluir en el informe, ha de ser
colocado manualmente mediante código y por lo tanto constituye un proceso trabajoso.
PDF Sharp funciona mediante dos módulos diferenciados. En el caso de querer elaborar
documentos de texto simples, formados por elementos usuales tales como tablas, enlaces, o
gráficas, se optará por el módulo llamado MigraDoc. En caso de querer elaborar interfaces
gráficas elaboradas para documentos PDF en los que se utilicen gran cantidad de
elementos de dibujo el módulo a utilizar será PDFSharp.
Para el proyecto planteado la simple elaboración de un documento de texto resulta

suficiente y por lo tanto se ha optado por la utilización de MigraDoc, módulo que igualmente
soporta la generación de documentos PDF.
De cara a la elaboración del documento se debe tener en cuenta que amos módulos aunque
compatibles, no han sido pensados para trabajar complementariamente y cualquier tipo de
documento de mayor complejidad que requiera de la utilización de ambos, exige hacer creer
al ordenador de que el documento utilizado es simultáneamente de ambos tipos. Este hecho
da lugar a numerosos errores y resulta confuso, por eso es preferible evitarlo salvo estricta
necesidad.
Definición del documento:
Ilustración 30: Ejemplo PDFSharp
Al igual que un documento realizado manualmente, MigraDoc/PDFSharp permite la

definición de cabeceras, pies de página, numeraciones y otro tipo de elementos de texto.
Para abordar esta tarea se puede plantear de dos formas, bien mediante el establecimiento
de tipos predeterminados o bien asignando página a página aquellos elementos que se
desea que aparezcan. De esta forma se pueden establecer tipos de fuente predeterminados
a utilizar, en aquellas situaciones que se especifiquen, tales como los ya mencionados pies
de página.
Cada elemento dispone de una serie de características que lo definen, en el caso de una
imagen tales como sus dimensiones, si esta es re-escalada al tamaño del documento,
número de pixeles entre otros Se puede observar en la ilustración 30 un ejemplo de
definición de lo anteriormente explicado. Todos estos elementos han de ser introducidos
manualmente en el documento mediante una especificación por código.
PSF Sharp interpreta los documentos como elementos de extensión finita, determinada esta
misma en función del formato elegido (A2, A4, etc…) que salvo explicita definición no
contempla saltos de página. Esta aparente complejidad permite que el código del mismo sea
altamente versátil, permitiendo la creación de documentos capaces de contener más
información de aquella que pueden representar. Por otro lado esta especificación implica
que el proceso de formación del documento se base en constante ensayo y error. La
elaboración de un documento relativamente simple requiere grandes cantidades de tiempo,
pero aporta la ventaja de que una vez creado el documento, la presentación de información
es automática.

IMPLEMENTACIÓN
Fotografías de los modelos:
La incorporación de una pre-visualización del modelo generado constituye un objetivo

prioritario.
Como primera aproximación se optó por la utilización de aquellas herramientas de captura
de imagen ya incorporadas por Solid Edge. Esta tarea sería realizada por el módulo de
renderizado incluido en el mismo, llamado Keyshot.
Dicho módulo es sin embargo propiedad de una tercera empresa, siendo su código
restringido a los usuarios del mismo. El conjunto de librerías que permiten su funcionamiento
no se encuentran situadas en las librerías aportadas por Solid Edge. Dicho módulo forma
parte de un complemento accedido en línea por el ordenador cada vez que se inicia un
acceso al mismo y por lo tanto el código que lo hace funcionar no es accesible de forma
manual por el usuario.
Esto no impide la posible automatización del propio módulo por código, aprovechando
directamente la API aportada por Keyshot. Existe sin embargo una vía alternativa, la cual
implicaría la elaboración de una macro específica para esta tarea. Dado que Keyshot es un
producto basado en el lenguaje Python, solo mediante la inclusión de paquetes de
interoperabilidad esta solución sería posible. Esto implicaría el aprendizaje de un nuevo
lenguaje de programación exclusivamente para esta tarea, familiarizarse con el
funcionamiento de una API distinta y el aumento considerable del peso del programa, al
tener que añadir los paquetes de interoperabilidad a los archivos de programa.
Por todos estos motivos se optó por la utilización de simples capturas de pantalla para la
elaboración de dichas imágenes mediante comandos internos de Solid Edge. El proceso a
seguir sería el siguiente:
I. El modelo es generado y verificado.
II. Se desplaza la cámara hasta las vistas deseadas.
III. Se ejecuta un comando de captura de pantalla y las imágenes son guardadas.
IV. Una subrutina, aglutina imágenes y parámetros leídos y genera el informe PDF.
Este algoritmo aunque fiable en la versión actual de Solid Edge, es una solución
considerable como temporal. Al hacer uso directo de comandos por número de identificación
dentro Solid Edge, no se puede garantizar que en futuras actualizaciones dichos número no
varíen. En consecuencia puede que el programa deje de funcionar en futuras versiones.
Esta una de las principales mejoras a realizar de cara a proyectos futuros, pero ante las
exigencias que implicaría la búsqueda de una solución mediante el uso Python no resulta
viable para la extensión de este proyecto.

IMPLEMENTACIÓN
En este apartado nos disponemos a explicar cuál ha sido la implementación final del
proyecto expuesto y las principales funciones desarrolladas para la elaboración del mismo.
Internamente para facilitar el uso de las funciones creadas, estas mismas han sido
recogidas en único espacio de nombres (NamesSpace) llamado Functions, habiendo sido
explicada su definición en el apartado 4.4.2. Este agrupa en su conjunto 4 tipos distintos de
clases, en las que todas las funciones creadas son definidas.
Ilustración 31: Espacio de nombres functions y sus campos.
La explicación de cada uno de estos campos se realiza en los siguientes apartados y en la

ilustración 31, se muestra el esquema interno que sigue el espacio de nombres.
4.5. Funciones de interacción con Solid Edge.
Como fue explicado en apartados anteriores, para garantizar el mejor rendimiento posible
del programa diseñado, ha sido necesaria la implementación de unos protocolos de
actuación sobre Solid Edge. Para evitar repetición de lo explicado consultar Ilustración 9.
Cada uno de los pasos lógicos explicados en dicho diagrama de flujo, se corresponde con
una función creada específicamente para su cumplimiento. Por lo tanto para interactuar con
Solid Edge se han creado 3 funciones:
 IsSolidEdgeOpen()
 OpenSolidEdge()
 CloseSolidEdge()
Sus nombres son auto explicativos pero haremos un breve inciso sobre el funcionamiento
interno que permite que estas trabajen.

IMPLEMENTACIÓN
Toda interacción que se pretenda realizar sobre Solid Edge se efectúa tratando de hacer
una asignación por referencia a un objeto del mismo tipo que la aplicación de Solid Edge.
Como se ha mencionado en anteriores apartados, cada elemento de funcionamiento de
Solid Edge tiene su relativo informático, en forma de un dato particular. La propia aplicación
no constituye una excepción y el control sobre la misma se realiza a través de un tipo de
objeto llamado:
SolidEdgeFramework.Application
Como puede ser observado este objeto pertenece a la librería de SolidEdgeFramework, que
como fue explicado supone la librería encargada del control de toda la estructura principal
de Solid Edge. Cuadro se genera un nuevo objeto, dicho objeto carece de asociación en
memoria alguna, y cualquier acción que se realice sobre el, carecerá de efecto. El proceso
de interacción con Solid Edge se establece tratando de realizar dicha conexión.
En caso de estar abierto Solid Edge, solo existirá un objeto de este tipo y haciendo llamada
a una función propia del entorno Visual Basic podemos recoger los objetos que estén siendo
utilizados en ese mismo momento y tratar de establecer esa asociación por una etiqueta.
Cada objeto tiene asociada una etiqueta, con la cual podemos hacer llamada al mismo. El
espacio de nombres que guarda dicha función se llama Marshall, este espacio es propio del
sistema operativo Windows y se encarga de establecer conexión en memoria con los
recursos de los que haga uso el ordenador.
Para el caso de este proyecto, bien la asociación con el objeto en memoría se hará poque
este ya este activo o bien sea necesario crearlo. En caso de estar activo, una función propia
de Marshall se encarga de buscar en memoria un objeto que tenga la misma etiqueta que se
le ha introducido. SI lo encuentra, lo devuelve y de esa forma ya es posible actuar sobre
Solid Edge.
En caso de no poder encontrar
el objeto, la activación de Solid
Edge se realiza creando un tipo
de dato igual al indicado
anteriormente. Para llevar a
cabo esta operación, como
Windows no conoce los tipos
de datos internos usados por
un programa es necesario
buscar esa información de
entre los archivos de programa
instalados. Salvo los tipos de
datos propios sean cargados
previamente, como ocurre
durante la definición de
funciones al importar librerías,
Windows no podrá establecer
conexión.
La forma de resolver este

Ilustración 32: Algoritmo apertura SolID Edge. problema es buscando el
programa por su número de
identificación interna o ID. Se crea un tipo genérico de dato y este mediante la ID del
programa busca dentro de los tipos de datos definidos por la aplicación el deseado, en este
caso la propia aplicación.
4.6. Funciones de interacción con archivos.
Numerosas funciones han sido necesitadas para poder establecer control de datos y poder
interactuar con el conjunto archivos de los que depende la arquitectura interna del programa.
Estas mismas funciones se pueden agrupar en una serie de sub-divisiones:
 Funciones para la interacción con documentos de parte.
 Funciones de apertura/escritura en Excel.
 Función para la elaboración del informe.
 Funciones de Gestión de datos y variables.
 Función de Calculo paramétrico.
4.6.1. Funciones para la interacción con documentos de parte:
Si se desea controlar los procesos de guardado y generación de nuevos documentos para el

modelado de piezas es inevitable la creación de rutinas propias para este mismo propósito.
La interacción establecida entre los documentos de parte o también llamados de pieza se
resume en 3 puntos principales:
 Determinar si existe o no el documento.
 Crear un nuevo documento.
 Guardar un documento.
El proceso de trabajo es exactamente el mismo que el explicado en el punto anterior,
gracias precisamente al funcionamiento basado en programación por objetos en que Solid
Edge basa toda su estructura. La única particularidad que sea de especial mención es el
protocolo de guardado que ha sido establecido para los modelos.
Ilustración 33: Protocolo de almacenamiento.

IMPLEMENTACIÓN
Este protocolo será emulado para todo tipo de archivo que se necesite guardar durante el
funcionamiento del programa. La interacción es la misma siempre: primero el objeto
informático que se desea guardar activa una función encargada de determinar si ya existe
un archivo en la posición preestablecida de guardado con un nombre predeterminado, que
será diferenciado del resto por el digito añadido al final del mismo. Si encuentra que dicho
objeto existe, cambiará dicho digito hasta que encuentre uno que no exista, momento en el
cual guardará el archivo con ese nuevo digito.
Para evitar la sucesiva acumulación de archivos cada vez que se inicie el programa de
nuevo los archivos creados en la sesión anterior serán sobre-escritos, en el caso de que el
usuario así lo especifique. Dicha acción será realizada a través de una variable booleana en
el Excel común de datos de todo EDIMPO, dando permiso o no a la sobre-escritura de cada
uno de los archivos. Se ha realizado por lo tanto una función de guardado y cambio de
nombre de archivo para: documentos de pieza, imágenes e informe.
Dado que la generación de los arboles motrices es de ejecución muy rápida la orden de
sobre-escritura será ejecutada para todos ellos en vez de por separado. Esta es la única
particularidad presente en el algoritmo de guardado.
4.6.2. Funciones de apertura/escritura en Excel.
Estas controlan el proceso de intercambio de datos realizado durante la ejecución del

programa. Como ya se mencionó anteriormente existe por un lado un archivo común de
datos para todo EDIMPO y otro archivo particular para la generación paramétrica de perfiles
engranados.
Para el archivo general el proceso de intercambio de información se limita a la mera lectura
de la misma. Esto se debe a que como no va a haber ningún tipo de cambio en los
parámetros utilizados para la generación de modelos, salvo aquellos que realice el usuario
fuera del control del control del programa. Se evitará por lo tanto en todo momento la
modificación de los mismos por parte de este módulo. De esta manera el riesgo de provocar
cambios indeseados en el funcionamiento EDIMPO es eliminado.
De esta tarea se encarga la función:

ExcellGeometryRead( ByVal ExcelFile As String ) As Array
Dicha función se encarga por un lado de abrir el archive Excel y de ir circulando por todas
las celdas almacenadas en el documento. Cada celda contendrá una información bien sea
numérica, en forma de variable Verdadero/Falso o como una palabra. Un ejemplo de ello es
visualizable en la ilustración 10.
Independientemente del tipo de dato, toda esta información es leída como si de una palabra
se tratase y se somete a un algoritmo, tal que en función del parámetro que se esté leyendo
dejará dicha información en forma de palabra, la transformará en un número decimal o
entero o a un valor de tipo booleano. Como se conoce en todo momento que dato está
siendo leído y a que parámetro se corresponde este proceso no implica dificultad alguna.

Una vez se finaliza el proceso, el documento es cerrado sin guardar, por motivos de
seguridad y se proporciona a la salida de la función de una tabla de valores en forma de
matriz de varios tipos de datos la cual será utilizada posteriormente en la fase de gestión de
datos.
Ilustración 34: Lectura del archivo principal.
El proceso aquí explicado se repite igualmente en la función particular del archivo de

parámetros en ruedas engranadas:
GearParametersRead(ByVal ExcelFile As String ) As Array
Las únicas modificaciones destacables son el hecho de que a diferencia del archive anterior,
no se leen todos la información del archivo, limitando esta misma a las coordenadas XY de
la curva evolvente, correspondiente a las 2 primeras columnas del archivo junto con un
diferente algoritmo de cierre.
Una particularidad de Excel es que cuando los archivos son accedidos a través de código y
dichos archivos contienen gráficas o ecuaciones internas de cálculo si el archivo es
guardado toda esa información en forma de reglas internas se elimina. Al cerrar un archivo
Excel automáticamente se pide al usuario mediante un menú que guarde los cambios
realizados, como no se desea eliminar la información contenida se debe forzar el cierre del
mismo, borrando el proceso de memoria.

IMPLEMENTACIÓN
Este hecho es de especial importancia para el manejo del archivo de engranajes, pues para
poder renovar la curva evolvente, contenida en el mismo por cada nueva rueda engranada,
se han de modificar ciertos parámetros internos.
Haciendo en consecuencia inevitable la necesidad de guardar el archivo, pues solo una vez
guardado se ejecutan los cálculos internos. Dado que no se puede garantizar que todos los
equipos que ejecuten el programa creado dispongan de la versión más reciente de Office, se
realiza el guardado en una versión anterior.
4.6.3. Funciones de Gestión de datos y variables.
El funcionamiento de la misma ya ha sido explicado en detalle en el apartado 4.4.1, pero se

explicará en detalle el proceso de asignación de datos a continuación. La función
mencionada se llama:
ShaftGeometry ()
El proceso de funcionamiento de la misma es el siguiente:
I. Se le asignan variables de los tipos de objetos explicados en la estructura interna de
datos, vacíos.
II. Se activan las funciones de lectura de datos anteriores.
III. La información obtenida es almacenada en las variables anteriormente vacías y se
finaliza el proceso de ejecución.
Como la asignación de esa información se hace por referencia, al final del proceso se
obtiene una lista anidada de datos asociados a los objetos que se han creado. Esto se
realiza específicamente para agrupar la información de una forma intuitiva y extrapolable a
objetos físicos reales.
Todo este proceso de asignaciones se realiza mediante una serie de listas de apoyo. Cada
objeto superior en jerarquía al anterior dispondrá de una lista de aquellos objetos
subordinado al mismo, que en un principio se encuentra vacía. Las listas mencionadas
anteriormente simplemente cumplen de función de medio en el que apoyarse a la hora de
realizar las asignaciones.
Una limitación muy importante en el proceso de construcción de la estructura de datos es el
hecho de que cuando se subordinan varios niveles de listas, la información de los niveles
inferiores no puede ser asignada con una única lista de apoyo. Para mejor entendimiento de
este problema se adjunta el siguiente gráfico:

Ilustración 35: Organización interna de objetos.
Cada lista representada en este gráfico debe de tener su correspondiente programado y

definido por detrás. En consecuencia existe una limitación importantísima de cara a extender
las dimensiones de la estructura. El motivo por el cual es necesaria la definición de tanto
elemento, es el hecho de que a pesar de que cada objeto definido, como sería el caso de un
Árbol o un Engranaje, disponga de una serie de propiedades, tales como las listas de
objetos subordinadas al mismo, al ser necesario el uso de listas auxiliares, cada vez que se
pretenda hacer una asignación de valor a un nuevo Árbol o Engranaje en vez de cortar la
conexión anteriormente establecida, como sería de esperar, esta se mantiene.
En consecuencia, al tratar de almacenar los valores en los subsiguientes elementos solo se
modificarán las propiedades del primero asignado, tantas veces como veces se realice una
asignación.
Ilustración 36: Problema listas anidadas.

IMPLEMENTACIÓN
Existen medios para evitar esta problemática, sin embargo al ser un programa de uso
académico se ha determinado que la estructura utilizada es ideal para los objetivos
planteados. En caso de querer extender las capacidades del mismo, la estructura habrá de
ser modificada en consecuencia.
El proceso descrito es emulado por los engranajes, añadiendo como particularidad el hecho
de que previa lectura de los datos se inicia la sobre-escritura del documento de generación
para evolventes y a posteriori se obtienen los datos de las variables modificadas.
4.6.4. Función de elaboración del informe.
La función creada para la realización de esta labor se corresponde con la rutina llamada:
CreateSummary()
Dicha función, como ha sido comentado con anterioridad, se encarga por un lado de
organizar la información necesaria para la correcta descripción de cada modelo en pantalla,
junto con la colocación de las imágenes anteriormente obtenidas de los modelos y la
elaboración de una portada.
El proceso seguido para obtener el documento final es el siguiente:
 De la estructura de datos interna se obtienen los parámetros deseados.
 Se crea una página por cada modelo a representar.
 En cada página se añade la fotografía del modelo y se monta una tabla con los
parámetros.
Particularidades tales como numeraciones, pies de página, marcas de agua y otro tipo de
elementos de escritura han debido ser añadidos manualmente, eligiendo la posición en
pantalla bien por coordenadas establecidas mediante ensayo y error o en posicione
predeterminadas. Actualmente el informe, añade facultades tales como la fecha de creación
del documento y el nombre del autor.
4.7. Creación de ejes de transmisión.
La rutina encargada de la creación de los ejes de transmisión, constituye junto con aquella
destinada a la generación de ruedas engranadas las principales funcionalidades aportadas
por el módulo a crear. Se explicará a continuación exclusivamente el algoritmo seguido para
la consecución de dicho objetivo.
El proceso comienza con la preparación del plano sobre el que se dibujará el perfil inicial.
Para conseguir la formación de una única pieza cilíndrica de distintos radios y longitudes, a
las que hay que añadir la presencia de radios de acuerdo, se ha optado por la extrusión por
revolución de la mitad superior de la silueta del mismo.

Para la consecución de este objetivo se ha diseñado un algoritmo que seguirá los siguientes
principios:
I. Primero se establece una línea vertical de igual extensión al radio de la primera
sección del árbol, seguida de una horizontal de misma extensión que la longitud de
esa primera sección.
II. Para las consiguientes secciones en función de si el radio siguiente es superior o
inferior al anterior, se dibujará una línea ascendente o descendente, acompañada de
del respectivo radio de acuerdo. La diferenciación entre secciones ascendentes y
descendentes es importante debida a la distinta curvatura del radio de acuerdo.
III. La sección hasta ahora dibujada es completada por la línea horizontal
correspondiente a la misma.
IV. Una vez dibujadas todas las secciones el proceso finaliza con una última línea
horizontal, inferior al perfil, con el objetivo cerrar el boceto.
Ilustración 37: Perfil de árbol de transmisión.
La ilustración 37 se corresponde a un ejemplo realizado con el algoritmo mencionado.

Como se ha comentado en anteriores apartados todo perfil ha de ser validado y para ello es
necesario incluir las restricciones de puntos clave.
En esta función, dicha tarea es realizada intentando unir las correspondientes líneas
horizontales y verticales en aquellos puntos que carezcan de radios de acuerdo. La forma de
determinar si esto posible o no se basa en la simple ejecución de una orden de tipo Try.
Try es una orden interna de Visual Basic que establece como su nombre indica un intento de
ejecución, el fallo a conllevar dicha ejecución no resulta en la terminación del programa,
como si ocurriría con cualquier otra sentencia fallida. Para poder determinar si ha fallado o
no, se puede adaptar dicha orden a realizar una serie de acciones tales como borrar
variables o hacer que salga por consola una descripción del fallo encontrado.
Este tipo de sentencia ha sido utilizada en numerosas ocasiones durante la elaboración del
código. Para el caso explicado, al ordenar la ejecución de la misma, si se intenta unir una
línea horizontal con una vertical en presencia de un radio de acuerdo mediante un punto,
naturalmente la orden fallará y dicho proceso no podrá ser completado.

IMPLEMENTACIÓN
En consecuencia se irá pasando de sección a sección mediante un bucle hasta finalizar el

proceso. La asignación de keypoints tiene la particularidad de que el primer elemento de una
lista de elementos de dibujado siempre comienza por un índice 0, realidad que no se cumple
en la mayor parte de los casos en Solid Edge, siendo el índice 1 el predeterminado. Dicha
particularidad ha sido averiguada mediante ensayo y error, pero no es una información
recogida en ninguna guía. El perfil una vez restringido es cerrado y validado.
A continuación se ejecutará la orden de extrusión por revolución. Dicha tarea es realizada

por la función .AddFiniteRevolvedProtrusion , la cual a diferencia de todas las
funciones utilizadas en el dibujado del perfil, está asociada no a la colección de perfiles sino
a la de modelos, entendiendo por modelos, como el dato interno que Solid Edge asigna a los
mismos.
Ilustración 38: Operaciones sobre Volumen en Solid Edge.
Como se comprobará posteriormente, es importante entender la diferencia entre procesos

de adición de material y procesos de eliminación. Todas aquellas funciones que Solid Edge
utiliza para la ejecución de las primeras, siempre van asociadas al dato tipo de modelos, no
es así para las operaciones de recorte. El motivo por el cual esta asociación es realizada es
porque en una partimos de la premisa de que no hay volumen y por lo tanto no existirá
aquello que definirá al modelo geométricamente es esa primera acción de extrusión o de
construcción de una superficie.
Toda operación de recorte parte de la previa existencia de dicho volumen o superficie y en
consecuencia irá asociada no directamente al dato del modelo sino a unas listas de
operaciones en principio vacías. Por lo tanto si se desea recortar, se añade un elemento a
una lista previamente vacía, pero asociada al modelo y si se pretende construir volumen la
operación se realiza directamente sobre el dato de tipo modelo.
Esta aclaración es importante pues lo más intuitivo de suponer es que toda operación de
modificación de volumen debería de ir asociada directamente al modelo, cosa que no ocurre
internamente.

Definiendo un eje de revolución y el perfil deseado, la operación es completada, dando lugar

a la forma base del eje.
Una vez realizada la extrusión, el siguiente paso es la adición a las secciones extremas de
los chaflanes. El motivo por el cual dicha operación es realizada en este momento es debido
a que como ya se indicó anteriormente, operaciones tales como la retirada de material a
veces dan lugar a errores internos en la creación de elementos geométrico, tales como
superficies.
Este fenómeno ha sido explicado en el apartado 4.4.4. Para evitar la acumulación de estos
posibles errores, se ha decidido primero realizar los chaflanes y posteriormente las
chavetas.
Ilustración 39: Algoritmo generación ejes.
Finalmente el proceso de generación del modelo, se termina con la adicción de las

chavetas. Actualmente dentro de las posibilidades contempladas por el programa se
encuentran las chavetas de tipo A o B, sin inclinación.
Por la imposibilidad de determinar de una forma adecuada la superficie sobre la que se

pretende establecer un plano tangente al eje, se decidió optar por la definición de un plano,
cuya posición angular respecto al origen de coordenadas es determinado por el número de
chavetas que se pretendan añadir. La separación angular será tal que estas chavetas se
encuentren equidistantes entre sí.

IMPLEMENTACIÓN
Dicho plano será posicionado a una distancia del eje principal, tal que la separación sea
igual al diámetro de la cara sobre la que se vaya a realizar el corte, siendo esta misma
controlada por un parámetro dentro de los datos del archivo Excel principal.
Sobre este plano se dibujará el perfil del tipo de chaveta indicado manteniendo este una
distancia del origen de coordenadas previamente acumulada durante la elaboración del
perfil de revolución del eje. La chaveta tomará una posición central a la cara a recortar y
finalmente se ejecuta el proceso de corte, haciendo un corte recto cuya profundidad será
igual al parámetro T1 de la chaveta. Toda chaveta posteriormente realizada, se formará
gracias a la rotación del plano descrito alrededor del eje principal del modelo.
Una vez acabado el modelo, se toma una fotografía del mismo y es guardado, iniciando el
proceso de generación del siguiente árbol. Cuando todos los arboles hayan sido generados,
sus modelos son acumulados en la colección de árboles diseñada durante la gestión de
datos.
4.8. Creación de Ruedas engranadas.
El proceso técnico de construcción de ruedas engranadas ya fue explicado en el apartado

4.4.5, el objetivo de este capítulo es explicar cuál ha sido la implementación final de dicho
algoritmo.
Se parte por lo tanto de un modelo base, sobre el que ya han sido incluidas el conjunto de
curvas mínimas necesarias para determinar el perfil del diente. Dichas curvas serán
consecuentemente modificadas a través de las dimensiones que estas ya contienen. Más
concretamente las dimensiones modificadas son, los diámetros característicos del diente y
el ángulo con el cual se controla la posición del final de la curva evolvente.
Paso previo a cualquier modificación es necesario haber actualizado los valores
paramétricos del perfil de diente en el archivo Excel encargado de esta misma tarea. Dado
que durante el proceso de construcción de las estructura de datos ya se ha contemplado
este paso, no es necesario ejecutarlo en la función de generación del modelo.
El proceso comienza estableciendo una conexión con las dimensiones encargadas de
controlar las curvas mencionadas. Para poder realizar dicha conexión el programa hace uso
de una rutina específicamente creada para ello.
GetDimensionByName(objDims, "Da")
El funcionamiento de esta rutina se basa en la comparación de los nombres de las

variables/dimensiones, localizadas en la tabla de variables, con una etiqueta que se le
asigna en la llamada. Al haber nombrado manualmente todas estas dimensiones, se conoce
por lo tanto la etiqueta con la cual estas son clasificadas. Por lo general Solid Edge asigna
etiquetas en función de que operación se realice con dichas variables y el tipo de dimensión
de estas mismas. En caso de no haber asignado etiqueta no se podría identificar que curva
se controla con las mismas.
Una vez se tiene controlada la variable a esta se le asigna el valor obtenido durante las
operaciones de lectura, cambiando automáticamente por lo tanto las dimensiones del
modelo asociadas a esta misma. Para garantizar que el cambio es efectivo, es necesario
hacer que las dimensiones sean conductoras, esto implica que la prioridad de dicha

dimensión pasa a ser mayor que los valores numéricos que definen la geometría, actual del
modelo.
Para poder obtener el perfil del diente se siguen los pasos explicados en el apartado de
generación de ruedas engranadas (apartado 4.4.5.) Como el modelo engranado va a ser
conectado a los modelos generados en el apartado anterior, se incluye en el algoritmo una
operación de recorte de material en forma de circunferencia tal que el diámetro de la misma
se corresponda con el de la sección al que ira unido.
A posteriori de haber dibujado el diente, se realiza el corte helicoidal, teniendo por longitud
de corte la misma que la rueda engranada. El resto de dientes son formados tras de haber
asociado a la circunferencia de cabeza un patrón circular.
Ilustración 40: Algoritmo generación ruedas engranadas.
Todo patrón de tipo gráfico no se encuentra asociado al modelo sino a un perfil, el cual se
encargará de definir como se repetirá dicho patrón. En el caso de un patrón circular la
operación necesita de una circunferencia que haga de trayectoria para el mismo o si fuese
lineal, de una recta. Dicho patrón representa la base en torno a la cual la operación será
repetida y solo se ejecutará el corte final, una vez se haya añadido el patrón con la
operación deseada a la lista de patrones asociada al modelo.
El uso del mismo nombre para indicar dos conceptos distintos, hace que el proceso de
definir operaciones con repetición resulte confuso. Por eso es importante entender que no
es lo mismo un patrón gráfico, que uno operacional.

IMPLEMENTACIÓN
El primero se asocia como se ha dicho a perfiles y el segundo a operaciones a realizar sobre

un modelo. Si se inicia una operación solo mediante el segundo no va a efectuar ningún
cambio, necesitará del primer tipo como apoyo para la efectuación de la misma. Los
patrones al igual que las operaciones de cambio de volumen se encuentran asociadas al
modelo, por referencia directa. Una vez finalizado el modelo se toma una imagen y el
modelo es guardado.
4.9. Función de interacción con objetos COM.
Del proceso de manejo de objetos ya explicado en apartados anteriores se destaca el

algoritmo de funcionamiento de la rutina encargada de su eliminación.
releaseObject()
Primeramente el sistema trata de hacer una asignación al objeto pasado por referencia a la
función y en caso de ser exitosa, fuerza la eliminación de la misma. En caso de no serlo no
es necesaria actuación ninguna. A pesar de ser un algoritmo muy sencillo es fundamental
que este sea efectuado, de lo contrario el peso en memoria de todas las variables de tipo
objetos utilizados no se elimina y es acumulado progresivamente hasta que se fuerce el
cierre de Solid Edge. Se recuerda que se manejan cientos de estos tipos de objetos activos
en todo momento, el omitir esta operación haría rápidamente inviable el proceso de
automatización.
4.10. Función Main.
Esta actúa como columna vertebradora de todo el proyecto. Como se ha mencionado

anteriormente no es deseable que se ejecute la generación de todos los modelos cada vez
que se inicie el módulo. En caso de que el alumno no deseé por ejemplo generar de
momento las ruedas engranadas, estas deben de ser ignoradas hasta que se dé la orden
mediante un botón. De coordinar esta capacidad se encarga la función principal.
Siguiendo el protocolo de interacción con Solid Edge explicado en la ilustración 13, se
efectúa la llamada a la función encargada de crear la estructura de datos interna.
Dependiendo de aquellos modelos que hayan sido ordenados por el usuario, se ejecutará la
función creadora de los árboles o la de las ruedas engranadas, siguiendo los algoritmos
explicados en las ilustraciones 40 y 41 respectivamente.
En el caso de las ruedas engranadas, por motivos de optimización se ha optado por
mantener separado el proceso de generación de cada una, pues es una tarea que demanda
mucho poder de procesamiento al ordenador.
Finalmente se hace una llamada a la función encargada de crear el informe PDF y el
proceso finaliza con el cierre de Solid Edge.

4.11. Release
El programa una vez acabado ha de ser adaptado para la distribución a terceros usuarios.
Visual Basic toma como estado predeterminado del programa la versión de debug, esto
significa que todavía pueden ser realizados cambios sobre la misma. Una vez se haya dado
la orden a la plataforma de considerar la aplicación creada como finalizada, se generan unos
archivos esta vez no modificables, salvo por el propio autor de los mismos.
Es fundamental destacar la importancia que tienen los paquetes de interoperabilidad. Como
explicado en el apartado 4.4.2. No se puede dar un programa por finalizado sin haber
incluido dentro de sí todas las librerías necesarias para la ejecución del mismo.
En el caso que atañe a este proyecto las librerías propias de Solid Edge han de ser
incluidas dentro del propio código junto con las de PDFSharp. Estas irán incluidas en la
carpeta generada automáticamente por Visual Basic durante la compilación del programa.
No se incluyen las librerías de
Microsoft Office debido al hecho de
que estas mismas al tratar de ser
incluidas dentro de los archivos del
programa darán lugar a fallo. El fallo
no es por accidente sino por diseño, de
esta forma Microsft se asegura que sus
productos no sean libremente
distribuidos. Al no poder incluir dichas
librerías en el programa se debe
garantizar que antes de lanzar la
versión de salida los paquetes de
interoperabilidad del mismo han sido
activados, en caso contrario no
funcionará el programa.
El código del programa estará recogido
exclusivamente en forma de un
ejecutable encargado de llamar a la
información contenida en otro archivo
de extensión .pbd. Dichos dos archivos
junto a las librerías incluidas dentro del
código constituyen los archivos que
deberán ser compartidos.
Finalmente, para almacenar todas las
imágenes obtenidas durante el
proceso de modelado, junto a las
imágenes necesarias en el informe se
ha creado una carpeta llamada bin.
Los modelos serán guardados en la
carpeta de modelos y finalmente el
informe será almacenado en su propia
Ilustración 41: Esquema funcionamiento programa. carpeta, llamada informe.

IMPLEMENTACIÓN
4.12. Algoritmos descartados.
Durante el desarrollo de todo programa informático, las soluciones finalmente elegidas no

tienen por qué constituir las únicas soluciones exploradas. En este proyecto este hecho se
ha cumplido igualmente y se pretende mostrar en este apartado algunos de los algoritmos
infructuosos más destacados.
Construcción ejes mediante conjuntos
La primera solución explorada para el desarrollo del algoritmo de generación de los ejes
paso primeramente por tratar de construir el modelo mediante la unión de sub-modelos de
forma cilíndrica.
El algoritmo inicial seguiría los siguientes pasos:
I. Se forman tantos modelos cilíndricos, como secciones haya por árbol.

II. Dichos modelos son conectados en un documento de conjunto (assembly).
III. El modelo obtenido se abriría de nuevo en un documento de pieza y se le añadirían
todos los detalles característicos de un eje motriz.
Cada cilindro sería formado por una operación de extrusión sobre un perfil circular, cuya
extensión y radios serían los correspondientes a la sección tratada. El modelo una vez
terminado, sería guardado en un archivo para ser posteriormente utilizado en un documento
de conjunto.
El desarrollo de esta solución fue conllevado hasta la finalización de este segundo paso. A
pesar de que la solución no acabó siendo finalizada sí que existió un tiempo de desarrollo y
familiarización con la generación de documentos de conjunto. Se dará a continuación una
breve explicación de cómo funciona este entorno.
A diferencia de los documentos de pieza, Solid Edge no trata los modelos que sean
introducidos en este tipo de documentos como elementos geométricos de “solidos”. Se
entiende por sólido que el modelo tiene unas barreras físicas, no traspasables, que definen
perfectamente los límites del mismo. El modelo dispone igualmente de una posición fija
respecto al eje de coordenadas global utilizado en el documento.
Esto no ocurre así en un documento de conjunto, pues los modelos pueden intersectarse
mutuamente, tomar posiciones espaciales variables y en general comportarse como
elementos incapaces de interactuar mutuamente. Nuestra interacción con los modelos
funciona por lo tanto de forma completamente distinta. Este es el concepto de “ocurrencia” u
ocurrence como es llamado internamente por Solid Edge.
Al iniciar un documento de conjunto, este se encuentra vació y es a través de la inclusión de
dichas ocurrencias como se podrán montar los modelos finales. Los modelos constitutivos
del conjunto final son introducidos en forma de ocurrencia y se establecen las restricciones
que permiten fijar los unos a los otros. En el caso planteado se consiguió elaborar un
algoritmo capaz de fijar entorno a un mismo eje todos los modelos de cada sección junto a
una restricción de coincidencia entre caras finales de la sección e iniciales de la siguiente.

Cada ocurrencia como debería de ser obvio, no representa el modelo real y por lo tanto el
resultado final del documento de conjunto no será un modelo sino una serie de ocurrencias
relacionadas mutuamente.
Este hecho hace que no pueda ser utilizado como vía para resolver el problema. Al no poder
garantizar que el resultado fuese a trabajar adecuadamente en el módulo encargado de
hacer análisis F.E.M. dicha solución tuvo que ser abandonada.
De este intento fallido se obtuvo conocimiento sobre cómo trabajar con documentos de
conjunto, como establecer restricciones entre ocurrencias y como utilizar elementos
geométricos en modelos.
Construcción de piñones sobre árboles de transmisión
Inicialmente se contempló como parte del proyecto la inclusión del tallado de los piñones en
los ejes de transmisión. El algoritmo de generación de los mismos, no podía partir en
consecuencia del mismo principio utilizado para las ruedas engranadas.
Al tener que hacer uso de modelos generados de forma automática, no se dispondría de
ninguna de las facilidades incluidas dentro de un modelo base, previamente generado a
mano como si ocurre en la formación de las ruedas. Para circunvalar dicho problema se optó
por la utilización del mismo algoritmo de formación del perfil de diente que en las ruedas
engranadas.
Una vez hubiese sido obtenido el perfil, este sería copiado a un plano, que previamente ha
sido definido en la cara horizontal anterior a la sección contenedora del piñón. Se optó
inicialmente por establecer el código necesario para disponer el plano mencionado. La
propia determinación de la cara a utilizar constituyo por si sola un gran problema en tiempo y
resolución técnica. Como ya se ha mencionado, Solid Edge a veces genera superficies de
área nula, no visibles para el usuario y cuya ordenación dentro de la lista de elementos
geométricos no puede ser controlada.
Para resolver este problema se ideó una rutina capaz de identificar la etiqueta interna
asociada a la cara deseada y por lo tanto con ello determinar la posición de esta misma en
la lista de caras.
Una vez se había concretado tanto el proceso a seguir para poder llevar a cabo el corte solo
bastaba con conseguir transferir el perfil de un documento a otro, pues se recuerda se parte
de dos modelos distintos. Es en este paso que se hizo clara una gran limitación de Solid
Edge y es que es perfectamente posible copiar una pieza en su totalidad de un documento a
otro pero no así elementos individúales de cada modelo. Esto implica que una unidad más
básica que el modelo no es transferible entre documentos y en consecuencia el proceso no
podía ser llevado a cabo mediante este algoritmo.
Por limitaciones de tiempo se optó por omitir de los objetivos planteados al proyecto, la
inclusión de los tallados sobre ejes motrices. De este proceso sin embargo se obtuvo
conocimientos sobre la selección de elementos internos de Solid Edge según su etiqueta y
de aquellas limitaciones aparentemente inexplicables que Solid Edge presenta.

IMPLEMENTACIÓN
Elaboración de informe mediante archivo .txt
Como solución temporal a la elaboración de un informe PDF para la descripción de modelos,

se optó por la construcción de una rutina capaz de copiar este mismo proceso en un formato
más simple, el de los documentos de texto predeterminados de Windows.
Dicha rutina no necesita de la adquisición de ninguna nueva librería aparte de las ya dispo-
nibles con el sistema operativo. La formación de este tipo de archivos, se realiza mediante
sucesivas operaciones de escritura siguiendo un formato de texto conocido. Esta solución se
corresponde con una alternativa menos atractiva visualmente pero igualmente útil a la des-
crita solución final de este proyecto.

5. RESULTADOS
En este apartado se adjuntan los resultados obtenidos por el programa diseñado. Para po-
der mostrar el correcto funcionamiento del mismo se introducirán los valores paramétricos
utilizados en un trabajo del año anterior.
Ilustración 42: Portada Informe

RESULTADOS
Ilustración 43: Informe Árbol 1.


RESULTADOS

Ilustración 46: Informe Rueda 1.

RESULTADOS
Ilustración 47: Informe Rueda 2.

6. CONCLUSIONES Y LINEAS FUTURAS
A la vista de los resultados obtenidos, se consideran los objetivos marcados al principio de

este documento como cumplidos y se ofrecerá una visión detallada de los mismos punto por
punto junto con una breves descripción de cuáles constituyen las líneas futuras de desarro-
llo, puntos a mejorar o posibles optimizaciones del programa.
6.1. Conclusiones
En este apartado se ofrece un breve inciso en aquellos aspectos de mayor importancia de

cara a la final consecución del proyecto y un seguimiento de los objetivos que fueron marca-
dos al inicio de este texto.
6.1.1. Didáctica
Este bloque a pesar de no ser el objeto de estudio principal del proyecto sí que constituye
una meta fundamental para considerar el proyecto como exitoso. El punto de vista del estu-
dio ha de realizarse teniendo presente la posible implementación del trabajo realizado en las
clases de la asignatura de Diseño de Maquinas I.
Con este proyecto se pretendía ofertar al alumno de una herramienta que le permitiera ad-
quirir conocimientos de una forma más rápida y efectiva. Este proceso de aprendizaje de-
pende de la capacidad que tenga el alumno de verificar rápidamente las soluciones obteni-
das. Mediante la lectura del informe el alumno es capaz de obtener una representación
aproximada de cuales han sido los resultados a nivel de modelo, junto con la posibilidad de
chequear rápidamente que datos han sido introducidos.
Una vez aprobada la comprobación visual, el chequeo de la solución obtenida dependerá a
continuación de su validación por análisis FEM. Como el objetivo marcado es permitir al
alumno un flujo rápido de información entre las tareas de comprobación y diseño, se puede
considerar que los resultados obtenidos han sido satisfactorios.
Dado que la elaboración de modelos de alta complejidad tales como las ruedas engranadas
se reducen a la mera incorporación de detalles, el tedioso proceso de su construcción es
eliminado. De esta forma se permite al alumno utilizar el tiempo anteriormente reservado a
la elaboración de los documentos CAD en la mejor comprobación y validación de los con-
ceptos enseñados en la asignatura.
Finalmente como la comprobación de los diseños obtenidos se realiza mediante un informe,
este mismo vale como medio de comunicación entre equipos, permitiendo establecer un
proceso de mejora mutua o también llamado peer-learning.

CONCLUSIONES Y LINEAS FUTURAS
6.1.2. Optimización
Desde el punto de vista de la optimización la parte fundamental del trabajo irá destinada a
garantizar un rápido proceso de generación.
Tomando como referencia las herramientas habilitadas por Solid Edge para la elaboración
de ejes o engranajes, se puede comprobar que el algoritmo diseñado efectua el mismo tra-
bajo más rápidamente. Esto es especialmente notable cuando se trata de las ruedas engra-
nadas.
En consecución dado que el proyecto elaborado se demuestra a la altura de lo esperable
por un producto comercial, podemos afirmar que el programa ha sido satisfactoriamente
optimizado.
6.1.3. Solid Edge como plataforma
El proyecto planteado ha visto el número de funcionalidades y limpieza del informe presen-

tado limitadas, debido a la falta de tiempo para una mejor consecución del mismo.
Solid Edge se ha demostrado como una plataforma altamente personalizable y muy modu-
lar, en la cual proyectos de automatización de alta complejidad como este mismo son reali-
zables. Ahora bien dicha plataforma dispone no de pocos errores o administraciones inter-
nas poco lógicas o intuitivas y existe una falta de material de apoyo muy importante.
6.1.4. Seguimiento de objetivos.
En lo relativo a los objetivos inicialmente planteados, se puede afirmar con total seguridad
que los siguientes objetivos han sido cumplidos en su totalidad:
Objetivo B: Estudio de la herramienta de trabajo en la API Solid Edge ST10 de cara usos
futuros.
Objetivo C: Verificación e integración de la herramienta diseñada en software EDIMPO.
Objetivo D: Actualización de los modelos creados de una forma eficiente y en la que la inter-
acción del usuario con Solid Edge se limite a la modificación de datos en el programa princi-
pal.
Objetivo E: Elaboración de auto-documento PDF de modelos y parámetros de especial im-
portancia para los mismos.
Finalmente se considera como parcialmente cumplido el objetivo:
Objetivo A: Creación automática de modelos 3D de árboles motrices y ruedas engranadas
en reductoras.
Al no poder integrarse el tallado de los dientes en los ejes engranajes, no se puede conside-
rar como completo en su totalidad, pero como objetivo principal del trabajo se puede afirmar
que ha sido cumplido satisfactoriamente.

6.2. Líneas Futuras
En este apartado se presentan brevemente que posibles mejoras y líneas futuras están
abiertas para la continuación de este proyecto.
Debido a que el proyecto se ha fundamentado en un campo, carente de suficiente documen-
tación y ha implicado un proceso de aprendizaje muy intenso en Visual Basic, lenguaje pre-
viamente desconocido, gran parte del tiempo utilizado para la consecución del mismo se ha
destinado al aprendizaje y resolución de errores inesperados.
Un ejemplo de las limitaciones que esto ha supuesto se encuentra fácilmente en la genera-
ción de piñones dentro de los objetivos del proyecto es debido a la existencia de errores
internos en Solid Edge. Por eso mismo, partiendo de la base explicada y ya programada en
este proyecto la final consecución de dicho objetivo no resulta especialmente complicada, el
motivo por el cual no se llevó a cabo fue por una limitación temporal.
Se puede añadir como objetivo la inclusión de los modelos generados dentro de un docu-
mento de conjunto y la formación de lo que constituirían las bases del modelo final.
Como objetivos de líneas futuras se plantean los siguientes:

 Tallado de piñones sobre arboles generados.
 Adición de la posibilidad de construir secciones de pendiente no nula.
 Adición de elementos mecánicos ISO sobre los modelos de ejes motrices tales como
rodamientos.
 Generación de árboles estriados.
 Generación de Macro en Python para la captura de imágenes renderizadas de los
modelos.

REFERENCIAS, ILUSTRACIONES Y ANEXOS
7. ANEXOS
Ilustración 48: Esquema interno de librerías y objetos Solid Edge.

8. TABLA DE ILUSTRACIONES
Ilustración 1: Rueda Engranada. ............................................................................................2

Ilustración 2: Eje de transmisión .............................................................................................2
Ilustración 3: Arquitectura EDIMPO 2018 .............................................................................10
Ilustración 4: Guía de actuación. ..........................................................................................16
Ilustración 5: Tipos de proyectos predefinidos ......................................................................19
Ilustración 6: Spy for Solid Edge ...........................................................................................22
Ilustración 7: Librerías Solid Edge. .......................................................................................24
Ilustración 8: Modo de operación SE ....................................................................................25
Ilustración 9: Protocolo de actuación sobre documentos ......................................................26
Ilustración 10: Diagrama de lógica del módulo de generación paramétrica...........................27
Ilustración 11: Interfaz módulo. .............................................................................................29
Ilustración 12: Ejemplo de división por objetos .....................................................................32
Ilustración 13: Esquema de datos.........................................................................................33
Ilustración 14: Propiedades de un objeto ..............................................................................35
Ilustración 15: Función constructora .....................................................................................35
Ilustración 16: Diagrama creación objetos ............................................................................36
Ilustración 17: Función creadora ..........................................................................................36
Ilustración 18: Objetos y sus parámetros ..............................................................................37
Ilustración 19: Dimensiones chavetas. .................................................................................38
Ilustración 20: Curva Evolvente y circunferencias de engrane. .............................................40
Ilustración 21: Perfil de engrane. ..........................................................................................41
Ilustración 22: Estructura interna de perfiles en un documento. ............................................47
Ilustración 23: Ejemplo Eje producido por programa.............................................................52
Ilustración 24: Ejemplo Rueda generada por programa. .......................................................54
Ilustración 25: Intersección evolvente y diámetro primitivo. ..................................................57
Ilustración 26: Puntos a conectar manualmente ...................................................................58
Ilustración 27: Ejemplo perfil a recortar ................................................................................59
Ilustración 28: Perfil finalizado. .............................................................................................61
Ilustración 29: Modelo de informe. ........................................................................................62

REFERENCIAS, ILUSTRACIONES Y ANEXOS
Ilustración 30: Ejemplo PDFSharp ........................................................................................63

Ilustración 31: Espacio de nombres functions y sus campos. ...............................................65
Ilustración 32: Algoritmo apertura SolID Edge ......................................................................66
Ilustración 33: Protocolo de almacenamiento. ......................................................................67
Ilustración 34: Lectura del archivo principal ..........................................................................69
Ilustración 35: Organización interna de objetos ....................................................................71
Ilustración 36: Problema listas anidadas...............................................................................71
Ilustración 37: Perfil de árbol de transmisión .......................................................................73
Ilustración 38: Operaciones sobre Volumen en Solid Edge. .................................................74
Ilustración 39: Algoritmo generación ejes. ............................................................................75
Ilustración 40: Algoritmo generación ruedas engranadas. ....................................................77
Ilustración 41: Esquema funcionamiento programa. .............................................................79
Ilustración 42: Portada Informe.............................................................................................83
Ilustración 43: Informe Árbol 1. .............................................................................................84
Ilustración 46: Informe Rueda 1. ...........................................................................................87
Ilustración 47: Informe Rueda 2. ...........................................................................................88
Ilustración 48: Esquema interno de librerías y objetos Solid Edge. .......................................92

9. REFERENCIAS BIBLIOGRÁFICAS
1. Foxall JD. VISUAL BASIC 2012: Paso a paso. Anaya Multimed. 2012;(ISBN 10: 8441533474 /
ISBN 13: 9788441533479).
2. Som G. Curso de iniciación a la programación con Visual Basic.
3. Mauer L, St E. More Visual Basic . NET in. East.
4. Edge S, Api ST. . NET Programmer ’ s Guide. 2015;193.
5. Siemens Product Lifecycle Management Software Inc. Solid Edge fundamentals. 55 p.
6. Blog: Undocumented Matlab (2018). http://undocumentedmatlab.com/blog/running-vb-code-
in-matlab. Último acceso 21/06/2018.
7. Foro: Página Web Siemens, Solid Edge Blog (2018). https://community.plm.automation.
siemens.com/t5/Solid-Edge-Blog/bg-p/solid-edge-news. Último acceso 21/06/2018.
8. Página Web, Solid Edge Community (2018), https://github.com/SolidEdgeCommunity. Último
acceso 14/02/2018.
9. Página Web, PDFSharp and Migradoc Wiki (2018), http://www.pdfsharp.net/wiki/. Último
acceso 24/04/2018.

TFG Borja Jesus Fernandez Lopez

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG Borja Jesus Fernandez Lopez

Cargado por

Copyright:

Formatos disponibles

Desarrollo de software para la

Borja Fernández López

TRABAJO FIN DE GRADO PARA Borja Fernández López

Borja Fernández López 1

Ilustración 2: Eje de transmisión.

Ilustración 1: Rueda Engranada.

331002, 331309, 331315, 330323, 120309, 120310, 120326.

2 Escuela Técnica Superior de Ingenieros Industriales (UPM)

Borja Fernández López 3

4 Escuela Técnica Superior de Ingenieros Industriales (UPM)

Borja Fernández López 5

6 Escuela Técnica Superior de Ingenieros Industriales (UPM)

Actualmente el mundo educativo hace cada día un mayor hincapié en la necesidad de

8 Escuela Técnica Superior de Ingenieros Industriales (UPM)

Borja Fernández López 9

Ilustración 3: Arquitectura EDIMPO 2018

En la Ilustración 3 explica de una forma sencilla el proceso de intercambio de información

10 Escuela Técnica Superior de Ingenieros Industriales (UPM)

Las funcionalidades que se pretenden añadir mediante este módulo se corresponden a:

2.1. Motivación Académica

Borja Fernández López 11

2.2. Motivación Personal

12 Escuela Técnica Superior de Ingenieros Industriales (UPM)

El módulo a crear ha de ser ante todo momento un elemento de software de ámbito

Objetivo A.1: Elaboración de algoritmo de generación de árboles motrices y sus

Objetivo B.1: Adquirir conocimientos de programación en software Solid Edge PLM.

OBJETIVO C: Verificación e integración de la herramienta diseñada en software EDIMPO.

OBJETIVO D: Actualización de los modelos creados de una forma eficiente y en la que la

OBJETIVO E: Elaboración de auto-documento PDF de modelos y parámetros de especial

Borja Fernández López 13

3.1. Planificación temporal

14 Escuela Técnica Superior de Ingenieros Industriales (UPM)

El proyecto ha seguido la relación de presupuesto presentada en la siguiente tabla:

Concepto Coste unitario N.º Unidades TOTAL

Borja Fernández López 15

Para la realización de este proyecto se ha planteado la siguiente guía de actuación como

Ilustración 4: Guía de actuación.

A continuación se explicaran las bases de trabajo en torno a las cuales se fundamenta el

16 Escuela Técnica Superior de Ingenieros Industriales (UPM)

4.1. Proceso de recogida de datos e Investigación previa

Borja Fernández López 17

4.2. Recursos necesarios

4.2.1. Microsoft Visual Basic .Net 2017

El entorno de programación de Microsoft Visual Basic, es una herramienta que permite a un

18 Escuela Técnica Superior de Ingenieros Industriales (UPM)

El uso de estos módulos se

La interacción con los mencionados bloques se lleva a cabo mediante asignaciones de

Borja Fernández López 19

4.2.2. Solid Edge ST9/ST10

El entorno de diseño en 3D de Siemes PLM Software o Solid Edge, es un sistema de diseño

20 Escuela Técnica Superior de Ingenieros Industriales (UPM)

4.2.3. Microsoft Office Excel

Microsoft Office es un paquete de programas de edición de texto, cálculo y organización en

4.2.4. Mathworks Matlab

La plataforma de cálculo numérico Matlab de Mathworks fue originalmente diseñada bajo la

De cara a este proyecto la interacción con el mismo se limitará a la elaboración de una

Borja Fernández López 21

Es sin embargo importante tener en cuenta las capacidades y limitaciones de la propia

4.2.5. Spy for Solid Edge

Esta aplicación constituye una herramienta indispensable para la programación de cualquier

Ilustración 6: Spy for Solid Edge

Es una aplicación de código libre desarrollado como parte de un esfuerzo comunitario. La