AutoCAD Plant 3D: Specs and Catalogs for the Masses

SCOTT HALLMARK: Well, welcome to AU. This class is the "AutoCAD Plant 3D-- Specs and Catalogs for the Masses," being brought to you by myself-- Scott Hallmark-- and Ken Fauver. We'll jump to the next slide so you can see a little bit about us. I'm a senior mechanical and Plant consultant with ECAD. I've been with them since about February of this year.

I worked with a couple of other different resellers in the past. This is my seventh time to speak at AU. I've been using AutoCAD since 1988-- release nine, with the 5 and 1/4" floppy disk on a 286 machine-- and been consulting with Plant and Inventor for many years. So I'll turn it over to Ken.

KEN FAUVER: Yes, I'm Ken Fauver. And I'm a senior Plant consultant at ECAD. I've been in the oil and gas industry for just over 30 years as a designer and CAD manager.

Prior to ECAD, I worked 8 and 1/2 years at Autodesk as a Plant 3D technical sales specialist and a consultant. I'm just like Scott. I've been an AutoCAD user since 1988-- maybe it was 1987. I'm getting too old to remember. But I'm also now a BIM 360 consultant since 2019. Geaux Tigers!

SCOTT HALLMARK: Yeah. Roll tide. And so, down at the bottom, we have some links for you. Pdoteam.com is our company's blog for process Plant-- and basically anything dealing with Plant 3D-- a website link ecadinc.com, and then I've got a personal blog there that you can see that's dealing with Plant 3Ds. I've been using Plant since its inception, when it was just PNID at the time. And at that point, I just started writing things down that I was learning. So it's got some things in there for you as well.

So we'll continue. The description of this class-- hopefully, you know what this class is about since you signed up for it. But just to give you a brief description of what this is about, you've got specs and catalogs in Plant 3D.

And depending on the size of your project, you've got to figure out what's the best solution going to be in order to get this information to the masses, to the designers-- whether they're in a single location, whether it's a single user on a project, whether it's multiple users in a single building, or you've got multiple buildings, multiple states, multiple countries.

Remote users-- I know that's the thing that's becoming real prevalent now is people working from home. And you've got to be able to let those designers and engineers have access to the information-- the specs and the catalog-- so that they can do their work. So our focus here is on specs and catalogs. You're going to hear us talk a good bit about project information. But the focus here is specs and catalogs and getting that out in the most efficient method possible to the end user.

So we're going to start off with some questions to ask when you're planning your spec and catalog deployment-- the first question being, how many Plant 3D designers will be working in this project, and where will they be located?

This is important to know, even though, again, we're talking about specs and catalogs. And this is talking about the project. Well, we need to know where that project is. We need to know how many users are going to be on that project and where those people are going to be located. That will help us formulate a plan for deployment of the specs and catalogs.

Next question is going to be, what will be the most efficient location for editing and accessing the specs and catalogs? We need to plan that out as well. Is it going to be best if these things are sitting on the server, and everyone accessed the server?

But then, you've got remote users. How are they going to access? That's going to be slow for them. Is it going to be best for us to push those specs down to the local workstation? Those are things we need to consider when we're asking these questions.

And the last thing is, what are the pros and cons of the options we have? So once we've defined the designers and where it's going to be and what locations we have available to us to store these specs and catalogs, what are the pros and cons for that? So we're going to kick off the first question with Ken. And he's going to take that one.

KEN FAUVER: All right. Thanks, Scott. Well, the first question is, how many Plant designers will be working in this project, and where will they be located? First, we want to have one to three users on a local machine-- meaning this is your local desktop. Specs and catalogs will be local along with the project on your computer. This is the most efficient scenario, because you're not relying on servers or internet access.

The next one will be one to three users on a local file server. The specs and catalogs, along with projects, will reside on this server. And this option is still very efficient and simple to set up and use. Three or more users on a local file server-- this option increases to bigger projects and more users. We'll touch on this a little bit later.

But I wanted to move on to the option of having three or more users on a non-local file server. This scenario can be challenging but has the potential of R4 improvement. And then, we have three or more users on a replicated file server.

