Archives for June 2009

So we had been introduced to Phil from SoftTech through Chip Steel at Emmegi. When we were in Italy, we had looked at a product called FPPro from EmmegiSoft (http://www.emmegisoft.com). The Italian’s were not feeling too keen on the idea of trying to support their software in America. Chip had done some research and had worked out a deal to partner with SoftTech to support their equipment from the software side. So after we had purchased the software and began working with it we were anxious to see how the software would integrate with the Planet Machining Center.SoftTech uses a separate piece of software called link XML that actually connects their software to different CNC machines. The concept is that you can create the same information inside V6 then export it through the Link XML program to multiple pieces of machinery. The software uses a SQL file to connect V6 to a text file format output that can then be imported the software supplied by the machine manufacturer.On the surface, this seems like a good idea. Just make a new SQL file and you can now connect all of your existing data to your new machine. The problem is, as you can imagine, you are now trying to connect a complex machine to your software through SQL. Not a very forgiving or flexible language.

We BJ Wilson and Geoff from SoftTech out for three days where we ground out the basic code. We then had BJ back out to try and work out the compound miters. Zach at our office was a huge help creating the code for the compound miters and I think we are close. The biggest issue right now is working out a way to translate the cutting angles when the part is rotated on the machine. We are launching into that next week. So if you have a vertical mullion that is sloped meeting a Horizontal mullion that is sloped, you will end up with a compound miter. The V6 software will pass the angles to the Link XML based on the positions of the mullions when they are in the opening. When you put the part on the Planet, you usually want to rotate the part so you limit the amount of work you need to do to the bottom of the part. But, since you rotated the part, you now need to re-calculate all of the angles and cutting information. Some information in the Emmegi software will automatically adjust, but not the flying blade information for some reason.

We’re still debating weather it would be simpler to just write the code to create the text files in VB. SQL is crazy when you get this complex. It’s hard to debug and pretty linear. You can write helper functions, but not really branching functions. You can write “if, then, else” type functions, but they are all in line and you end up nesting them which gets crazy to read later. I’ll let you know what we end up doing.

This is just some of the fun you run into when you try to integrate software into your process and why you need to allow a lot of time to get things set up.

What we are finding is that the biggest part of implementation is figuring out how to set everything up. When we purchased the software, we bought the 3 seat minimum and they anticipated we would need to do a 1 week scoping session and then two one week training sessions.When I met with Carl for our scoping session, I gave him a tour of our facilities and an overview of what we had set up so far. Based on what he was seeing, he felt we could probably dispense with the scoping session and start right in on explaining the software. We spent the week geeking out in my office talking about all of the possibilities of how you can set things up. Every day when I would go home I felt like my head was ready to explode. Anyone walking by my office probably thought we were from another planet.So let’s take an example so you can relate to the issue. For our systems, all of our gaskets are made in frames (molded corners). Kawneer, who is one of the main people behind the development of this software, really only use lineal gaskets, so the program doesn’t have any specific functionality for this issue.

So we began discussing how to deal with this. The first idea was to create a nested frame that could be inserted into the daylight opening that would contain the inside gasket, the outside gasket and the glass. This solution seemed to work fine. We had to create a macro that would run right after the frame was built to automatically insert the nested frames into every specific light opening.

So, we had the beginnings of a solution. Now, like everything, the devil is in the details. So, what if there is a structurally glazed mullion somewhere in the opening? What if we want the molded gasket to span across both lites in this instance? What happens at structurally glazed corners? What if the interior gasket is molded and the exterior gasket isn’t (pressure wall systems)? How do we handle the mark numbers? They should really match the glass mark numbers to make the key sheets easier to create and manage.

So we started creating macros to help with this. We added an attribute to the vertical mullion assemblies to define if they were structural or captured. We then created a substitution matrix to look up what gaskets should be used in what situation. We then wrote some code on the nested frames to read the attributes on the verticals, look in the matrix and then apply the correct gaskets.

This got us to about an 80% solution. We then started adding more code to address the other 20%. In the mean time, we started doing some testing. Our first test project had a segmented wall with about 50 segments and 3 floors tall. When we tried to create the opening, all of the macros and attributes and matrix information started to kick in. The program began to slow and pretty soon, the computer came to a crawl and the program crashed. Just too much data to crunch. Worked great on smaller storefront openings, just couldn’t scale with the size of work and openings that we do.