¿Qué es iLogic?

La mayoría de las personas que utilizan algún tipo de aplicación de escritorio entienden lo que es la automatización. Si utiliza Microsoft Excel, probablemente haya oído hablar de las macros o secuencias automatizadas que se crean y se diseñan en Excel para llevar a cabo tareas específicas. Inventor Automation es algo parecido en el sentido de que la automatización puede adoptar distintas formas, básicamente, se trata de una secuencia o una serie de secuencias que permiten realizar automáticamente una tarea, un proceso o una función específicas. iLogic es parte de Inventor Automation.

iLogic es una función de Inventor que permite a los usuarios y administradores desarrollar lógica en el lenguaje VB.net para completar tareas. Para ello, se crean reglas que se organizan mediante el uso de fragmentos y otras instrucciones de escritura de código con el fin de ejecutarse en momentos determinados y realizar sistemáticamente parte del trabajo que deben hacer ingenieros y diseñadores.

Se podría crear un grupo de reglas de iLogic para completar tareas como actualizar las iProperties según diferentes criterios relacionados con el modelo o sustituir los componentes de un ensamblaje en función de las opciones seleccionadas en un formulario de iLogic, o incluso actualizar bloques de texto en un dibujo asociado. La lista de las tareas que iLogic puede hacer es larga. La pregunta es: ¿Qué desea hacer con iLogic?

¿Por qué debería usar iLogic?

Ahora que ya sabemos lo que es iLogic, veamos los motivos por las que debería incorporarlo a sus procesos de ingeniería.

En primer lugar, a lo largo de mi experiencia trabajando con fabricantes grandes y pequeños de todo el mundo que desarrollan una gran variedad de productos, hay una cosa que siempre es cierta: en todos los entornos se repiten patrones y tareas. La clave radica en identificar los patrones y las tareas en los que iLogic puede ser útil. Este simple cometido pasa por conocer bien todos los aspectos de su proceso de trabajo en los que interviene Inventor.

Pongamos, por ejemplo, que usa un formato específico para una descripción de iProperty de sus modelos 3D o cualquier otra iProperty con la misma finalidad. Si el formato es predecible y está normalizado, iLogic puede ser útil. Podría desarrollar lógica para obtener información del modelo, transformar esa información y sobrescribir las iProperties con la información adecuada que tiene un nuevo formato. Siempre será correcta, coherente y estará disponible.

Información relacionada: Alcanzar un nivel superior: automatización de dibujos mediante Autodesk Inventor, con Thomas Fitzgerald

Configuración de Inventor para usar iLogic

¿Cómo se debe configurar Inventor para usar iLogic eficazmente?

Aunque iLogic está incluido en Inventor y se puede empezar a usar inmediatamente, hay que prestar atención a algunos parámetros para obtener el máximo partido de iLogic. El botón de configuración de iLogic permite a los usuarios configurar varios parámetros para determinar dónde encontrará Inventor información complementaria.

configuración

Los usuarios y administradores querrán modificar estos parámetros para indicar a Inventor dónde encontrar los directorios de reglas externas y especificar el orden prioritario de esos directorios. Además, los usuarios pueden establecer la ubicación de directorio en la que Inventor encontrará las bibliotecas de enlace dinámico (DLL). Las DLL son archivos de salida de Microsoft Visual Studio que se utilizan para desarrollar interfaces de usuario personalizadas con el objetivo de accionar y activar las reglas de iLogic y otro tipo de lógica.

El cuadro de diálogo de parámetros permite a los usuarios establecer la extensión de archivo con la que se guardarán las reglas externas y el nivel de registro predeterminado en el que se puede generar información de depuración. También hay algunas opciones de seguridad para proteger los sistemas de red e informáticos frente a código potencialmente dañino que se ejecute en el entorno de Inventor. Más adelante se ofrece información complementaria sobre las reglas externas y la depuración.

Reglas internas y reglas externas

¿Cuáles debo utilizar y cuándo?

Las reglas de iLogic pueden ser internas y externas. Ambos tipos de reglas se crean de la misma forma en el marco de Inventor, en el Navegador de iLogic.

navegador

Las reglas internas se crean y se almacenan en el contexto de un archivo. Los archivos de pieza, ensamblaje o dibujo permiten almacenar, compilar y ejecutar reglas que afectan a cada archivo de forma diferente. Las reglas externas son muy parecidas, pero no se almacenan en archivos de Inventor. Como las reglas internas se almacenan en archivos, están expuestas a los usuarios que tienen permisos para acceder a esos archivos. Las reglas externas se almacenan en un directorio, ya sea de forma local en el sistema de un usuario o de forma centralizada en un servidor, con independencia de la ubicación geográfica.

