Experiences with Developing a “Somewhat Large” ACT Extension in ANSYS

With each release of ANSYS the customization toolkit continues to evolve and grow.  Recently I developed what I would categorize as a decent sized ACT extension.    My purpose in this post is to highlight a few of the techniques and best practices that I learned along the way.

Why I chose C#?

Most ACT extensions are written in Python.  Python is a wonderfully useful language for quickly prototyping and building applications, frankly of all shapes and sizes.  Its weaker type system, plethora of libraries, large ecosystem and native support directly within the ACT console make it a natural choice for most ACT work.  So, why choose to move to C#?

The primary reasons I chose to use C# instead of python for my ACT work were the following:

  1. I prefer the slightly stronger type safety afforded by the more strongly typed language. Having a definitive compilation step forces me to show my code first to a compiler.  Only if and when the compiler can generate an assembly for my source do I get to move to the next step of trying to run/debug.  Bugs caught at compile time are the cheapest and generally easiest bugs to fix.  And, by definition, they are the most likely to be fixed.  (You’re stuck until you do…)
  2. The C# development experience is deeply integrated into the Visual Studio developer tool. This affords not only a great editor in which to write the code, but more importantly perhaps the world’s best debugger to figure out when and how things went wrong.   While it is possible to both edit and debug python code in Visual Studio, the C# experience is vastly superior.

The Cost of Doing ACT Business in C#

Unfortunately, writing an ACT extension in C# does incur some development cost in terms setting up the development environment to support the work.  When writing an extension solely in Python you really only need a decent text editor.  Once you setup your ACT extension according to the documented directory structure protocol, you can just edit the python script files directly within that directory structure.  If you recall, ACT requires an XML file to define the extension and then a directory with the same name that contains all of the assets defining the extension like scripts, images, etc…  This “defines” the extension.

When it comes to laying out the requisite ACT extension directory structure on disk, C# complicates things a bit.  As mentioned earlier, C# involves a compilation step that produces a DLL.  This DLL must then somehow be loaded into Mechanical to be used within the extension.  To complicate things a little further, Visual Studio uses a predefined project directory structure that places the build products (DLLs, etc…) within specific directories of the project depending on what type of build you are performing.   Therefore the compiled DLL may end up in any number of different directories depending on how you decide to build the project.  Finally, I have found that the debugging experience within Visual Studio is best served by leaving the DLL located precisely wherever Visual Studio created it.

Here is a summary list of the requirements/problems I encountered when building an ACT extension using C#

  1. I need to somehow load the produced DLL into Mechanical so my extension can use it.
  2. The DLL that is produced during compilation may end up in any number of different directories on disk.
  3. An ACT Extension must conform to a predefined structural layout on the filesystem. This layout does not map cleanly to the Visual studio project layout.
  4. The debugging experience in Visual Studio is best served by leaving the produced DLL exactly where Visual Studio left it.

The solution that I came up with to solve these problems was twofold.

First, the issue of loading the proper DLL into Mechanical was solved by using a combination of environment variables on my development machine in conjunction with some Python programming within the ACT main python script.  Yes, even though the bulk of the extension is written in C#, there is still a python script to sort of boot-load the extension into Mechanical.  More on that below.

Second, I decided to completely rebuild the ACT extension directory structure on my local filesystem every time I built the project in C#.  To accomplish this, I created in visual studio what are known as post-build events that allow you to specify an action to occur automatically after the project is successfully built.  This action can be quite generic.  In my case, the “action” was to locally run a python script and provide it with a few arguments on the command line.  More on that below.

Loading the Proper DLL into Mechanical

As I mentioned above, even an ACT extension written in C# requires a bit of Python code to bootstrap it into Mechanical.  It is within this bit of Python that I chose to tackle the problem of deciding which dll to actually load.  The code I came up with looks like the following:

Essentially what I am doing above is querying for the presence of a particular environment variable that is on my machine.  (The assumption is that it wouldn’t randomly show up on end user’s machine…) If that variable is found and its value is 1, then I determine whether or not to load a debug or release version of the DLL depending on the type of build.  I use two additional environment variables to specify where the debug and release directories for my Visual Studio project exist.  Finally, if I determine that I’m running on a user’s machine, I simply look for the DLL in the proper location within the extension directory.  Setting up my python script in this way enables me to forget about having to edit it once I’m ready to share my extension with someone else.  It just works.

