Your 3D CAD software is generally an order of magnitude more complex than any other business software your company relies on right now. It’s complex in that it is difficult to use, and it’s complex due to all the millions of lines of code and mathematical calculations that run in the background. That’s why it takes considerable time to become proficient at using 3D CAD, and why things can go wrong quite often and quite spectacularly. When you’re considering a new CAD system, training and support should not be an afterthought – they are an essential part of any CAD implementation.
There are two different types of CAD support calls: “How do I?” type training-related questions, and “I can’t do my work” type bug and crash reports.
Let’s deal with the second category first. Because CAD is so complex, finding the cause of a crash, recovering corrupt data or resolving some other job-stopping event is an almost impossible task. You have to have some level of sympathy for the support person who is desperately trying to help you. Unfortunately, when these types of events frequently repeat themselves, sympathy flies out the window fairly quickly.
There are numerous reasons why finding the root cause of an error is difficult. Every user uses CAD differently. They work in different industries, designing their own unique products and there are multiple ways to model the same thing. One user may extrude and add fillets, while another may revolve a sketched profile. One combination of actions may crash the software and another may not. The end result is the same, but the path chosen to get there is different every time. This makes it impossible for CAD developers to predict how the software will be used and therefore impossible to predict when and where the software will fail.
What Causes Crashes?
Crashes are either caused by the software or by the environment in which it is being used: the computer, the operating system, the graphics card and the biggest culprit of all, the drivers. Software-related crashes are easier to trace and fix as long as they are reproducible – which unfortunately is not always the case. Finding a hardware-related crash can be a game of cat-and-mouse because there is no way of identifying the cause unless the developer can build an exact copy of the machine, replicate the exact environment and replicate the exact steps that led up to the crash. This is, of course, impossible and certainly something that the developers don’t have the time or resources to invest.
To this end, CAD vendors often provide a certified list of supported hardware platform combinations, including details such as the operating system version and service pack number, graphics card type and driver version, and even CPU brand and hardware manufacturer. These certified lists limit a customer’s options and often necessitate the purchase of new and expensive hardware. But they also provide a certain level of reassurance that they won’t encounter any problems if they use a computer that matches these specs. Or will they? These lists can also serve as a blanket rebuff for CAD support personnel. Not using certified hardware? “Sorry, can’t help you!”
So what should you do when you see the dreaded crash report dialog? That’s a good question and apparently, the answer is not as straightforward as you might think.
Typical Vendor Response for Dealing With a Crash
In a blog post, SOLIDWORKS details their support process and recommends that you print out their support flowchart and pin it to your office wall. Yup, you read that correctly. Having problems? Consult your flowchart!
Of course, you don’t really need to look at the flowchart, all you need to do is call your Value-Added Reseller (VAR) and they’ll manage the flowchart steps for you. At a high level, the flowchart details the hoops that your VAR support team must jump through in order to get your vendor to fix that show-stopping bug or come up with an acceptable workaround. This may explain why some bugs take forever to get fixed, if at all. What the flowchart doesn’t show you is everything that happens – or is required to happen – at each stage of your support journey. So let’s dig into this a little deeper.
The crash report screen above will send details to your CAD vendor, not your VAR. In developer-speak, this is called a “stack trace” that tells developers which line of code caused the crash. Most of the time, a crash seems random and is not reproducible. In these situations, all you can do is shrug and try to recover your lost data or start from scratch all over again. If it happens consistently, you need to call your VAR – sending a crash report won’t help as it will likely end up on a “must fix someday” list and you will never hear of it again.
Once you have initiated a support call with your VAR, you will need to detail, in full, what the problem is and what you think caused it. If it is a “How do I?” type question, then your VAR support person will ask you to download and install some screen-sharing software so you can show them what you are trying to do. They may be able to help you or suggest a workaround right there and then. If not, they will need a copy of some or all of your files so they can try to resolve the issue offline and call you back when the problem is solved. They may even need to call the vendor’s support team to get advice from them, and then relay that information back to you.
This process is not very efficient and can be frustrating waiting to hear back.
The same agonizing process applies when reporting a bug or a crash. If it is reproducible, you’ll need to either write out the required steps, create a video or screen share with the support person live. Unless the bug or crash is generic, you’ll need to share a complete copy of your design files, detail the steps to reproduce the issue and send the exact specifications of your computer, operating system, other installed software and driver versions.
This takes a lot of time and effort to orchestrate and is probably the reason why so many bugs and crashes go unreported. Here’s your Catch-22: If you don’t report a bug, it won’t get fixed. If you do report a bug, by the time it gets fixed, it may no longer be relevant. You may have already moved on to other projects where the bug does not manifest itself, or you may be so used to using the workaround that you’ll never notice if the bug was fixed or not.
Getting CAD files to your VAR is a very manual process requiring you to collect all the files together, ZIP them up and then upload them to the VAR’s FTP site with a support call reference number. Then it’s a waiting game. By the time you receive a response, those files may well be out-of-date or you’ve found your own workaround. Point blank: You simply cannot afford to halt a project while a problem is being investigated.
Typical CAD VAR Solutions
Your VAR’s eventual follow-up may consist of 3 possible solutions:
- Additional Training is Required – This could be as simple as an explanation of how a particular set of design problems should be tackled or a best practice guide that should be followed.
- Your Data Needs to be Modified – In order to get a particularly difficult set of geometry conditions to work, the modeling steps you used may need to be tweaked. This could be communicated verbally so that you can make the changes yourself or a fixed part file could be sent back from support (which also requires an explanation of what was changed).
- The Software Needs to be Modified – This takes time and depending upon the priority of the fix, may not be completed for months, years or even ever. Once that fix is shipped in a service pack, you then have to download, install and test the fix, as well as check that there have been no regressions that may affect your other design files. If the fix is included in the next major release, you may not be able to install it anyway if it puts you on a different version than your customers and suppliers. You will also have to update all your files to be compatible with the new release, which often creates a new set of problems.
Surely, there must be an easier way to get support.
How Onshape Set a New Standard in Customer Support
Onshape is the only product development platform that runs entirely in the cloud. Its unique database architecture enables you to access your design data from anywhere on any device, either through a web browser on a computer (Mac, PC, Linux, Chromebook) or via dedicated apps for iOS and Android devices.
The complex calculations required to run CAD are all carried out on Onshape servers in the cloud. The local web browser displays menus using JavaScript and graphics using WebGL – technologies that are well supported and tightly integrated into modern browser software. This delivers device independence that immediately eliminates almost all hardware-related issues. In the unlikely event that you do experience an issue that can be attributed to your hardware setup, you can at least carry on working on another computer until we resolve the issue. All we ask is that you use a supported browser and keep your drivers up to date.
If you need help with a particular geometry problem or you think you’ve identified a bug, getting help from Onshape Support couldn’t be easier. Just click “Contact Support” from inside Onshape and describe the issue with both text and on-screen markup tools (read about Onshape’s built-in Feedback tool here). Since Onshape stores all your design data in the cloud, there are no CAD files to send. Enabling “Share this document with Onshape support” and clicking “Send” will automatically create a new support ticket and give the support team direct access to your design data.
One of the benefits of dealing directly with Onshape, rather than an intermediary third party VAR, is that the support team uses all the same diagnostic tools as the development team and has direct access to user-generated logs. Not only can they track trends and identify problems that the users are experiencing, but also track those that occur behind the scenes. Bugs can be quickly identified, diagnosed, addressed and deployed without the customer having to do anything to apply the fix – no downloading hotfixes, no patching of computers, no regression testing required. All of those things are taken care of by Onshape’s Support, Development, QA and Operations teams.
Furthermore, bugs identified as a high priority can be fixed and deployed within hours to every user worldwide. This is only possible with Onshape’s unique database architecture.
Onshape’s support team also works closely with development to define new features and refine existing ones. When customers request product improvements via support, they may well be conversing with the same person who defines how these features will work and how they will be incorporated into the product. As such, we may ask for additional feedback within the ticket. You certainly won't find that level of customer service with any other CAD vendor’s support.
Finally, it should be noted that Onshape never crashes. Yes, this is a bold statement. To clarify, while software crashes may still occasionally occur, our users never experience them. If there is a crash, you will most likely not even notice. Each user session is supported by multiple servers and low-level software components – if one of those fails, another one takes over in just a few milliseconds. Your data is automatically saved every time you make a design change so even if you suffer a power outage you can pick up your phone or tablet and carry on where you left off.
This unique support mechanism, like everything else in Onshape, was an important consideration right from the very start and was integrated directly into the product to make life easier for our customers.
Regardless of which product design tools your company is using right now, you should demand that their bar for customer support is as high as Onshape’s. Want a basis for comparison? Give Onshape a test drive today.