This improves performance over a global and work sharing situation, meaning that you can work share local as well as work share globally across the large pond, if you will. But this starts to get a little bit complicated. But with the right planning, it can also be quite efficient.

SCOTT HALLMARK: All right. And so, I'll take the next question-- what will be the most efficient location for editing and accessing the specs and catalogs? So, again, you've got basically those four scenarios-- the local machine, the local server, the non-local server, and the replicated server. With the local machine, again, we're talking about a user and that person's workstation.

So it's really a one person job. That's an easy setup. That's as easy as it gets. It's a fast setup, fast access to the files, fast access to the specs and catalogs. All the editing of the specs and catalogs are done from that.

But it could be a scenario where you've got a single user. And that user has that project on their machine, but they're also in a network environment. And in that network environment, the specs may be being edited by someone else, bearing in mind there may be an employee that just handles that. And so, they're pushing specs to the server after they modify the specs, edit the specs, and test them.

Well, then, it's to that point where we need to get those specs down to that local user that's just using his or her machine to work on that project. And so, we want to use a batch file for that. And I'm going to give you a little snippet down here in the left corner of one that we've used in the past for different clients. So really, you could actually type this from a command prompt if you wanted to-- a Windows command prompt.

But if you set it up in a text file or a BAT file, it's doing a few things. It's looking to see if a directory exists for where you're going to store these Plant project specs. If that folder doesn't exist, it'll create it for you. The next line, the Robocopy line. And if you're not familiar with a robocopy, it's not a new tool at all. It's been around for quite a few years. It's similar to Copy and Xcopy in DOS or the Windows command prompt.

But it's much more robust. It's got many more switches and options in there in order to make it to where you can specify exactly what needs to be copied, removed, what needs to be removed from that copy, things like that. The information you're seeing there on the screen-- it's going to be available to you in the handout. So you don't have to type it down real quick for that.

But also, in August of this year, we've released a blog post on pdoteam.com that gives all the details of even what these switches mean. So you want to look at that a little bit later after the class, maybe, or after AU is finished. but that's for the local machine. You can use that batch file to push the specs from the server down to local machines.

You've also got the local server option. And with the local server option, again, use that batch file to robocopy the specs down to the local machine. But if that's not going to be something you're going to want to set up, then obviously you can just use a map drive or UNC in order to access those specs and catalogs in the project.

Now, if you're going to do that, the content has to be consistent across the board. So you're going to need to go into the Spec Editor application on each user's machine. Go to the Tools pulldown and modify the shared content folder to point to that common location. The reason you want to do that is, if the shared content is going to be in a single location on the server, everyone needs to point to the same thing.

You don't want some users pointing to their local, some users pointing to the server. You have inaccurate information at that point. But another option would be, just copy that content down to the local machine as well using the batch file. You would need to make some changes to the batch file, but it can be done. But the key to that is you have to run Spec Editor as administrator if you're going to do that. It does require an administrator privilege in order to make that shared content folder change.

Then you've got the non-local. The non-local is if you're dealing with users that are non-local users accessing a server that's not local to them. So it's sitting in a headquarters or something. And you've got users out in different cities or working from home. They're having to VPN. They're having to VPN in to access not only the project, but the specs catalogs and write to the database.

And so, you can use remote desktop for that. Good luck with that if you're going to try that. It's worked before, but I personally would not use it myself. Speed and latency is going to become a factor for the non-local users accessing the specs and catalogs. But again, if you use the batch file, push those down to the local machine, you're going to get a better result.

And also, they're going to be working on files or using specs that are released. They're not work in progress. So if you're going to be in this type of environment where you've got a non-local server, you need to test this thoroughly at various times of the day. Don't just test it at 8:00 AM and tested it again at 12:00 when nobody's there and they're all gone to lunch. Test it at various times of the day with routine Plant operations.

Because what you don't want to end up doing is getting a quarter of the way, or halfway, into a project and suddenly realize our remote users are not going to be able to function this way. They're not going to be able to work on this project because of the size of the project, and maybe some other factors. So test, test, test on that. You're also going to be limited to internet speeds and WAN and server uptime. So, again, there's factors there that can cause issues with this.