Rebuilding the ACT Extension Directory Structure

The final piece of the puzzle involves rebuilding the ACT extension directory structure upon the completion of a successful build.  I do this for a few different reasons.

  1. I always want to have a pristine copy of my extension laid out on disk in a manner that could be easily shared with others.
  2. I like to store all of the various extension assets, like images, XML files, python files, etc… within the Visual Studio Project. In this way, I can force the project to be out of date and in need of a rebuild if any of these files change.  I find this particularly useful for working with the XML definition file for the extension.
  3. Having all of these files within the Visual Studio Project makes tracking thing within a version control system like SVN or git much easier.

As I mentioned before, to accomplish this task I use a combination of local python scripting and post build events in Visual Studio.  I won’t show the entire python code, but essentially what it does is programmatically work through my local file system where the C# code is built and extract all of the files needed to form the ACT extension.  It then deletes any old extension files that might exist from a previous build and lays down a completely new ACT extension directory structure in the specified location.  The definition of the post build event is specified within the project settings in Visual Studio as follows:

As you can see, all I do is call out to the system python interpreter and pass it a script with some arguments.  Visual Studio provides a great number of predefined variables that you can use to build up the command line for your script.  So, for example, I pass in a string that specifies what type of build I am currently performing, either “Debug” or “Release”.  Other strings are passed in to represent directories, etc…

The Synergies of Using Both Approaches

Finally, I will conclude with a note on the synergies you can achieve by using both of the approaches mentioned above.  One of the final enhancements I made to my post build script was to allow it to “edit” some of the text based assets that are used to define the ACT extension.  A text based asset is something like an XML file or python script.  What I came to realize is that certain aspects of the XML file that define the extension need to be different depending upon whether or not I wish to debug the extension locally or release the extension for an end user to consume.  Since I didn’t want to have to remember to make those modifications before I “released” the extension for someone else to use, I decided to encode those modifications into my post build script.  If the post build script was run after a “debug” build, I coded it to configure the extension for optimal debugging on my local machine.  However, if I built a “release” version of the extension, the post build script would slightly alter the XML definition file and the main python file to make it more suitable for running on an end user machine.   By automating it in this way, I could easily build for either scenario and confidently know that the resulting extension would be optimally configured for the particular end use.

Conclusions

Now that I have some experience in writing ACT extensions in C# I must honestly say that I prefer it over Python.  Much of the “extra plumbing” that one must invest in in order to get a C# extension up and running can be automated using the techniques described within this post.  After the requisite automation is setup, the development process is really straightforward.  From that point onward, the increased debugging fidelity, added type safety and familiarity a C based language make the development experience that much better!  Also, there are some cool things you can do in C# that I’m not 100% sure you can accomplish in Python alone.  More on that in later posts!

If you have ideas for an ACT extension to better serve your business needs and would like to speak with someone who has developed some extensions, please drop us a line.  We’d be happy to help out however we can!

 

Phoenix Business Journal: ​How technology can bring people together and bring down barriers

We talk about technology all the time and how it impacts our daily lives, good and bad.  “​How technology can bring people together and bring down barriers” takes a look at the social impact of technology when it comes to creating understanding and community.

Phoenix Business Journal: Installing a metal 3-D printer was a lesson on working with regulators

While installing our new metal 3D Printer we learned a couple of important lessons on working with local inspectors.  In “Installing a metal 3-D printer was a lesson on working with regulators” we share what we captured.

inBusiness: Riding the Wave of 3-D Printing

The Greater Phoenix inBusiness magazine just did a profile on PADT and co-founder Eric Miller.  “Eric Miller: Riding the Wave of 3-D Printing” gives some history and insite into what makes PADT unique.  It even includes some fun facts about the company.

Kids, Race Cars, and Scanned Turtle Shells: PADT’s 2017 SciTech Festival Open House

There is something about a kid running down a hallway screaming “mom, you HAVE to see this!” #openhousegoals.

Last night was our annual event where we open up the doors of PADT with a family oriented event sharing what we engineers do.  We also invited some students from high school and University to share their engineering activities.  With over 250 attendees and more than one excited kid running down the hall, we can safely call it a success.

Attendies were able to see our 3D Printing demo room including dozens of real 3D printed parts, learn about engineering, explore how 3D Printing works, and check out our new metal 3D Printer. They were also able to learn about school projects like the ASU Formula SAE race car as well as a prosthetic hand project and research into cellular structures in nature from BASIS Chandler.