Dado que las reglas externas se almacenan en una carpeta fuera de los archivos, el nivel de seguridad de estas reglas puede ser mayor. Los usuarios pueden abrir y ver el código de la regla, pero los administradores establecen quién tiene acceso y puede editarlas mediante la definición de permisos específicos en la carpeta de reglas externas. Por esto motivo, en un entorno corporativo en el que es posible que muchos usuarios necesiten ejecutar código durante el proceso de diseño, es preferible utilizar reglas externas. Si las circunstancias no hacen necesario regular los permisos o si no hay demasiados usuarios que necesiten utilizar la lógica de reglas al mismo tiempo, las reglas internas podrían servir.

Ambos tipos de reglas están visibles en el Navegador de iLogic, tal como se puede observar en las siguientes imágenes.

reglas

Hacer clic con el botón derecho en uno de los dos tipos de reglas permite controlar funciones como suprimir o cancelar la supresión de reglas con el fin de determinar cuándo se deben activar, eliminar reglas o quitar de la lista.

Parámetros y propiedades

¿Cómo se deberían usar?

Autodesk Inventor es una "aplicación 3D de diseño paramétrico". Pero ¿qué significa esto? Los parámetros son marcadores de posición de valores con nombre que responden a un tipo específico. La mayoría de los parámetros de Inventor son de tipo numérico y están asociados a dimensiones que controlan la geometría. Cuando los valores de los parámetros cambian, las dimensiones asociadas a esos parámetros también cambian y los modelos se actualizan gráficamente. En Inventor hay cuatro tipos de parámetros:

1) Parámetros de modelo

2) Parámetros de usuario

3) Parámetros de referencia

4) Parámetros vinculados

Los parámetros de modelo se crean con el funcionamiento normal de Inventor. En el cuadro de diálogo Parámetros, se designan de forma automática como d0, d1, d2, etc. Inventor controla los parámetros de modelo, lo que significa que el sistema los crea y elimina según sea necesario.

Los parámetros de usuario los crean los usuarios. Estos parámetros pueden ser numéricos, de texto o cadena, verdaderos o falsos, o booleanos. Los parámetros de usuario tienen especial importancia porque los crean los usuarios, se utilizan en varias operaciones y en el código de iLogic, y no se crean ni se eliminan como consecuencia del funcionamiento normal de Inventor.

Nota: La creación de parámetros de usuario mediante una convención de nomenclatura y un tipo es el método preferido para usar información de los parámetros en las reglas de iLogic. Aunque se puede cambiar el nombre de los parámetros de modelo, este método no es recomendable.

Los parámetros de referencia se crean cuando Inventor define una cota de referencia. Es posible que alguna vez haya visto este cuadro de diálogo al trabajar en el entorno de boceto:

boceto

Si selecciona Aceptar en este caso, se creará un parámetro de referencia. El cuadro de diálogo Parámetros, se verá el nombre y el valor del parámetro, pero el valor no podrá cambiar. Sí se puede cambiar el nombre. Esto es útil para usar el valor en el código de iLogic.

Los parámetros vinculados se suelen asociar a Inventor desde una hoja de cálculo de Excel. Cuando un usuario cambia los nombres y valores en la hoja de cálculo de Excel, esos cambios se reflejan en Inventor. Esto da lugar a que se generen valores de cotas, se establezca el control de funciones, se gestionen ensamblajes, etc.

Las propiedades, o iProperties en el lenguaje Lingo de Inventor, son descriptores adicionales u otro tipo de información importante sobre los archivos del usuario. En ocasiones, se les conoce como metadatos. Las propiedades no son algo nuevo y pueden ser muy útiles cuando se pretende obtener muchos datos sobre los archivos. El nombre de archivo, el tamaño, el autor o la fecha de modificación son propiedades. La mayoría de las veces, cuando se trabaja con datos de archivos de iLogic e Inventor, el nombre y la ruta del archivo son las dos propiedades que se usan más. Otras propiedades frecuentes son el número de pieza, el número de almacenamiento, la descripción, la masa, el coste y las propiedades personalizadas. Todas las propiedades son de lectura, y la mayoría están habilitadas para la escritura.

Declaración de variables, preasignación y variables compartidas

¿Qué importancia tiene usar esta jerga de codificación?

iLogic es código, simple y llanamente. Aunque no haya que ser programador ni saber escribir código, conocer algunos aspectos básicos de la escritura de código será muy útil. Esto se debe a que hay algunas normas que todos los programadores entienden. La declaración de variables y la preasignación forman parte de esas normas. ¿Por qué es esto importante? Bueno, es como hablar un idioma. Tener una norma elimina parte de la dificultad a la hora de escribir lógica.

Declaración de variables y preasignación

La declaración de variables es en realidad muy sencilla. En iLogic, solo hay que escribir un nombre y asignarle un valor:

Length = 20

Una vez que tenemos la variable, podemos utilizarla de varias maneras. Podemos leer el valor y procesarlo en un cálculo o escribir en él para actualizar otro elemento. Aunque iLogic admite la escritura de un par formado por un nombre y un valor, según las prácticas recomendadas de escritura de código es mejor escribir el nombre, asignarle un "tipo" y proporcionar un valor:

Dim Length As Double = 20

Esta expresión indica a iLogic que cree una variable que solo conserve un valor "Double" y luego lo proporciona. Esto se denomina "preasignación" y garantiza que solo se pueda proporcionar un valor específico a la variable. Si intentáramos proporcionar un valor de cadena o texto a la variable Length, el código generaría un error. Por lo que he podido comprobar, al proporcionar un tipo se puede emplear código mucho más complejo en las reglas, además de entender y visualizar el flujo de información. Por ejemplo, si escribimos una instrucción en una regla que genera un cálculo matemático y recibimos un error, sabremos que las variables de tipo "String" o cadena no generan el error.

A continuación, se incluyen ejemplos de declaración de variables y preasignación:

Dim cylinderHeight As Double = Parameter("CylinderHeight")
Dim fileName As String = "This is a string value!"
Dim holeCount As Integer = 2
Dim occurrenceName As String = String.Empty
Dim plateWidth As Double = Nothing

En los últimos dos ejemplos, no se ha proporcionado un valor, o más bien el valor está vacío. Habrá ocasiones en las que sea necesario declarar una variable, pero aún no sepamos el valor. En este caso, para mantener la coherencia es posible declarar la variable, la preasignación y poner algo al otro lado del signo igual. Esto también es útil para depurar el código y comprobar si algún valor se proporciona o no mediante programación.

Si se ha prestado atención, también se habrá observado que en el primer ejemplo se declaró una variable, una preasignación y el valor se estableció para que coincidiera con el valor de un parámetro de usuario. Este método es útil para construir la lógica necesaria para los cálculos, transferir valores a otros elementos y modificar otros parámetros. También es útil cuando tenemos que obtener o establecer el valor del parámetro de usuario con rapidez, es decir, cuando el código lo requiere. Esta es la razón por la que los usuarios nuevos de iLogic tienen problemas cuando ejecutan reglas y esperan un comportamiento específico, pero Inventor parece ir un paso por detrás. Consulte los siguientes ejemplos:

cylinderHeight = CylinderHeight
Dim cylinderHeight As Double = Parameter("CylinderHeight")

Ambas instrucciones hacen algo parecido, pero no lo mismo. El primer ejemplo declara una variable que podría ser de cualquier tipo, con un valor que es igual al parámetro de usuario. Como el color del texto es azul, Inventor reconoce el parámetro de usuario. Debido a que Inventor reconoce el parámetro de usuario, cualquier regla cuya supresión se cancele utilizando este formato se ejecutará automáticamente. Puede que deseemos o no ejecutar las reglas de esta forma.

Esto también significa que la variable especificará el valor del parámetro de usuario en el momento de la última actualización. Si la lógica hubiera cambiado el valor del parámetro de usuario en el intervalo de tiempo transcurrido entre el momento en que la variable necesita el valor y la última actualización, el valor del parámetro de usuario estaría desfasado. Este es el motivo por el que se necesita una actualización y, en ocasiones, varias actualizaciones aparentemente, para obtener el resultado deseado.

Para abordar este problema, es posible hacer dos cosas. En primer lugar, utilizar la segunda instrucción. Al declarar la variable, la preasignación y usar la función "Parámetro", la variable se establecerá para coincidir directamente con el valor del parámetro de usuario, garantizando así que el valor esté actualizado. Esto permite tener un mayor control sobre cuándo se ejecutan las reglas. En segundo lugar, se usa el fragmento de código de iLogic "RuleParametersOutput()". De este modo, los parámetros del usuario se mantendrán actualizados. Posteriormente se lleva a cabo una actualización para que los modelos asociados también estén al día.

Variables compartidas

Anteriormente, hablamos sobre las prácticas recomendadas para escribir código de variables, pero las variables compartidas son una función de iLogic. Al declarar una variable en una regla de iLogic, esa variable solo es accesible en el contexto de la regla. Si necesita crear una variable y establecer un valor para utilizarlo en varias reglas, las variables compartidas son la solución.

En el panel de fragmentos del editor de reglas de iLogic, encontrará las funciones de variables compartidas en el índice de variables.

Para usar las variables compartidas, se sigue un procedimiento similar al de declarar otras variables. En primer lugar, declarar la variable compartida y después asignarle un nombre y un valor. El valor puede ser estático, o bien coincidir con el de otra variable, parámetro o propiedad.