One thing that could help, certainly, would be to consider Autodesk Vault so that everyone is working locally. You download or you check out a project. And you work on that project local. And then you just check in the files as you need to check them in. That way, everyone else has the same access to the current data. And then, there's also a collaboration option with BIM 360. I'm going to let Ken talk about that for just a minute or two.

KEN FAUVER: Yeah. With BIM 360, you're working in Plant 3D in the cloud. And you can check in and check out, similar to the way you do with Vault. And it also will load those files locally for you to edit.

SCOTT HALLMARK: All right. And then, we have replicated servers. And this is going to be adequate. It's going to work well for your specs and catalogs, and even the SQL server. But you don't want to do this with the planned project. You can, but a better workflow for that would be to use Vault.

And you can replicate Vault using an AVFS file server at one location-- and at the host location, you have your main files, your Vault server-- and let them replicate back and forth the data that's being checked in and checked out. That way, everyone is working on current data.

Now, there's a great AU class from several years ago by Jarrod Mudford. It's called, "Multi-Site Workflows-- The Good, the Bad, and the Ugly; An Advanced Look at Your Options." So look that up. Everything in there is still pertinent today, even though it's a few years old. So that's something to consider also. So we'll let Ken take on the last question.

KEN FAUVER: Yeah. We're going to talk about what are the pros and cons of the options we have-- the great, the good, and the bad. So first thing we're going to discuss is speed and latency on your local machine. The local machine is the best and fastest option for accessing and editing specs.

So make sure to make frequent backups before editing specs, just so you can go back to them if you need to. Copy specs to the server location for access by other users. That way, the designers are not using a work in progress version of the specs and cats-- meaning they are not depending on the specs that you're currently working on or editing to work on the project. So that way, they're not getting locked by the user or by you and causing conflicts.

Local server-- typically fast, but can drag at times due to heavy network traffic. And your company's network infrastructure can be an issue. Having specs and catalogs on the server, in most cases, means they are being backed up. Hopefully, the IT department has set that up that that server is getting backed up on a daily basis.

And then, we have replicated servers. Like the local server, speeds are good for the designer. But latency of replication could be a concern. What you need to ask is whether or not the replication is an immediate or a scheduled intervals. Because that can cause a problem. Working with Plant, you need things to happen immediately instead of every so often, every couple of hours, or something like that.

Then, you have the non-local server. This can be a frustrating project to work on, especially if you're the non-local user. VPNs will have you looking for other options. We talked about that a little bit in the last section. You might want to be looking at options like collaboration with BIM 360, which has the local workflow. And for specs and project files, check in check, out drawings to and from the cloud.

You can also use Vault via a VPN. And it also has the local workflow for specs and project files. And you can also check in, check out drawings. But you're checking in and checking out to and from the Vault server. So the Vault server for Vault, and then, for BIM 360, you're checking in and out from the cloud.

SCOTT HALLMARK: All right. So I'll take manageability. Manageability is going to be a key factor in this. It's not just about speed and latency, but we want to be able to manage these specs and catalogs. And obviously, with a local workstation, where the end user is at their workstation-- that machine-- or the local server, those are going to be great. Those are going to be great options.

The management in either of those scenarios is ideal. You can still do local editing and testing of the specs and catalogs before releasing those to the project, basically pushing them up, either manually through a copy, or through a batch file that copies everything up to the server and then gets pushed back down to the end users.

Again, we keep talking about pushing files back down to the end user through this batch file. But that's going to be to ensure the correctness of the specs-- that everyone is using the same version of the specs and the catalog content. That's going to be a key option for you, is to do that.

Replicated servers-- that's a good option. It's actually a really good option. There's really just one holdup for it being great. But let's talk about that option. The editors, they're making changes locally. They can make changes on their local machine, push them up to the server once they're finished, just like what I was talking about-- copying to one server and then letting the servers replicate that around to the other servers at the different locations, whether it's across states, or across cities, or even across the globe.