Oh, and there was Pizza.

Pictures speak louder than words, so here is a galary of images from the event.

Connection Groups and Your Sanity in ANSYS Mechanical

You kids don’t know how good you have it with automatic contact creation in Mechanical.  Back in my day, I’d have to use the contact wizard in MAPDL or show off my mastery of the ESURF command to define contacts between parts.  Sure, there were some macros somewhere on the interwebs that would go through and loop for surfaces within a particular offset, but for the sake of this stereotypical “old-tyme” rant, I didn’t use them (I actually didn’t, I was just TOO good at using ESURF to need anyone else’s help).

Image result for old tyme

Hey, it gets me from point A to B

In Mechanical contact is automatically generated based on a set of rules contained in the ‘Connection Group’ object:

image

It might look a little over-whelming, but really the only thing you’ll need to play around with is the ‘Tolerance Type’.  This can either ‘Slider’ or ‘Value’ (or use sheet thickness if you’re working with shells).  What this controls is the face offset value for which Mechanical will automatically build contact.  So in the picture shown above faces that are 5.9939E-3in apart will automatically have contact created.  You can play around with the slider value to change what the tolerance

image image image

As you can see, the smaller the tolerance slider the larger the ‘acceptable’ gap becomes.  If you change the Tolerance Type to be ‘Value’ then you can just directly type in a number.

Typically the default values do a pretty good job automatically defining contact.  However, what happens if you have a large assembly with a lot of thin parts?  Then what you run into is non-sensical contact between parts that don’t actually touch (full disclosure, I actually had to modify the contact settings to have the auto-generated contact do something like this…but I have seen this in other assemblies with very thin/slender parts stacked on top of each other):

image

In the image above, we see that contact has been defined between the bolt head and a plate when there is clearly a washer present.  So we can fix this by going in and specifying a value of 0, meaning that only surfaces that are touching will have contact defined.  But now let’s say that some parts of your assembly aren’t touching (maybe it’s bad CAD, maybe it’s a welded assembly, maybe you suppressed parts that weren’t important).

image

The brute force way to handle this would be to set the auto-detection value to be 0 and then go back and manually define the missing contacts using the options shown in the image above.  Or, what we could do is modify the auto-contact to be broken up into groups and apply appropriate rules as necessary.  The other benefit to this is if you’re working in large assemblies, you can retain your sanity by having contact generated region by region.   In the words of the original FE-guru, Honest Abe, it’s easier to manage things when they’re logically broken up into chunks.

image

Said No One Ever

Sorry…that was bad.  I figured in the new alt-fact world with falsely-attributed quotes to historical leaders, I might as well make something up for the oft-overlooked FE-crowd.

So, how do you go about implementing this?  Easy, first just delete the default connection group (right-mouse-click on it and select delete).  Next, just select a group of bodies and click the ‘Connection Group’ button:

image image image

In the image series above, I selected all the bolts and washers, clicked the connection group, and now I have created a connection group that will only automatically generate contact between the bolts and washers.  I don’t have to worry about contact being generated between the bolt and plate.  Rinse, lather, and repeat the process until you’ve created all the groups you want:

image

ALL the Connection Groups!

Now that you have all these connection groups, you can fine-tune the auto-detection rules to meet the ‘needs’ of those individual body groups.  Just zooming in on one of the groups:

image

By default, when I generate contact for this group I’ll get two contact pairs:

image image

While this may work, let’s say I don’t want a single contact pair for the two dome-like structures, but 2.  That way I can just change the behavior on the outer ‘ring’ to be frictionless and force the top to be bonded:

image

I modified the auto-detection tolerance to be a user-defined distance (note that when you type in a number and move your mouse over into the graphics window you will see a bulls-eye that indicates the search radius you just defined).  Next, I told the auto-detection not to group any auto-detected contacts together.  The result is I now get 3 contact pairs defined:

image image image

Now I can just modify the auto-generated contacts to have the middle-picture shown in the series above to be frictionless.  I could certainly just manually define the contact regions, but if you have an assembly of dozens/hundreds of parts it’s significantly easier to have Mechanical build up all the contact regions and then you just have to modify individual contact pairs to have the type/behavior/etc you want (bonded, frictionless, symmetric, asymmetric, custom pinball radius, etc).  This is also useful if you have bodies that need to be connected via face-to-edge or edge-to-edge contact (then you can set the appropriate priority as to which, if any of those types should be preserved over others).