SharedVariable("VariableName") = "This is the value" SharedVariable("cylinderHeight") = Parameter("CylinderHeight")

Una vez que se ha declarado una variable compartida y se ha proporcionado un valor, se podrá utilizar y actualizar según sea necesario.

Dim cylinderHieght As Double = SharedVariable("cylinderHeight")

Las demás funciones de variables compartidas se usarán para determinar si existe una variable compartida o para eliminar de la memoria una o todas las variables compartidas.

Bucles y expresiones condicionales

¿Es necesario siempre que una persona tome una decisión?

Cuando interactuamos con Inventor, tenemos la ventaja de poder mirar la ventana gráfica y seleccionar la geometría para decidir lo que hacer con ella. En un ensamblaje, es posible entender cómo se interrelacionan los componentes. Cuando empezamos a mirar las reglas de iLogic, a veces es necesario definir el proceso de toma de decisiones entendiendo las diferentes condiciones que pueden darse en un diseño. El uso de expresiones que definen las diferentes condiciones es una manera de que los usuarios de iLogic completen esas tareas.

La expresión condicional más común es "If Then". Es similar al siguiente ejemplo:

If someValue = True Then
'Do Something
Else
'Do Something Else
End If

En el código, comprobamos si se cumple una condición y, en caso afirmativo, el código hará algo. Si la condición no se cumple o es otra, el código hará algo diferente. Esta funcionalidad se puede ampliar para identificar numerosas condiciones, como las siguientes:

If someValue = True Then
'Do Something
ElseIf someValue = False Then
'Do Something Else
ElseIf someValue = Nothing Then
'Yet Do Something Else
End If

Todo esto parece fácil y tiene sentido, pero hay un límite. Podríamos esperar que las condiciones se mantuvieran indefinidamente, pero a partir de cierto punto, es complicado saber lo que sucede realmente. En concreto, cuando empezamos a añadir otros operadores. En mi opinión, una vez que se han producido tres o cuatro condiciones, hay otras alternativas mejores para abordar la situación.

Otra expresión condicional común es el método "Select Case". Funciona de forma parecida, pero es más fácil de leer y entender. Además, requiere menos código. La expresión "Select Case" es similar al ejemplo siguiente:

Select Case someValue
Case True
'Do Something
Case False 'Do Something Else
Case Nothing
'Yet Do Something Else End Select

Como se puede observar, es más fácil de entender y de adaptar al número de condiciones que es necesario incluir.

Una de las principales metodologías utilizadas para escribir código se basa en el concepto de "bucles". Si utilizamos el ejemplo de iteración a través de un ensamblaje para obtener los nombres de las incidencias, los bucles permiten recorrer todas las incidencias sin necesidad de saber cuántas hay. El desarrollo de código y lógica tienen que ver con conocer los patrones, con la coherencia y con la previsibilidad. Existen métodos que se pueden usar en ocasiones para abordar la falta de previsibilidad. Los bucles son uno de esos métodos. A continuación, se incluye un ejemplo de un bucle "For Next":

Dim counter As Integer = 3
For t As Integer = 1 To counter
MessageBox.Show("Number of Iterations: " & t)
Siguiente

En el ejemplo, se ha definido el punto inicial del bucle en "1". También se ha definido el punto final del bucle, cuyo valor es "3". Esto quiere decir que el bucle se iterará tres veces para generar un cuadro de mensaje. Si no conocemos el punto final del bucle, podemos contar los elementos de una colección y hacer que ese número sea nuestro punto final. Consulte este ejemplo:

Dim items As New List(Of String)
items.Add("Pizza")
items.Add("Sandwich")
items.Add("Milk")
items.Add("Eggs")

For i = 0 To (items.Count - 1)
MessageBox.Show(items(i))
Siguiente

En el ejemplo, se ha creado una colección, se han rellenado los datos y se ha informado al bucle para que se itere tantas veces como elementos contenga la colección. Como se puede observar, el bucle comienza con el valor 0 y finaliza con -1. Esta es una de esas situaciones en las que es importante entender la indexación. La indexación consiste en identificar un punto inicial, que suele ser 0 o 1. En este tipo de colección, el primer elemento de la lista empieza con 0, no con 1.

Thomas Fitzgerald es consultor sénior de implementaciones y se especializa en Inventor Automation y en gestión de datos. Thomas ha consultado a muchas empresas, con departamentos de ingeniería de todos los tamaños. Tiene más de 20 años de experiencia con los productos de Autodesk en los sectores de diseño mecánico y fabricación. Posee la certificación del programa Autodesk Certified Instructor, además de ser administrador de sistemas certificado por Microsoft.

¿Desea recibir más información? Descargue el documento completo de la clase para seguir leyendo.