That replication can take place and push those specs around. And then, of course, the batch file pushing it down to the end user-- we can't reiterate that enough. The batch file, again, comes in very handy in that scenario. There's no worry of the work in progress specs being used in the active project.

The only holdup, like I said, for this being a great solution is just that reliance on the internet again to replicate, and the intervals of that replication. So once you leave that building, and that information has to go to another building, you lose control at that point. You have no control of the infrastructure between your building and the next place it's supposed to go to. That's somebody else's deal.

So having to rely on that can be tricky at times. It's usually pretty good. You usually have a real high percentage of uptime. But there is those times where we do have downtime. And that's where work stops.

And then, you have the non-local server-- which is, again, just showing up in the red. It's not the ideal solution. It's what we would consider a bad option. And the non-local user, again, is, you've got the remote users. They're accessing a server that's in a building. But they're not in the building. And so they're having to use some type of VPN or remote workstation to get in, remote desktop, to get in and do work.

Now, if the editors of the specs and catalogs are not local to the server, they have to use a VPN. The manageability there can be strained at times. They can still edit and test locally on their workstation. But, again, they've got to rely on the internet. And they've got to rely on that VPN to be functional to push that information up to the server.

Personally, I live out in what I would consider a rural town in Alabama. And we have issues at times where the internet goes down. And I can't help customers. I can't make phone calls out of my computer phone system. And that stops work. And it's going to be the same type of situation for anyone else that's dealing with that non-local server scenario.

So designers and engineers accessing specs via VPN should be easy to manage. It's just a matter of pushing it down. But then the potential problem could be how often they pull it down-- how often they run that batch file. It really should be an automated process. So I'll let Ken take the last one here.

KEN FAUVER: So there's accessibility. Again, the local machine is the best. There's no infrastructure to worry about. And you just have to remember to back everything up. Local and replicated servers are good. This is probably a close second if your IT department is on the game and has failover plans and the appliances and server equipment that's needed.

Non-local-- usually that accessibility is kind of spotty at best. Reliance on the internet and working from home-- the things you've got to ask in that arena, the problems you run into on this situation, is the residential internet versus the business grade, similar to what Scott was talking about in the last section.

And then, you have your upload versus download speeds. That's always an issue. So let's move on to scenarios. The first thing I wanted to talk about is the small projects. This is a single local server. Most of the time, the users have to be in a same location. And there's no remote users. Large projects-- users in the same office as the server. And sometimes you have home-based users across the country.

And then, you have the large global projects, where users are in the same office as the server, but you can also have satellite offices with replicated servers. And you can also have satellite offices in other countries, along with remote home-based users across the country.

So let's start with the small projects scenario. We'll start out with one office, three designers, a local file server-- we won't have any VPN or remote users, but we will have one SQL server. And the specs and catalogs are on the local file server.

Recommendations for this is to have the specs and catalogs edited and tested on the local server. Use the batch file or login script, as Scott had discussed early on. And also, again, consider using the BIM 360 for localized workflow, along with the Autodesk Vault. We discussed that earlier on. Those are good options.

SCOTT HALLMARK: All right. And then, I'll take the large project. So in this scenario-- again, all these scenarios are for is to just kind of gauge where you're at in some of these scenarios and look at the recommendations that we're making. And you may not agree with some of the recommendations. And that's fine. You might say that this scenario has been working for us just fine. And you're telling us not to do what we've already done.

It doesn't mean that it won't work. We're just, from the many years of being consultants and the different clients that we've dealt with, we've run into a lot of scenarios. And we've run into what works and what doesn't work. And so, in this particular one, we would consider this a large project, where you've got maybe 12 office-based designers. Say they're in Houston. You've got four home-based designers in Atlanta. There's one local server in Houston with map drives over a VPN for the Atlanta users.

And then, you've got one SQL server in Houston. So there's no replication going on. There's no Vault in place here. But the spec editor, the person responsible for editing the specs and catalog items, that person resides in Atlanta. And so, they're remote. Again, they're working from a home office.