So the plus side to doing all of this is that after any kind of geometry update you shouldn’t have much, if any, contact ‘repair’ to do.  All the bodies/rules have already been fine tuned to automatically build what you want/need.  You also know where to look to modify contacts (although using the ‘go to’ functionality makes that pretty easy as well).  That way you can define all these connection groups, leave everything as bonded and do a preliminary solve to ensure things look ‘okay’.  Then go back and start introducing some more reality into the simulation by allowing certain regions to move relative to each other.

The downside to doing your contacts this way is you risk missing an interface because you’re now defining the load path.  To deal with that you can just insert a dummy-modal environment into your project, solve, and check that you don’t have any 0-Hz modes.

Exploring High-Frequency Electromagnetic Theory with ANSYS HFSS

I recently had the opportunity to present an interesting experimental research paper at DesignCon 2017, titled Replacing High-Speed Bottlenecks with PCB Superhighways. The motivation behind the research was to develop a new high-speed signaling system using rectangular waveguides, but the most exciting aspect for me personally was salvaging a (perhaps contentious) 70 year old first-principles electromagnetic model. While it took some time to really understand how to apply the mathematics to design, their application led to an exciting convergence of theory, simulation, and measurement.

One of the most critical aspects of the design was exciting the waveguide with a monopole probe antenna. Many different techniques have been developed to match the antenna impedance to the waveguide impedance at the desired frequency, as well as increase the bandwidth. Yet, all of them rely on assumptions and empirical measurement studies. Optimizing a design to nanometer precision empirically would be difficult at best and even if the answer was found it wouldn’t inherently reveal the physics. To solve this problem, we needed a first-principles model, a simulation tool that could quickly iterate designs accurately, and some measurements to validate the simulation methodology.

A rigorous first-principles model was developed by Robert Collin in 1960, but this solution has since been forgotten and replaced by simplified rules. Unfortunately, these simplified rules are unable to deliver an optimal design or offer any useful insight to the critical parameters. In fairness, Collin’s equations are difficult to implement in design and validating them with measurement would be tedious and expensive. Because of this, empirical measurements have been considered a faster and cheaper alternative. However, we wanted the best of both worlds… we wanted the best design, for the lowest cost, and we wanted the results quickly.

For this study, we used ANSYS HFSS to simulate our designs. Before exploring new designs, we first wanted to validate our simulation methodology by correlating results with available measurements. We were able to demonstrate a strong agreement between Collin’s theory, ANSYS HFSS simulation, and VNA measurement.

Red simulated S-parameters strongly correlated with blue measurements.

To perform a series of parametric studies, we swept thousands of antenna design iterations across a wide frequency range of 50 GHz for structures ranging from 50-100 guide wavelengths long. High-performance computing gave us the ability to solve return loss and insertion loss S-parameters within just a few minutes for each design iteration by distributing across 48 cores.

Sample Parametric Design Sweep

Finally, we used the lessons we learned from Collin’s equations and the parametric study to develop a new signaling system with probe antenna performance never before demonstrated. You can read the full DesignCon paper here. The outcome also pertains to RF applications in addition to potentially addressing Signal Integrity concerns for future high-speed communication channels.

Rules-of-thumb are important to fast and practical design, but their application can many times be limited. Competitive innovation demands we explore beyond these limitations but the only way to match the speed and accuracy of design rules is to use simulations capable of offering fast design exploration with the same reliability as measurement. ANSYS HFSS gave us the ability to, not only optimize our design, but also teach us about the physics that explain our design and allow us to accurately predict the behavior of new innovative designs.

3D Printing Student Projects at PADT: Visit our Open House to Learn More (Thursday, March 2, 5pm)

Thursday, March 2 is PADT’s annual SciTech Festival Open House, from 5-8pm (click HERE to register). This year, three student groups working on a range of projects will be present to showcase their work, all of which involved some level of 3D printing. Please bring friends and families to meet and discuss ideas with these students from our community.

Formula SAE Team (Arizona State University)

ASU’s Formula SAE team will be onsite with their 2016 cardemonstrating specifically how they used 3D printing to manufacture the functional intake manifolds on these cars. What is specifically interesting is how they have modified their manifold design to improve performance while leveraging the advantages of 3D printing, and also they have evaluated multiple materials and processes over the recent years (FDM, SLS).

