Description
Key Learnings
- Learn to use EDGE to create real-time estimates
- Learn how to use EDGE to maintain producer-specific rebar-naming conventions
- Learn how to use EDGE to automate the shop ticketing process
- Learn how to use EDGE to automate the mark numbering process for like precast members
JORDAN WATKINS: --called EDGE for Revit that we're going to talk about today. Before I do that, I want to introduce Shannon Cooper. Shannon's going to be co-speaking with me this morning. Shannon's got 13 years of experience as a detailer in the precast industry.
He started out in the industry as doing a lot of the fabrication drawing, detailing, and he's now upwards to the lead modeling and doing the full framing and layouts of our overall structures. Shannon also is manager of our support staff, with our EDGE for Revit solution, so it's always been our business model, with our EDGE solution, to have a support staff that are active detailers and engineers in the industry, and that's where Shannon plays, really, a vital role with us at PTAC.
So just a little bit about each one of us there. But in this class, just take a deep look into the key features of our EDGE for Revit solution. Everywhere from our estimating solutions and our general massing tools, all the way through our fabrication-level drawings, our [INAUDIBLE] drawings, so on and so forth.
I really want to talk to you guys about why we developed this application as engineers and detailers in this industry to give you a glimpse into, really, what our overall goal is in the development of this tool. So with that said, we also really want to look at how we customize this solution for your business model. Obviously-- how many precasters do we have in the room? Good deal.
So as you guys know, there's no one way that everybody does it. Everybody does their own thing, from how you want to see a shop ticket presented, how you want to name reinforce-- whatever it may be, everybody has their own different workflow. And that was really one of our main catalysts when creating a lot of the tools in our EDGE for Revit solution-- to give all of the producers their way of doing it, allow them to standardize it to their workflow.
So if anybody's been to any of my other demos this week, I've brought this slide up on every one of them. And the reason I do that, I really want to-- it resonates with me a lot of why we really tried to create this solution for our industry. We truly believe precast is, bar none, one of the better materials out there to satisfy a lot of the real-world problems that we hear in construction today.
We've all heard, this week, about resiliency, sustainability. Schedule, obviously, is always a main catalyst. And precast has a very unique way of satisfying all of those issues. But for some reason, we're still 1% of the overall construction market. In 2018, we were projected to be right at about $800 billion in the overall construction market, and PCI has published that we're right in the $7 billion range.
So less than 1% of the overall market is precast concrete. And we believed, at least in part, that the reason that is the case is that the ability for our industry to actually produce concrete is in part limited by the amount of engineering that can be done. It's a very specialized design and detailing process. So like I said, that was really the big catalyst by creating our EDGE for Revit solution-- is to really optimize our entire industry.
And like somebody said in the keynote at the Connect & Construct Summit, a high tide raises all ships. So that's really what we're trying to do here, and really just overall increase the productivity of our industry. We didn't only do this with our EDGE for Revit solution. That was our main, core business, but since then, we've turned a lot of focus, as well, with our development staff to apply to the upstream and downstream processes. And we'll take a look at those at the end of this presentation, just to show you guys how we're working to automate production beyond just our engineering workflow-- get this data out of those data silos, free that data so we can actually leverage it for other processes throughout our workflow here.
So after we leave this class, the big thing I want to focus on is taking a deep dive into a lot of the key features that EDGE for Revit has. Like I said, we've got a lot of customers that are leveraging this technology, from estimating, all the way through fabrication. So in order to do that, we need to make a very seamless workflow, a very simplified workflow, so we can really go from conceptual design to fabrication-level drawings. And then we're going to go all the way through our project management tools, our rebar naming convention tools, how we generate shop tickets, how we automate those processes, and so on.
So first one I want to look at-- this tool we actually-- oh, and by the way, Shannon's going to be switching back and forth to show you guys some live demos, because nobody likes to just listen to me read these slides. So we're going to show you guys, in action, what these tools do and how they do it. But first, the Addon Hosting Updater Tool-- the reason we created a utility like this was because out of the box Revit, we realized, when we first adopted this solution and tried to use it in our in-house detailing, really didn't work for the precast workflow.
Revit walls, Revit beams, Revit columns-- they just weren't giving us the unlimited flexibility that we needed. So we decided to create a unique solution of wiping the Revit slate completely clean, adding all of our own content, and then giving unified workflows to basically create that very complex geometry. When we started implementing this to one of our big customers-- early adopters-- about five years ago, it was that we noticed that a lot of users were going outside of the project environment, creating that one-off custom content in the Family Editor, and loading it back in. Very clunky workflow, very, very difficult to get the custom precast shapes that we were looking for.
So because of this, we came up with a unique way of joining all of this material together, or carving this material away to ultimately allow us to create those very architectural pieces that a lot of our customers were using. So you can see here we've got corbel that's obviously not monolithic with that panel. Doesn't appear monolithic.
Rather than going into the Family Editor and adding that corbel to it, our Addon Hosting Updater's going to retroactively join those pieces together. So it's going to take on the same physical attributes of that particular wall panel. It's going to take on the transparency, the color, so on and so forth. But more importantly, Revit in and of itself has no way of telling that particular wall panel that it has auxiliary geometry associated with it.
You can see Revit-- if Shannon will select that wall panel-- you can see that Revit's got its volume for that panel of 4.75 yards of concrete. But EDGE is actually recalculating that-- scroll all the way down for me, Shannon-- recalculating that to determine what the true volume of that is-- 4.83 yards of concrete. So it's a utility that's collecting all of that material together and actually writing the relevant information to that particular wall panel itself.
Another big thing-- it's cleaning up all of our details for us. So if we look at a detail with that section cut, traditionally you would see a hard line between your wall panel and the corbel itself. And this basically creates, again, just that one, unified geometry, that one monolithic geometry, so we can leverage it downstream, rather than going into the Family Editor each and every time.
Another very unique thing is that it's going to also determine what type of material it should consume. So you can imagine, here, obviously we've got a structural panel, here, with a structural corbel. We may have an architectural face mix that's going to have a bull nose associated with it. So the Addon Hosting Updater's actually going to take all of that into consideration and consume the appropriate materials so you have accurate counts when you get to the fabrication level.
So just a quick example of that is we've got the material of precast concrete-- which was, in fact, the material of the wall panel itself-- to actually be associated with the corbel. So we get those true reliefs of inventory of what we've actually batched for each particular material, each particular mix. Another unique thing about our Addon Hosting Updater is it's also going to go into our finishes as well. Our finishes are going to be anything from thin brick, acid etch, heavy sand blast-- whatever it may be, we're going to quantify those materials and those post-pour finishes in our model itself so we can get that true unit cost associated, not just in the overall model, which Revit does a great job of doing.
But ultimately, on a per piece level, too, so we can really go back retroactively and get some good cost accounting numbers from each one of our end products, ultimately. So this Addon Hosting Updater's everything from corbels, cornices, bull noses, solid zone, and insulated piece-- whatever it may be-- any auxiliary concrete outside of that main panel itself.
That was just a really big tool to kind of get us off the ground and really create that content each and every time, and a very custom workflow so we can make those very specific precast pieces that we needed. So the next one was taking that model data and leveraging it for estimating. That was obviously the next obvious step. And we've got a lot of customers who are actually taking this data, and we've written it to proprietary estimating solutions-- or commercially-available estimating solutions, for that matter.
But it's actually going to extract that data and not just give you a Revit schedule, but it's going to collect the associated form work with that particular panel. It's going to give you the corbels down as cast or top as cast faces-- just going to really get all of that data for you so you can put a unit cost associated with each type of element.
So Shannon's going to go through that with us also. What we're actually going to show is one of our customers-- two of our customers, actually; big producers in North America-- have a solution that they called precast evolution. And that's their estimating solution which has a unit cost associated with each type of product itself.
So Shannon's going to export that for us, and that's going to actually, again, sum all of those materials, all of that form work. In this particular system, they wanted to know overhead doors, personnel doors, and windows, and then top as cast face haunches and bottom as cast face haunches. So just getting all of that data in the format in the data structure that they're estimating solution needed to be able to not only automate the actual estimating process, but also automate the full proposal process as well. So really a one-button touch to generate their proposals for estimates.
And this is just a quick look at exactly what Shannon just showed you guys. Just showing you, again, it's going to quantify those overhead doors, overhead width and height personnel doors-- or man doors-- and ultimately windows. So you can see a very unique situation.
If we've got a number of different man doors in a panel that's a 3 by 7 door or a 4 by 7 door, it's going to average those out so they've got the appropriate unit cost associated with what they're actually going to generate in that particular panel. So the next thing is going beyond just our generic models-- our massing, if you will-- and going, actually, into our scheduling tools.
So we've got a unique way of getting away from the traditional cumbersome workflow of placing an embed in each individual component, ensuring that those embeds are hosted to the appropriate host so we can get accurate counts later. Instead, we try to optimize the placement of our connections, and really, retroactively, if you will, break those apart so we can get those counts for how many plates double tees are going to consume, how many plates a bed is going to consume, a day is going to consume-- whatever it may be.
We wanted to break it down in a very granular level so we can extract that data and start really leveraging it for our ERP systems. So we've got some unique tools for scheduling, and we break this down into two different components. We call one our Bill of Materials product testing utility, and the other one our construction product testing utility.
Basically, the difference in those two are simply-- Bill of Materials is looking at the overall project. We want to know, per project, per product, how many plates we're going to consume. So we want to know how many double tees-- how many plates and double tees are being consumed, so on and so forth.
The construction product hosting is a little bit different, and it's going to go down to the individual entity level. So we want to see exactly how many plates a very specific double tee it will be consuming so we can leverage that for our shop ticket data and generate the Bills of Materials on our shop ticket as well. So Shannon's going to cycle through that for you, and if he runs our BOM Product Hosting tool-- and you'll see what that dialogue that he just went through a number of times, just giving you the granular control of which portion of a model you actually want to run this tool on.
But now you can see that particular plate now has what we call our BOM Product Host, or Bill of Materials Product Host, to that particular plate. So now we have all of the data extracted from the panel itself written to the embed, and ultimately, we can fairly simply get those schedules generated in Revit for, like I said, all of our production material, our loose material, our cast and place material, so on and so forth.
Next tool we wanted to do to kind of leverage the data we have in our models for scheduling of embed scheduling of hardware was actually go to what we call our Schedule Sequence By View. And any time I show this tool, I always tell a story. We were detailing a job for Coreslab Tampa, and we were detailing-- it was a big, seven-level parking garage, and a little auxiliary building-- the central energy plant, we called it. And it was somewhat of a unique job that we've had. Our seven-level garage-- our central energy plant, excuse me-- powering the seven-level garage, as well as a steel structure on the same job site for the US Board of Realtors.
And in my infinite wisdom, I just sent them all of the double tee plates on a particular job. And I quickly got a phone call back saying, that's great, but we're not producing the garage. We're not erecting the garage for quite a while. We're working on the central energy plant, so we need that broken out.
So because of that, we generated this tool. And this is what I would describe as our graphical scheduling tool. Just lets you do any count, whatever you have visible on the screen, in any method you see fit. So temporarily hiding it in the view, permanently hiding it in the view, getting a section box-- whatever it may be, allowing you to refine your view, refine the elements in your view, and extract that data out very quickly.
Probably the most applicable way of using this tool is scheduling loose material, scheduling [INAUDIBLE] material by face. That's probably one of the most applicable situations you have here. But Shannon's going to run our tool, and he's going to actually just write whatever you guys see fit. So if you write phase 1, you'll see all that loose material, or phase 2-- whatever we're going to type here.
And now you can see, if you select the lug between your mini V's-- your panel-panel connection-- or anything visible in this view, you're going to see that you've got phase 1 associated with that. So again, just further allowing you to refine your schedules and your hardware Bills of Materials within the Revit model, and like I said, very quickly quantifying what's visible on the screen, there.
So next, this is arguably probably our most powerful tool in EDGE. This is a tool that we realized we were going down a workflow of trying to automate this process, but we didn't have a very refined way of naming mark numbers, or marking pieces-- which is obviously the core of our business. And we found ourselves detailing with EDGE-- spending a day, two days, maybe three days on a decent-sized project-- going through and comparing pieces in the model to ensure that they were the exact mark number.
And we were opening ourselves up to a ton of human error obviously, as well as just a ton of wasted time trying to do that. So what we did there was create our mark verification tool. And the reason we did this and leveraged it outside of just your Autodesk Revit workflow of creating assemblies and letting Revit compare those assemblies is we saw two major flaws.
The first one is there's no reason to create an assembly on every piece in the entire project that early on when you're trying to mark the piece. The second thing is there was zero tolerance associated with the assembly tool in Revit, meaning that if I had some-- we would never-- nobody in this room would do this, but we had some careless modeling, and maybe had a plate 1/256th of an inch off from each other. Revit inherently said that was a different piece than the other, so we wanted to build this mark verification solution with a method that would allow us to take those tolerances in that even PCI themselves, MNL-116 and 117, say you're OK.
So we built an interface to not only allow you to build your tolerances in based on the user specifications, but also build the mark number settings, we call them, to automatically name your pieces for you. So if we want a prefix of CLA for our columns here, it's going to automatically name those and order them appropriately.
One thing important to note as well is we try to maintain the drafting integrity as much as humanly possible here as we're algorithmically going through that and determining what the mark number should be. So what I mean by that is you don't want to have mark 1 on your first sheet, then get a mark 300, and then back to mark 2, and then it's just scattered all over the place. So what we've done there is actually collect it by our control number parameter within EDGE to order that appropriately.
So each group with the lowest control number will get the first mark number. Meaning if I have a group of five double tees that are 1, 2, 4, and 6 and 7, that would be double tee 1. If the next group was 2, 3, so on and so forth, that would be double tee 2. So grouping it by those control numbers and allowing us to automate that naming convention is the goal with our mark verification tool.
You're going to see here, shortly, too, we realized that we needed two methods for this tool. We needed to initially mark a job before we released it, or before we submitted it for approval, but we also needed to have some way to retroactively verify those marks, because inevitably, something on the job's going to change. So in order to do that, we have what we call our existing tool and our initial tool.
And our initial tool, like I said, is going to go through and automatically mark each element for you. An existing is not going to remark it, but it's ultimately going to validate the existing marks in a job. So to do this, show you guys are really quick example. And I'll put together a very, very simple model so you can understand, really, the real power behind mark verification.
And in this model, I've done everything. I've basically started with our baseline panel here and copied it over 10 times and made slight modifications each time. This one, I've got a corbel rotated 180 degrees. I've moved some plates in this location.
And ultimately, if you pan all the way down to the other side, Shannon, we've also taken into account this very unique situation that we came across-- at least very unique from a programmatic standpoint. We did everything from our parameters on the wall panel-- the weights, the volumes, the length, the width, so on and so forth-- to your embed locations, your addon locations, all of those things. And then we looked at this particular problem, and we quickly realized that that, for all intents and purposes, are the exact same piece.
Until we, in fact, did a full polar moment of inertia full section property analysis of those pieces, we really had no evidence that it was, in fact, a different piece. So this was probably our most complex situation and mark verification. But ultimately, what I want to illustrate with that is we've done everything from your parameters, your embed location, your addon locations, your rotation and orientation of those addons, and then ultimately, a full section property analysis.
So if we run that tool-- our initial tool-- you're going to notice we have an initial dialog box that we give you. And the intention behind this was we've got this really powerful engine with mark verification, and that's going through all of those criteria I just listed. But we realized that someone like gate precast cast may find a lot of value in ignoring the embeds, ignoring the corbels, and looking specifically on the repetition of form work in your project itself.
So we wanted to give the ability to kind of parse out different portions of this engine, and leverage it for however you guys see fit in your overall business model. So if I wanted to just simply select our solid geometry comparison, we can look at that specific form work and kind of forget about the rest. But this model, we're just going to do all of it. And you'll see it's going to go through and process-- that's not a good thing. Go to your other model. Go to your other model.
So this is going to cycle through and do your analysis on each and every element in that model itself. Not sure what's going on there, so that's awesome. Never do a lab demo, for sure. So what that's actually going to cycle through is go through and, like I said, group those panels accordingly to make sure, in fact, it is an identical panel.
A very unique thing is we're also going to retroactively analyze that with our mark verification existing. And we're not just going to simply tell you, hey, this doesn't match. Instead, if we've got a project with 75 wall panels that are identical, and for some reason two of them changed, but in fact, they changed to still be identical to each other, we're going to do a full analysis on those 75 and tell you that not only did this 75 fail, but also, this 75 failed with these 73 still being identical, and these 2 now being identical as well.
So going to do a full regrouping for you and let you make the decision, with mark verification existing, whether or not you want to modify the existing mark number of a particular piece depending on where you're at in the production, or if you want to just allow EDGE to automate that process for you, and renaming it with the suggested renaming convention.
It's just a little bit more like that. So after we've got our embeds in the model-- oh, one more thing to explain about mark verification as well is that we try and do this in a phase in the model where we're fairly conceptual, and allow you to iterate through that process. So even though we're not going to have every piece of reinforcement in our model at the time of creation or at the time mark numbering, we're going to allow you to put in a design number parameter-- there you go. We've got it working now-- so design number parameter to actually analyze that.
If this is, in fact, the exact same piece from a geometric standpoint, from an opening standpoint, from an addon standpoint, everything, and you say the design number is the same, then we're going to inherently say that, OK, then all of your lifting devices and all of your reinforcement will be the same as well. So Shannon, run through that one more time really quick so we can show what that's actually doing.
So you can see here it's presented you with each individual mark number in the job, named it accordingly based on an insulated wall panel. We wanted it to have a prefix of WPB. And it's just going to certainly-- it's going to automatically determine which one is the same and which one's different. We, like I said, not only cut down on a substantial amount of time we were wasting in marking the job. We also cut down on a substantial amount of human errors, and we really found out something that I was extremely interested in-- was we were being grossly conservative on our manual marking.
We saw a huge economy of scale when we switched it to an automated process, because when we weren't sure on two different elevations, they were different mark numbers. So really, we saw a lot of economy outside of just our software standpoint, but from an engineering standpoint, we saw our jobs have a lot better metrics as we went on. So if you go to our WPO, it's three there. And Shannon's just going to make one of those different, here.
So we're going to run our mark verification existing again. You need to cut that void first, though. So we're going to run our mark verification existing again. Same criteria. And you'll see that WPB03 should fail. But it's not just going to simply tell you it failed. It's going to tell you exactly where it failed, and why it failed.
If you select that WPB03, you'll see it actually failed on our main material volumes. And then ultimately, we could go into a very detailed comparison of each one of those particular pieces. So if we select our Check Detailed Comparison at the bottom, this is going to open another dialog that actually regroups that for you. So that's what I was saying-- that you had 75 mark numbers. Two of them change, but the two are exactly the same-- it's going to analyze those appropriately and regroup them accordingly.
So if you select each one of those individual members, you'll see which ones passed, and then ultimately, the next one-- this one-- should have passed everything, and the next one failed on material volumes. So ultimately, a very powerful analysis tool that helped us quite a bit in automating our naming convention, and automating just our overall detailing workflow.
All right, so once we had mark verification done, once we had some middle drawings out for approval, obviously the next step was going to our fabrication level of drawings. And Revit-- as many of you guys know, Revit has a built-in functionality with assemblies to extract that individual element out of a model-- essentially, out of a model and be able to detail it on its own accord. But we found the assembly workflow fairly clunky with out-of-the-box Revit, especially if we had to go through and manually add each individual element to a particular assembly to create fabrication-level drawings.
We quickly found out there was a lot of human error there. We left a corbel off of a wall panel in a big job an inverted T-beam corbel, so not just an easy repair-- off of a job down in South Florida, and quickly realized we needed to automate that process as well, too. So our Assembly Creation tool actually cycles through everything in the model and deleverages solid geometry interferences out of Revit to create that one, unified element in the model so, again, we can use that for fabrication-level drawings.
The real benefit of that is we talked about essentially, before, that we were essentially trying to optimize the placement of connections throughout the model, and we do that by nesting a lot of our components together, placing an embed in the inverted T-beam, which ultimately-- or a connection to the inverted T-beam-- which ultimately has our loose material, as well as the double tee plates associated with it as well, but we need to retroactively break that apart to create our assemblies. And that's ultimately what our Assembly Tool will do.
It will find the inverted T-beam plate itself and extract that out of the model. So you'll see that here, particularly in your mini-V flange connectors here-- or alignment connections here. You'll see we're going to retroactively break that connection apart, and only select or only collect the associated elements within that model itself-- or within that assembly itself, here.
So again, really eliminated our error rate in missing embeds when we were trying to place it in the model, and so on and so forth. Another big thing we realized with our Assembly Creation tool was that-- or with out-of-the-box Revit assemblies, excuse me-- was that the way to create a local coordinate system within Revit was fairly difficult.
Revit did a phenomenal job of having an overall project coordinate system associated with the project, but not so great when we got to a local coordinate system for each individual piece-- which is obviously extremely important for precast concrete. So because of that, we created what we call our Top as Cast tool. And this tool is actually just going to let you graphically select faces to reorient that local coordinate system for you and make it a lot easier than out-of-the-box Revit-- or our experience with out-of-the-box Revit-- was.
So you see Shannon's just going to simply select our Top as Cast face first, and then the left edge of a panel and the right edge of a panel. We were hoping that we could just simply select that Top as Cast face first, but quickly realized something like a sloped spandrel with a skewed end-- we really needed those three levels of input.
So there are a few-- and I'd be happy to share it with everybody-- there were a few issues with the Revit Assembly tool prior to 2017 depending on the orientation of a member's z-axis to the global z-axis. And ultimately, we circumvented that completely with this Top as Cast tool. So if anybody's interested in that, I'd be happy to give you guys a little white paper that I passed on to Autodesk to memorialize this bug form.
So next thing is once we create that assembly tool, we need to obviously put the reinforcement in the model. We need to get to that LOD 400-level model so we can get to fabrication drawings. One thing, again-- realized all these tools, common theme here, is they were driven out of direct necessity for either our detailing or our customers' detailing. But we ultimately decided to get rid of Revit rebar initially-- for two main reasons that I've been in discussions with Autodesk quite a bit on.
One of the first reasons was you previously could not place reinforcement in a three-dimensional model, which was an extremely clunky workflow. Having to go to a two-dimensional section elevation plan to put your reinforcement in and not allowing you to dynamically spin it around was just not a good workflow.
Another thing was rebar wasn't creating an actual solid geometry interference. So we weren't leveraging the ability to figure out those clashes and do a lot of that stuff without getting to Navisworks, which ultimately we would like to do in Revit itself. So for a lot of those reasons, we basically wiped the slate cleaned there, and just created custom notable families.
Every PCI bar bend in the handbook is created with EDGE and provided to our customers, so ultimately you guys can hit the ground running with a suite of rebar utilities that come directly with our EDGE ecosystem. So we realized, obviously, that we couldn't just provide content, but we needed a way that we could automatically track and name mark numbers-- our bars-- automatically for you as well based on a user setting.
So gate precast, for example's, got #301 for their first number 3 bar in the model. That's a bent bar. And that's ultimately going to-- if you've got 1 foot by 1 foot by 1 foot U bar and then you got a 1 foot by 1 foot by 2 foot, clearly that should be a different bar mark. And we're automating that process and naming it accordingly, but not just simply naming it, naming it according to those producer standards.
So you're going to see-- and this, again, is a common theme, like our mark verification, like rebar settings, like our ticket settings-- that we have tried to make this as customizable to our customers as possible. So we're not modifying the drafting integrity that you guys achieved with 2D workflow and sacrificing it for a three-dimensional workflow. We're trying to maintain that integrity, and just bring it into a more model-based approach.
But here you'll see we've got three different settings. We've got our Bent Rebar settings, which was the example that I gave earlier that was built on an incrementing fashion. So the first number 3 bar's #301, #302, so on and so forth. We surveyed our industry and our customers and realized that there was kind of two different clear ways that people wanted to name reinforcement-- one being the bent bar in an incrementing-type fashion, the second one being straight bars and concatenating a name together to create an overall bar mark.
Meaning that if I have a straight bar that I wanted a prefix of S, and I wanted to know the diameter, and I wanted to know the length, and I wanted that all pushed into one name to be the bar mark itself, that was a really big-- that was a bear to do with out-of-the-box Revit. Really big pain. So because of that, we created the utility to concatenate that and dynamically update your mark number based on the length and the model itself.
And then lastly, we realized that there was another use case for this reinforcement, and that was standard rebar settings. We've got a lot of customers out there that have automatic vendors that they bought years ago that have no way to accept wireless or physical media to extract our bins out of the model appropriately. And they came up with a workflow-- a lot of these vendor providers did-- of allowing you to store database of common mark numbers so you didn't have to go punch in a 1 foot by 1 foot by 1 foot U bar each and every time-- which is our first example here. Instead, you would just simply say, I want 50 MK 301's, and the vendor would know what that is.
So in order to facilitate that workflow with EDGE, we allowed our customers to create a user database to determine if a bar mark is, in fact, the same, and then ultimately, we'll name it accordingly. So when you place a piece of rebar in the model, we're doing multiple things. First, we're checking that Rebar database, seeing if it is a standard bar mark.
Then, if it doesn't match any of our standard bar marks, we're going to scan the rest of the model. We're going to determine if that configuration has been created before. If so, we'll adopt that naming convention. If not, we'll obviously make it the next-available bar mark as well.
So continually building that database for you, project-specific so you can ultimately get those bar bend schedules for each individual project. Our out-of-the-box workflow is really with a prefix diameter, incrementer-type deal. But we've supported everything from Rocky Mountain Prestress has the diameter, shape, length, and ABCD, so on and so forth incrementing fashion-- so a lot of different workflows that we can support with our EDGE Rebar Naming tool. But ultimately, the goal is simply to make sure that we are automating that process and allowing our users to reinforce the model without worrying about a naming convention.
So you'll see, here, Shannon actually placed a number 4 bar in the model. And you'll see that that number 4 bar is, in fact, an MK 402, here. There's another 4 bar in the model somewhere. But if you copy that bar and change one of our leg configurations here and you make that a 1 foot by 2 foot stirrup, you'll see EDGE will automatically recognize that that is, in fact, a new bar mark-- that your previous bar mark was incorrect, but a new bar mark-- a #401, the first number 4 bar in the model itself, meeting that naming convention.
Likewise, we bring this to number 3, a #402, so on and so forth. This particular bar here-- your MK401-- and actually, I didn't realize it before, but if you select the initial bar-- Shannon-- that's actually mimicking one of our standard bar marks in your database-- so that MK402. So that's why it adopted that name rather than the first increment of the overall project name. Does that make sense? So it's matching a database name, there.
Another big thing with our bar marking is that we did it with all of our-- dynamically between shape and size as well. So if you select one of those number 4 bars and you make it a number 3 stirrup, then obviously that diameter should change. That naming convention should change.
We don't have one loaded in the model, so I'll put him on the spot. But that would ultimately name that #301, and so on and so forth. So dynamic between shape and size. Last thing to note with bent rebar settings, as well, is that we have all of our opposite hand checks in place.
So if we copy the bar that Shannon's got here and we simply make that-- instead of a 6 by 1-- this bar right here's a 2 by 1. We're going to make it a 1 by 2 instead. And you'll see that-- a 1 by 2, Shannon. So 1 and 2.
So we can see that's still going to recognize that it is, in fact, the same bar mark regardless, because ultimately, we do all of our hops and hand checks and determine if, in fact, it is the same bar, just simply mirrored. So we can get some economy of scale out of our vendors there. And then finally, our straight rebar settings-- you can see it's built on our diameter, as well as the overall length, and we're concatenating that into our bar mark here.
So we make that 5, and you'll see that dynamically update to S04, or S40500. And it is feet, inches. However, whatever your setting is for your particular bar mark naming convention, it will dynamically update for you as well.
And this is just a few more topics that we just kind of rolled through, but our standard naming convention-- giving you a little bit more information in the class handout if you guys are interested in how we organize this, how we order this, and how you can ultimately create a completely custom bar shape that doesn't fit into the PCI handbook shapes.
So the next one is a tool that we created to basically be a project management tool to track every single piece throughout its lifecycle-- at least its engineering lifecycle in precast. So we're going to track every piece from being created initially-- and we're saying that's assembled-- to actually reinforcing that piece-- which, our engineers, we have a very unique business model at PTAC that our engineers are very model-based, model-oriented, and we're actually putting the reinforcement into the model that we design.
The idea behind that is nobody should know that better than us if we designed it. So they're going to put all lifting devices, mesh reinforcement. And so we want that individual, if they're working in our Tampa office, to not have to pick up the phone to call our Pensacola office and say, hey, it's ready to go.
Instead, we're going to use our project management interface to tie our project team together and alert users when specific elements are ready for the next phase of their overall engineering lifecycle. So we do that by our reinforce date, our created date-- which basically tells our drafters working on fabrication drawings that maybe one Drafter A has created that initial piece, and we're working on the same product line. We don't need to fight over that particular piece.
So really, just a clean interface to really track every piece throughout its lifecycle. It also is going to go through our detailed date, when it's complete, ready for checking, and then ultimately released for production. This, we joke, is our little blame tool, here. But this tells you who did what every step of its lifecycle as well.
So I know, as the engineer, if I made a modification to something and it did not get picked up on the last drawing but somebody said they accepted those changes, we can really see who did each phase, and really use it as a learning tool to make ourselves better in our overall tracking. Another thing from simply a management business standpoint-- we'd get a lot of the good metrics that we're concerned about in our detailing services. We need to know how many pieces there are, how many marks there are. And then ultimately, we want to know how many have been reinforced? How many have been detailed? So those are the things, in our weekly staff meeting, that we just get a very quick 10,000-foot view of where a project stands in its overall lifecycle, and how we're doing on that project to-date.
AUDIENCE: [INAUDIBLE]
JORDAN WATKINS: Yes, yes. That's the date that it is ready for checking. So that's-- at least internally, for us-- and I should qualify that. That's our workflow. You guys can use that to whatever workflow you saw fit, but that's ultimately what we implemented at PTAC-- is this is the date that it's ready to check. Good question.
So like I was saying, from the 10,000-foot view in our weekly staff meeting, we want a lot of those metrics, and quite often, we want to see those on a very specific workflow, meaning that I know our unit costs for detailing a wet cast piece at double tee, a wall panel. It's substantially higher than detailing a piece of hollow core. So we want to know very quickly not only how many pieces are in the project, how many marks are in the project, but if we filter by something, we're going to dynamically update that as well, too.
So you can see if you type in C here, that's going to filter out our list to only of our columns. And then all of our numbers actually will update as well, too. So we know we have two marked numbers in the model for columns. And we can see here, we've dynamically updated what's been reinforced, what's been detailed, what's been released for production. So again, we get those metrics not only on a project level, but down to a product line level as well, too, to really get a better image of where our project stands and maybe where our pitfalls are there.
The other thing to mention as well, and we don't have an example in this particular model is if a change has been made, after it has passed a specific stage in its life cycle, meaning that, as the engineer, I have reinforced this, I've marked it as reinforced, and someone has begun detailing it. If I go and make a change, it's going to force me to actually put together a list of what those changes are.
And then in this project management interface, you're going to see it actually flag those particular pieces, and give a life cycle of that piece, and tell you what has been changed, why it's been changed. And then ultimately, as the end party responsible, you have to accept those changes. So again, we've got every piece tracked on its life cycle.
Shannon, if you get back to the demo one more time, and you just right click on any of these pieces, you can access a lot of stuff right here. But one thing is to review our ticket edit history. And again, that's what I keep talking about here. If you select that, that's going to-- has not been in the assembly yet, so--
There you go. That's going to give you every stage, what happened, who did it, what their comments were if there were any comments. So again, we can track every piece, start its life cycle, and try and learn from our mistakes if there are any, and better ourselves a bit there. You also have the ability to launch a lot of tools directly from this utility.
You guys will hear about our edge for cloud utility at the end of this presentation as well. And this is a way to directly export it from our model and get it to our cloud platform, ready to be viewed by production immediately. So just a lot of different tools. You can open our ticket view directly from our project management interface. You can go to our-- actually create our ticket with our ticket populater command. Just that one clean interface that we want our users to stay in, to not only track pieces through its life cycle, but interact with those pieces as well.
So next, obviously, we need to get in to how we automate the shop ticketing process. So just like marked verification, just like reinforcement, we realize that no two producers in North America-- I can say this pretty confidently, nobody does it the same way. Everybody has the best way of doing it, but nobody does it the same way.
So because of that, we wanted to create a way that we could completely customize that experience. And you guys to determine exactly what your shop think it should look like. Everywhere, everything from the title block down to the views to your view rotation to the bills and materials where you want those bills and materials located, your title block information, and so on. We wanted a way for you to customize that, and ultimately tell us exactly how you want your shop to get to look. And then we can leverage that information and actually regurgitate those subsequent similar piece details.
So we're going to go through a demonstration here. But we do this by graphically creating a template with a lot of the out of the box Revit tools. And then we're going to leverage that template, like I said, to regurgitate many, many pieces.
So first, we're just going to go through the semi-manual process. And keep this in the back of your mind, we do this one time and one time only per producer, per product. So all of this is stored. And we have an ecosystem set up to where for Gate Precast, for example, for Spancrete.
You guys would go and create that template one time, store it on a shared server. And then we have a user settings file that we call our edge preferences that actually map where your particular files should go. So again, at PTAC, we've got one file for Spancrete, for our naming convention of reinforcement, and that's it. We don't have any ability to have inconsistencies across the board.
So that's done a lot of stuff for us. First, it got rid of all of the obvious potential human error of editing files multiple times. But it also inherently gave us consistency that we were losing with our old 2D workflow. So as simple as keeping our lifting detail in the exact same location on every single shop ticket for a double tee, every single time, not only on one project, but every project period gave our end user production something that they really could get in their routine with and not continue to move that, which we saw a lot with our two dimensional workflow.
So what Shannon's doing here first is just simply selecting the views that he wants on the shop ticket. He's going to generate that shop ticket or that ticket template graphically. And he's going to actually rotate each one of those views as well, too. So you guys can see the view rotation itself.
We'll give him just a second to do that because often obviously, you don't want to see it always as erected. Some producers want to see that panel as it's poured into bed, some want to see it as erected, whatever you guys see fit. Everything from the location, those views to the orientation of those views, that's what we wanted to make available in our ticket template settings file.
On top of that, we wanted to give you obviously, the ability to save those ticket or those view templates as well per individual view. So for Gate Precast, for example, if you have a five sheet shop ticket for a wall panel that you want your initial sheet to be form work, it basically progressing through our production sequence. Form work bottom is cast plates, top is cast plates reinforcement, and just a number of very clean, unified sheets. That's what we wanted to give the ability to do.
So actually, I glazed over it. But in our top is cast tool. We're also doing an analysis of where an embed is located in that piece in relation to that new local coordinate system you created. And we're going to programmatically determine if a plate is, in fact, top is cast, bottom is cast. So when we get to our shop ticket level, we don't go through the effort of manually hiding embeds that are on our top is cast face to show a form view. We want to do that all algorithmically and all programmatically.
So you can see, we've obviously placed our views, set our view template, set our view orientation, we're then going to use our edge tools to actually run our bills and materials as well. This is also something I won't get into too much detail right now because we're running short on time. But this is also something that is fully customizable to our end user workflow.
So if you want a reinforcing schedule that's separate from a lifting schedule, that's separate from a mesh schedule, whatever it may be, we give you the full ability to ultimately determine exactly what those are going to look like. So we've just got some examples of-- you can see for all of our hardware here, we're quantifying that on an existence in the models, how many times it actually exists. On our installation sheet, you can see we're obviously doing that by a surface area. And with our overall strand, we're doing that on a total lineal feed.
So ultimately, the idea is to give you the full customization because Revit doesn't allow you to quantify similar things different ways in a single schedule. We want to be able to give you guys a workflow of presenting that how you see fit there.
And then finally, our title block information as well. This is just simply going to go through and fill out all the relevant title block information for your volumes, your final release strength, if you see it fit, your mark number, your weight, so on, and so forth. This is also again, another way that we give you the full user customization.
So if you go to our administrator tab and you select our ticket populater settings, you'll see you have complete control over determining what piece of information you want to extract from the piece in the model, and put it to your title block automatically because as we all know, that's grabbing a wall panel parameter, a structural framing parameter, whatever it may be, and converting it to a sheet parameter. So there's no clean interface in Revit to do that. So that's what this interface is intended for, is giving you the ability to automate that process and not have to go through the manual typing that we were seeing a lot of customers doing there.
And then lastly, and I don't know that actually asked Shannon to do this, so he probably doesn't have it set up in our demo here. But the last thing we have, and probably my favorite part of our assembly creation tool, is that we've actually got what we call our strand pattern template, or our shop ticket tool, excuse me. And something we call our strand pattern template.
And ultimately, what that's going to do for us is allow our engineers, as we're working in the model, to go through and identify a design number for each individual element in the model. And then we're going to when we use our ticket templates, we're going to circumvent our strand pattern template legend. And we're going to replace it with the appropriate template.
That just completely removes the effort that I had to do as the engineer, go through and check in every shop ticket because ultimately, I put the reinforcing in, I put the lifting in, I assigned the design number. So I know programmatically, from that standpoint, everything that I would have been particularly interested in, I know that it's going to be automated on the shop ticket process, everywhere from all of those steps to even our break strengths of concrete, our final and release strength of concrete. That's something that I'm working on in the model itself, and I'm confident that it's going to be appropriate when it goes to the ticket because it is an automated process there.
So once we've done that graphically, then we're going to use our edge tool to basically scan what you have on the screen. And we're going to store every bit of that information in a file that can be referenced by everyone in your organization here. So you'll see, Shannon is going to run our ticket template creator. It's going to map to a particular file. This one's on his local C drive, but ultimately, that would be on a shared location on your server. So everybody in your organization, whether they're in the same office or not, will still be referencing this same particular file. And he's going to name it based on the manufacturer.
As consultants, us, CGTG, using Edge, we work for a number of producers throughout the country. We wanted a clean way to identify who the producer was on the project we were working on. And I didn't want to go through Metromont's templates, through Gates's templates when I was working on a Spancrete job. So because of that, we wanted to store it based on producer to allow us to really automate and optimize that process.
And then the last things that we needed an answer on was how you wanted to handle your bills and materials. Is it going to grow from the bottom down or that-- I'm sorry, the bottom up or the top down? So that was kind of our first alignment issue we had to decide. And then the second was do we want these bills and materials to grow with each other, or do we want them, in fact, to be static in different portions? Meaning that if I've got my reinforcement on my reinforcing page, and my lifting on my lifting page, and so on and so forth based on our ticket template, we wanted to know that those grow independently of each other.
However, if we wanted our mesh, our hardware, everything to be in one particular schedule because obviously, no product has the exact same number of line items in a bill of materials. We wanted that to grow dynamically for us, automatically when we run our ticket template here.
So we're going to create that file, and it's going to be consecutive. It's going to be additive to your previous files. So you're not going over and overwriting anything before. We're just simply adding to that xml file. So everybody can leverage that as you build your content and build your templates.
So-- and Shannon, what he's doing right here, is actually reassigning a design number so we know what the design for that is so when we get to our shop ticket, we can replace that strand pattern template and replace it with the appropriate N pattern. Let me change that. That's better.
OK, so from our ticket manager, we're going to select this new piece that we want to create a shop ticket out of. And everything we just did manually from our title block location, from-- excuse me, our schedule location to our title block information to our views and everything, again, with stored force. And that's going to be automated with this process here.
So selecting it through our project management tool, Shannon will run our ticket populater. It's going to present him with the interface to allow him to determine exactly what template he wants to use. This is something that is stored per project, per product as well, your default settings, meaning that the next wall panel I run on my job, doesn't matter what user I am, I'm actually going to go in default back to the latest used template. So we create some economy and some consistency across multiple drafters in the project.
Last thing we're going to do is our scale. This again, is set to the default scale of the template itself. But that may or may not be consistent across a job if we're detailing 30 foot double tees verse 60 foot double tees on a particular project. We may want to change that.
So we give that, the ability to dynamically update that. But we did want a way to actually warn you that we think the scale is too large for a particular piece because we caught ourselves on a new job just iterating through what's the best scale for this job, what's the best scale for this job. So we wanted to go through and basically, give a way that we could empirically calculate what the available title box space is with a reasonable amount of buffer for details and schedules, and just give you our estimate of what we believe the true scale for this particular product line should be. So that's what you're seeing in red there.
So then once we've chosen all of our settings, our title block, obviously, we can dynamically update it if we want to. But that is stored in our ticket template settings file as well. So we run our populate command, and that's going to go through and automate that whole process for us.
Yeah, so actually go back and change that strand pattern, WPO1, Shannon. So that's OK. He had design pattern WPO1 for his strand pattern, no big deal there. But ultimately, we're going to redo that really quick so you guys can see that, where it will place that. But you can see, as he's doing that, we've got obviously, the views, the view orientation, the view location, all of our title block information, all of the bills and materials automated for you, and ultimately, ready for detailing for that particular piece. So he's going to delete all those one time, and take two on this one.
You'll see it'll go through that. And then again, my favorite part of this whole process is automatically placing that in pattern for a set design pattern. So we don't, in fact, ever have an issue that it was potentially not the appropriate in pattern. So again, just doing that all programmatically. So we take some of the human intervention, some of the human error that we saw out of there. So that's what we do automatically as of today to present the piece detail ready for annotation.
And we also have a number of tools that actually optimize the workflow of annotating those details, or annotating those shop tickets everywhere from our automatic dimensional routine to our automatic annotation routine, and kind of anywhere in between. What we realized, we developed a tool a long, long time ago with our previous software package of automating dimensioning, and we very quickly realized that it was taking us more time to clean up the verbosely dimensioned shop ticket of useless dimensions than it was to actually go dimension it manually itself.
But we also realized we were creating a ton of human error with manually dimensioning a shop. So we wanted to come up with some happy medium. We do have automated dimensioning, actually, that we're working on refining as well, too, just for formatting. But we wanted to give some hybrid way of leveraging automatic imaging and not picking things one at a time, but also not just spending 15, 20 minutes trying to strip dimensions away that could be avoided.
So we've done there is actually our hybrid of automatic dimensioning routine. And, Shannon, if you'll-- I don't know if this model's set up for that because it's one of our newer tools, but this will actually allow you to select and embed. It will globally select all of the elements that are like that embed, and then automatically generate a dimension string for you with the appropriate quantity, the appropriate pin string for the mark number of the element you're dimensioning and the location and form. We call it say, top is cast, bottom is cast, so on and so forth.
And then everywhere from automatically annotating views from or annotating elements, from the model itself, from model information, so tagging embeds, lifters, reinforcement to copying those ticket views so we can get some economy of scale when we have a number of double tees that are very similar. We want to take all of those same details and push them forward to the next piece. Basically, a save as, but a save as without being able to dimension it, if you will. Or without it being automatically dimensioned, I should say. You still needed to dimension it.
And then ultimately, a fine referring view tool that actually tells us if one detail-- we saw a very common mistake that we were modifying a detail on our shop ticket that we weren't educated on, meaning that I've got a lifting detail that needed to be specific for this individual piece and a checker modified that, marked it up, and read. And the detail or cleaning up that shop ticket was actually going and changing it, and not realizing he had just changed it everywhere on the entire job.
So this is really just an educational tool to allow you to understand where a particular in pattern or where a particular detail lives. And if you are going to be, in fact, just affecting that one piece or if this warrants actually creating an entire new detail itself.
And that's just an example of a detail that we actually-- or a shop ticket that we did for Metromont in South Florida at their Bartow plant. Just an example of the level of detail achieved with our Edge for Revit solution. And just to give you guys a few highlights before I open up to questions.
I said that we developed our edge for Revit solution as our core platform. But we also wanted to leverage all of this data for downstream and upstream processes. So we didn't want to keep that data. We all have heard this week, data silos. We didn't want to keep that data locked up in just engineering. We wanted to push it out to other processes as well.
So our enterprise resource planning system extracts all data from our models. So we can do everything from inventory relief, cost accounting, production planning, long range and short range production planning, knowing how much we need to actually batch one day, so on and so forth. So just giving us all of the metrics associated with the job and leveraging it for downstream and upstream processes directly out of our model itself.
When we break that in two, like I said, we've got our piece information, our assembly information, our export for materials as well. And that basically-- the assemblies is anything that needs kidding or assembly by the steel fab shop. And that's going to reference our actual raw consumable or our materials list to actually relieve inventory, meaning that if I've got a job with 100 plates, and those plates are six by six with four headed studs, four quarter inch by four inch studs, we needed to relieve that stud inventory itself. So we're leveraging our ERP data, extracting it from the model, doing real time inventory relief, cost accounting, and so on and so forth.
Next utility we have is our Edge for Cloud solution. This one's fairly new. We've got this active in about four or five plants now, for six plants, sorry. I was just thinking that through. I have six plants now.
This is actually a way to get our model data into the hands of our engineering folks, our production folks, and just, again, free that data from our data silos. So what you're seeing here is just the interactive way to interact with our three dimensional piece, select things from interactive bills and materials. You can see that's what I'm doing there. Go over to the two dimensional view as well, which is obviously the more native thing that we're in right now.
So go to the 2D view, the ability to measure it in two dimensions, the ability to interact with the bills and materials, step through a storyboard, which you're seeing here, of production sequencing. So you can see different phases and dynamically clean up a shop ticket without spending a lot of time on detailing. So just quite a bit of different ways to get data into the hands of production, a lot better than we traditionally have, with dumping our models down to a two dimensional sheet.
So again, just a better mousetrap to get that information over to them. Oh, and on top of that, we do have quality control tools. Our QC tools will actually allow you to mark this up on our Edge for cloud applications. So we bring the QC process completely paperless as well. We're going to store that for all PCI audits, so we store it on an external database, or your local database, or your local server if you guys see fit. So you can access that for future audits in the event that you need to improve any QC markups.
So the only thing we don't have at this point in time in our Edge for cloud solution is those QC items, such as break strengths and so on and so forth, which we depend on our Edge free, our P system, and the interaction with those other enterprise resource planning systems to store that relevant data for QC.
And then this is brand new, very much in its infancy, very much something that we're interested in and really wanting to turn a lot of focus on as this hardware becomes more and more practical and feasible for production. So our augmented reality application, we've worked very, very closely with Daiquiri out of Los Angeles that have been here a lot this week. And Daiquiri's an augmented reality provider that had-- this is actually their legacy device that's no longer in production called their smart helmet and their smart glasses.
The idea behind that is we're going to get away from the paper workflow. And we're going to render the appropriate piece in the form itself. There's a lot of things we've got to work out with that. From a software standpoint, we've got our proof of concept. And we actually have the Daiquiri glasses here if anybody is interested, not in this room, but I'd be happy to go grab them for you guys.
But it's basically a way that we can render the piece in the mold itself without worrying about drawing. So we can basically paint by colors, just trace the piece as we begin the production, rather than going through the workflow of two dimensional drawings. Again, very much in its infancy. We've got a lot of things to test, and we're hoping to really get that off the ground within the next 12 months.
And again, our business model from the software provider standpoint is to try and be there prior to the hardware, if you will. So we want to be two steps ahead of the hardware. So when this is something feasible from a price point standpoint as well as a technical standpoint, our customers won't be waiting on us to develop the software to be able to interact with Edge.
And then lastly, and this is actually something Doug and I taught about yesterday, is our Edge for Cam export. Our Cam export, computer aided manufacturing, is leveraging all of our model data for production automation. I'm sure a lot of folks have seen the YouTube videos of a lot of the pre-cast production going on in Europe and Asia where they're automating a lot of the workflows that our industry, albeit some folks are, but our industry is lagging quite a bit on automating our production workflow.
But as I said yesterday, we're kind of blowing other markets out of the water with complexity of pre-cast products. So we, with our Edge for Cam export, wanted to leverage our model data, even if we're not going to automate the entire production workflow, but to try and cherry pick portions of the production workflow to be automated. So anywhere from rebar bending to laser projection to water soluble bed plotting to whatever it may be, leveraging model data to be able to use it with a lot of the known machines out there.
So we support two file formats, Unit Technic and PXML out of the progress group. And those seem to be the two universal formats to drive a lot of machinery in our industry.
Last thing, and I think he's going to be there for maybe 20 more minutes, but Bogdan with Autodesk, the product owner of their pre-cast extension, is hosting a pre-cast connections and Revit idea exchange at the idea exchange corner over by the hub, or over by the exhibit hall. If you have some time, definitely go give Bogdan your feedback and see-- just help Autodesk try and drive our industry forward as much as they can.
We have a very symbiotic relationship with Autodesk, obviously, with our development. So they've helped us out in overcoming some technical limitations of Revit. But we hope to reciprocate some of that as well with the help of our customers by going and giving them some ideas that could hopefully push the product forward.
So with all that said, this is our Edge email address and our Edge for Revit website. My email's jwatkins@ptac. If you're interested, come grab a card. Be happy to hear from you guys. If nothing else, just give us some feedback on the presentation and let us know how we did. But I appreciated everybody's time this morning. I hope everybody had a great time last night and a great day today as well. And thanks.
[APPLAUSE]
Downloads
Tags
Product | |
Industries | |
Topics |