So a recommendation we might have for this-- and it doesn't mean, like this first bullet item here, keep the project located on Houston server share. Well, that recommendation doesn't really go along with "consider BIM 360 for localized workflow." Those are two different options. But it gives you at least the ability to say, all right, this is going to work better for us over this one, or vice versa.

But if you keep the project located on the Houston server share, then you want your specs and catalogs edited and tested on a local machine by that person in Atlanta. They then push that information up to the Houston server once it's tested, once it's approved. They can push that up to the Houston server.

So the users-- the 12 in the office, and the other three users that are remote-- they can then pull that down to their local workstation with the login script or the batch file that's doing that. Whether it's automated that that comes down or on demand, it can still be done through that batch file. But the Atlanta users-- they're going to experience some lag on drawing and database accessibility.

But they're going to gain some performance if those specs are localized and that content is localized as well. They're going to gain some performance on that. So they could possibly switch to a virtual machine. I wouldn't necessarily recommend it. I probably would vote against it. But not saying that you can't, it's a possibility to use. Internet accessibility and speeds here, though, are going to be critical for those Atlanta users accessing a server in Houston.

So, again, we could still locate the files on the Houston server, or we can consider BIM 360 and use that collaboration inside of Plant so that the project exists in the cloud. It's very easy to add more people in that are going to be remote. It's very easy to add more people in that are going to be in the office. It can be easy to add a whole new group that's from another office.

It's just a matter of giving them access to the project through BIM 360. They download it as local to the machine. They work on it. They save it. It automatically goes back to the cloud. That's not that's an ideal situation. And then, of course, Vault is also an option as well, where everyone is checking in, checking out. Really the only lag time you're going to experience is those Atlanta users checking in and checking out through VPN and refreshing Vault, refreshing files down from Vault. So that's the large project scenario.

KEN FAUVER: Let's move on to the large global projects, which is similar to large projects. But in large global projects, you have multiple offices. And these offices can be located in the US or other countries-- for example, Poland, maybe Mumbai. They could be replicated servers. There could be one to two SQL servers, possibly replicated. And then, specs and catalogs are located on the US server. So the recommendations for this are spec and catalogs edited and tested on the local machine. Of course, they'll be edited and tested on the local machine in the US office, then copied to the spec and cats folder on the US file server. Again, that little bugger keeps sneaking in there, that batch file and login script. That's always the best thing to use, to be able to copy those specs down to where you need them. And then, consider the BIM 360 localized workflows along with the replicated Autodesk Vault localization workflow. again, with that, you're going to get some of the lag on the check out or check in and refresh from Vault procedures. so with that, I'm going to turn it back over to Scott.

SCOTT HALLMARK: Yeah but in this case, the BIM 360 is really what that is designed for. Right, Ken?

KEN FAUVER: That is. This is where BIM 360 shines.

SCOTT HALLMARK: All right. So, in conclusion, we want to make sure that, hopefully, you've got some good information out of this. I know some of it sounded a little repetitive. But as things are repeated, they're learned-- from what I've experienced. But the main thing in this is, don't wing it. Don't start the project and then decide, after you're already into the project, what we did is not going to work. We need to go a different route.

So you don't want to wing it. What you want to do is, you want to ask the right questions about the project, which is what we just went over. Ask those three questions. Go through the pros and cons. Find out how many people are on the project, where it's going to be, what's going to be the best process for accessing the specs and catalogs. Once you get the answers to those questions, you can then make a plan.

You can implement that plan-- and then, hopefully, not have to deviate from that plan. And as a result, you end up with a successful project-- or we'd like to think so. We can't iterate enough the use of that batch file. That's going to take care of a lot of issues, making sure that everyone's using current specs and current shared content.

But also, BIM 360 can take care of a lot of those issues, too-- especially if you're dealing with remote users, which everyone seems to be doing that now, having to work remote. So with that, I want to thank Ken for joining me in this, being my co-speaker on this. He and I have been working together for many years-- not working together as in the same company.

But we've been kind of tag teaming while he was at Autodesk and I was at other places. We've been working together with various clients. And it's been a good working relationship. It's good to be working with him for ECAD now. So with that, I think we're going to be moving into a question and answer period. And we'd like to thank you for joining us on this class.