Prosthetic Arm Project (BASIS Chandler)

Rahul Jayaraman will be back to discuss how he and 30 students at BASIS Chandler manufactured, assembled and delivered about 20 prosthetic hands to an organization that distributes these to children in need across the world. Rahul and PADT were featured in the news for this event.

Cellular Structures in Nature (BASIS Chandler)

A BASIS Chandler High School senior, Amy Zhang, just started her Senior Research Project with PADT, focusing on a project at the intersection of biology and 3D printing, investigating cellular structures that occur on surfaces in nature, like the wing of a dragonfly or the shell on a turtle or the encasing of a pineapple – all of which are comprised of cellular geometries. Using 3D scanning, image analysis and mathematical methods, Amy hopes to develop models for describing these structures that can then be used in developing design principles for 3D printing. You can learn more on Amy’s blog: http://shellcells.blogspot.com/

 

 

Importing Material Properties from Solidworks into ANSYS Mechanical…Finally!

Finally! One of the most common questions we get from our customers who use Solidworks is “Why can’t I transfer my materials from Solidworks? I have to type in the values all over again every time.”  Unfortunately, until now, ANSYS has not been able to access the Solidworks material library to access that information.

There is great news with ANSYS 18.  ANSYS is now able to import the material properties from Solidworks and use them in an analysis within Workbench.  Let’s see how it works.

I have a Solidworks assembly that I downloaded from Grabcad.  The creator had pre-defined all the materials for this model as you can see below.

Once you bring in the geometry into Workbench, just ensure that the Material Properties item is checked under the Geometry cell’s properties.  If you don’t see the panel, just right-click on the geometry cell and click on Properties.

Once you are in ANSYS Mechanical, for example you will see that the parts are already pre-defined with the material specified in Solidworks .

The trick now is to find out where this material is getting stored. If we go to Engineering Data, the only thing we will see is Structural Steel. However when we go to Engineering Data Sources that is where we see a new material library called CADMaterials.  That will show you a list of all the materials and their properties that were imported from a CAD tool such as Solidworks, Creo, NX, etc.

You can of course copy the material and store it for future use in ANSYS like any other material.  This will save you from having to manually define all the materials for a part or assembly from scratch within ANSYS.

Please let us know if you have any questions and we’ll be happy to answer them for you.

ANSYS 18 HPC Licensing Updates Webinar

PADT’s webinar covering Mechanical APDL & HPC available in ANSYS 18 will be going live tomorrow at 12:00 PM MST.

Don’t miss this opportunity, sign up today!

With the release of ANSYS 18 comes a plethora of new HPC product packages, each uniquely positioned at a competitive price to ensure that you receive the option that is right for you.

For more information, join us as PADT covers the specifics of the available licensing options, followed by a live Q & A session with simulation support manager Ted Harris.

By watching this webinar you will learn:

  • About the four main product packages available with ANSYS 18

  • What licensing options are available under each package

  • How price scaling works with ANSYS 18

  • The solving capabilities for each package and licensing option

Phoenix Business Journal: What’s the next tech from ‘Star Trek’ to become reality?

It should be no surprise to anyone that I love Star Trek.  So when we had a lunch discussion (as we often do) about Star Trek technology it was the perfect topic for a blog post.  In “What’s the next tech from ‘Star Trek’ to become reality?”  I present my case for two technologies that should be next: Tricorder and Shuttlecraft.  Some may argue that universal translator is even closer.

PADT Events – March 2017

March starts out with a bang, with a ton of events in that very first week. So we are updating everyone on the month’s events a week early. They cover a wide range of customers and states, so we hope to see many of you there.

The most important is our Open House for families, part of the AZ ScitTech festival. Make sure you RSVP so we order enough pizza!


12th annual Wasatch Front Materials Expo

03/01/17
SLCC Miller Campus
Salt Lake City, UT

This is a fantastic event that brings manufacturing companies in Utah together to share and network. PADT will have a table. Stop on by!
Learn more

Scientifically fun for the whole family: PADT 2017 SciTech Festival Open House

03/02/17
PADT HQ
Tempe, AZ

Once again, PADT Inc. is proud to partner with AZ SCITECH to promote and celebrate Arizona’s STEAM (Science, Technology, Engineering, Arts, and Math) programs!As part of this event, we will be hosting an open house that will give you an inside look at what our engineers do all day, as well as a first hand display of the capabilities of innovative technology such as 3D Printing and Simulation. Come see how we make innovation work!
Learn more

Mayo Clinic Course: Collaborative 3D Printing in Medical Practice

3/3/2017-3/7/2017
Fairmont Scottsdale Princess
Scottsdale, AZ

Collaborative 3D Printing in Medical Practice is a post-graduate course designed to update and introduce radiologists, surgeons, dentists, biomedical engineers, and other health professionals and administrators on uses of 3D printing of anatomic models. PADT will be there as an exhibitor to answer questions about how 3D Printing and Simulation can be leveraged by in the medical space.
Learn more

Webinar: Co-Simulation with ANSYS Workbench and Flownex SE

03/07/17
Online

In this webinar Flownex will discuss some examples which are ideal for a hybrid 1D-3D simulation and showcase how Flownex can be used with ANSYS products to maximise the efficiency of your simulations. This is a great oportunity for those who do system fluid-thermal simulation or those who do component CFD, and they want to know how to use the two together.
Learn more

America Makes TRX

3/14/2017-3/16/2017
University of Texas, El Paso
El Paso, TX

The event gathers all of the members of America Makes in one place to review the advancements in the US Additive Manufacturing industry. PADT’s Dhruv Bhate will be sharing the results of our America Makes project and looking forward to catching up with all of you who are members.
Learn more

Seminar: Impacting the Medical Device Value Chain: What is the Right Supply Chain for Your Product?

3/22/2017
Arizona State University
Tempe, AZ

PADT’s Eric Miller will be on a panel discussion supply chain and how it impacts medical device development.  We will consider ways innovative companies approach product development as well as principal upstream and downstream strategies and risks associated with innovative medical products. The extent to which products and processes are truly disruptive will be considered. Product diversity will be addressed including impacts of evolving business-to-business and business-to-customer strategies, biosensors, 3-D printing, and the shift of care outside of the acute care setting.
Learn more

Hardwarecon: The Convention for Hardware Startups

3/24/2017-3/25/2017
ZNE Center
San Leandro, CA

PADT’s Eric Miller will be attending this unique event focused on hardware startups along with ANSYS, Inc. He will be talking about using Simulation to drive product design in a startup. This is a great event where the focus is on hardware and how to produce outstanding physical products.
Learn more

Flownex at the International SMR and Advanced Reactor Summit 2017

3/30/2017-3/31/2017
Westin Buckhead
Atlanta, GA

Our team will be joining staff from Flownex for this key event in the small modular reactor space to talk about how Flownex is becoming an important design and performance tuning tool for the industry.
Learn more

ANSYS Video Tips: ANSYS SpaceClaim 18.0 Skin Surface Tool Changes

There were some changes in ANSYS SpaceClaim to the very useful tool that lets you create a surface patch on scan or STL data at 18.0.  In this video we show how to create corner points for a surface patch boundary and how to get an accurate measurement of how far the surface you create deviates from the STL or scan data underneath.

In Business Magazine: Five simple strategies for promoting customer satisfaction

How do you make sure that your customers have a great experience?  In “Five simple strategies for promoting customer satisfaction” PADT’s manager of ANSYS Technical Support and Training, Ted Harris, outlines the tools he and his team use to keep PADT’s customer satisfaction rates outstanding.

Tour ConceptLaser’s Metal 3D Printing lab at AeroDef

Attending AeroDef this year in Fort Worth? Make sure you register to tour Concept Laser on March 6th before AeroDef! You’ll hear an update on the GE acquisition and presentations on customer applications and machine safety. Registration ends February 24th, 2017, so don’t miss this opportunity!

Register now: http://aerodefevent.com/sessions/concept-laser-tour/

Speed, superior quality monitoring, and an open architecture that enables innovation – that is what makes Concept Laser’s Direct Metal Laser Melting (DMLM) technology a leader in the metal additive manufacturing industry. Come and hear about how Concept Laser is investing to bring you innovation through new products and processes that will lead to revenue-generating opportunities for your business.

The Tour is March 6th from 8:30am to 11:30pm and includes round trip transportation from the conference and more.

What you will see on the tour:

  • Direct Metal Laser Melting
  • In-situ Quality Assurance
  • Best-in-class safety guidelines when interacting with reactive and non-reactive materials
3D Printed Exhaust Gas Probe (RSC Engineering and Concept Laser Inc.)
Titanium implant leveraging lattice designs (Concept Laser)