Monthly Archives: February 2018

Discarded Autodesk employees – how old were you when you were let go?

Some things have been mentioned to me privately that have made me curious. Curiosity is like an itch for me, I just have to scratch it. So here goes.

If you have been let go, fired, made redundant, discarded, dumped, sacked, had your office closed, encouraged to take a termination offer, sidelined into an untenable position, failed to have your contract renewed or otherwise ceased your employment at Autodesk in a not-entirely-voluntary manner in the last ten years, I’d like to know how old you were at the time. There’s a poll in this post and in the left sidebar.

Loading ...

The overall results will be public, but the individual responses will of course remain private. Feel free to add your observations in the comments, with or without your real name.

Guest post (BlackBox) – Why every click counts

5 Replies

With a bit of tongue in cheek, “This is not only my first guest post on [blog nauseam], it’s also my first guest post on any blog.” Thanks, Steve!

I get to write about one of my favorite AutoCAD features, and share a short personal story.

Yesterday I read Frank Mayfield’s article on time-sensitive Right Click, which made me recall an opportunity to help a new user on a design task the other day. I led them through an approach to mitigate a design issue, noticed they weren’t using time-sensitive Right Click, and asked them why?

User: Why not?

Me: Fair question; because it’s extra clicks.

User: It’s just a few extra clicks.

Me: Correct; every click counts.

User: Yeah, but it only takes a few seconds.

Me: Correct; how many seconds? Do the same task each way and time it.

User: <Does the task each way>… It only takes an extra 6 seconds.

Me: Good. Now extrapolate that; how many times a day do you do this?

User: Oh, all the time! Haha Hundreds of times a day.

Me: Okay, call it 100, because you won’t do that everyday.

User: 6 secs, 100 times a day, is 600 secs, that’s only 10 mins per day.

Me: Correct; extrapolate that over a year: 5 days, 50 weeks.

User: <Does the math>… Holy crap! 2500 mins? 41.7 hrs? That’s more than a week!

Me: Correct; you just cost the owner a week of otherwise billable time in extra right clicks. Get it now?

User: I get it now.

Me: I know. <Smiles and walks away> (<— Yes, I smile! A lot actually)

The user has since opted for the more efficient method on their own, and demonstrated this mindfulness for detail in other areas as well.

I show them the trade-offs and let them choose for themselves.

Accountability makes us better, more capable. Owning our decisions and learning from missteps earns respect. Only then do we see what a real team can do. #GetAfterIt

CAD Nostalgia Video

6 Replies

For the first video in the new cad nauseam YouTube channel, I’ve had a bit of fun. I unearthed a bunch of my old stuff to show you. Does any of this take you back? Enjoy!

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 2

2 Replies

This post continues my interview with Torsten Moses about BLADE, the new LISP IDE that arrived with BricsCAD V18.2. See here for post 1.

Steve: I’ve noted before that BricsCAD execution of AutoLISP and Visual LISP is several times faster than AutoCAD’s. How does the new technology affect that performance?

Torsten: All the new BLADE-related stuff doesn’t really affect normal LISP execution outside the IDE and debugger. The connection is made by a few callbacks, which take zero time in normal processing. Therefore there is also no chance of breaking things. The BLADE implementation is very safe, and performance remains high for normal usage. For the debugger and the synchronization, it is all home-brewed stuff, optimized for best performance even when debugging, and minimum system and LISP memory usage.

In the course of implementing the debugger and internal versus external synchronization, I also removed most emulations and implemented that as core OpenLisp functionality. That has the side-effect that the (repeat), (foreach) and (vlax-for) functions now run about five times faster at the loop construction. So rather than slowing things down, creating BLADE has actually speeded things up!

Steve: Will the Mac and Linux versions also get this feature?

Torsten: Yes, it is fully compatible. This is due to the implementations of WxWidgets and my own stuff. I have already verified BLADE running under Linux. There are no differences; even the implementation code has no Windows-specific stuff.

Steve: Can you give a simple example of the workflow of a debugging session?

Torsten: First, don’t pre-load any LISP file into BricsCAD. Such code loaded outside the debugger is fully functional, but it can’t be used for debugging. The special connection between internal and external representation is only established when loading the LISP code under a debug state.

Next, in BLADE open an existing FAS or VLX project, and/or a “Named Session”, or simply any LISP file you want to start debugging with.

Now you can select Start Debugging from menu or toolbar, or hit the F8 hotkey. The special Debug Toolbar will appear. You can either activate AutoBreak, which stops at first executable code, or activate the LISP source where you want to start debugging and place some breakpoints.

Then load the dedicated LISP file, either by the normal Load into BricsCAD function, or from the Load button in the Debug Toolbar. Now that loaded code is debug-enabled and you will see the file and debug-enabled functions in the two right tabs.

When the debugger halts at the first breakpoint, all debug-step modes are enabled in the toolbar, and you have all the usual debug step modes. More than in AutoCAD’s VLIDE, actually. You can set the watches (observed and tracked variables) as “Data Break Point” by activating the checkbox. Then, whenever that value changes, the debugger also stops automatically at the related LISP statement.

Steve: What if your code calls code in other files you haven’t loaded?

Torsten: Don’t worry about that. The debugger recognizes this and will ask to load the related LISP file on-demand. In normal LISP, you would get an unknown function error but the debugger catches this upfront. In fact, this is one of the high-end features – only load the primary LISP file, any further debugging into other files resolves by loading during the debugging session. This is very handy for dealing with complex apps – there’s no need to preload any other LISP source. I’m sure you’ve experienced Murphy’s Law, where the particular function you need is the one that’s not loaded. You won’t have that problem in BLADE.

Steve: Where to from here? Is this job done or is there still room for improvement?

Torsten: As BLADE is still a very young product, there is definitely a lot more to come. So far, the main target was to provide good debugging features, and a somewhat reasonable handling of projects, but not so much focusing on plain editor capabilities.

My to-do list still has a number of major key features to be implemented. We want to add a hotkey editor, because every developer loves his own keystrokes and learning others is a nightmare! We also want cross-reference checking on a per-file and per-session basis, mainly for bigger LISP applications.

Then, over time, the editor capabilities will be extended and improved, providing more features. One example is to provide an editor tooltip that shows a function signature and short help when hovering over a LISP function name.

And of course, I’m aware that when people start using this in production, a lot of feedback will arrive from developers in the form of wishes, hints for improvements and bug reports. It’s very likely there will be many wishes to implement several details to make BLADE resemble AutoCAD’s VLIDE more closely. This could be a bit difficult sometimes, and is also not the main target. I hope that developers will be open to a slightly different workflow, given the big advantages they get in return.

In general we are very open to developer ideas, needs and requirements, as we are with BricsCAD itself. In the end, it’s the developer who needs to work with BLADE, as easily and productively as possible. Even the initial release of BLADE is based on important feedback from beta testers such as Martin Drese (CAD Wiesel).

Steve: I can certainly attest to how well you respond to feedback. I’ve seen bugs I’ve reported fixed in a very short timeframe.

Torsten, thank you for your time. This has been very illuminating.

This interview is also available in one post on the Bricsys blog.

Interviewing the creator of BLADE – CAD’s best LISP IDE – part 1

1 Reply

Easily the most impressive new feature of BricsCAD V18.2 is the new Visual LISP IDE, BLADE (BricsCAD LISP Advanced Development Environment). The lack of any LISP IDE has been a BricsCAD stumbling block for a while, dissuading CAD Managers from adopting BricsCAD to replace their stagnant and increasingly expensive AutoCADs.

As I will relate elsewhere, Bricsys has not just caught up with Autodesk here, but has shot so far ahead it’s unlikely to ever be caught. BricsCAD’s BLADE is so superior to AutoCAD’s VLIDE in so many ways there’s really no comparison.

Yet it remains highly compatible. I have personal experience in making large amounts of AutoCAD LISP code (literally hundreds of routines) work in BricsCAD. That experience tells me that the vast majority of code will work just fine (and much faster) in BricsCAD. A tiny proportion of LISP or DCL code may need adjustment before it will work perfectly on both platforms, and that’s one reason an IDE that works within BricsCAD was an important step that Bricsys needed to take.

I had the chance to see this IDE privately in then-unnamed pre-release form when I attended the Bricsys Conference 2017 in Paris. I was surprised and delighted at the functionality demonstrated by its creator, Torsten Moses. I recently had the chance to interview Torsten about his creation.

Steve: I understand it was difficult to create a LISP IDE for BricsCAD because of the way BricsCAD’s LISP works. Can you explain that?

Torsten: BricsCAD LISP uses the OpenLisp core system, from French developer Christian Jullien. This is the only LISP engine still under development; the others I found stopped development in the mid-90s.

OpenLisp is a very modern implementation, not comparable to the old XLisp dialect used by AutoLISP. Even object-oriented features are supported. Therefore the internal representation of LISP expressions is different from the textual representation as seen in a LISP file.

Steve: So the AutoLISP code I write isn’t the code that BricsCAD executes?

Torsten: That’s right. A number of typical AutoLISP constructions were implemented by a kind of emulation, which drives the internal versus textual representation differences even further. That makes it a major challenge to synchronize the internal OpenLisp expression execution with the related textual representation in order to provide any debugging functionality.

Besides the plain technical details, which seemed to be virtually unresolvable, there was the expected heavy effort to implement a full-blown GUI. This was not just a plain editor, but the entire IDE GUI. It would have been a disaster, a major disgrace, if we had provided a VLIDE that was just up to AutoCAD standards. That was great in its time, but it’s 20 years later now. The idea of creating a LISP IDE for BricsCAD seemed so filled with difficulties that we put it off for a long time.

Steve: How did you finally manage to overcome these difficulties?

Torsten: First, it was a pure coincidence. [laughs] By luck, I discovered a hidden detail in OpenLisp – any LISP symbol (and expressions are a kind of anonymous symbols) can hold unlimited, attached custom data, very similar to XData in DWG database objects. I even knew about that for many years, but never worked out the shortcut to ‘misuse’ this for the LISP expression execution to editor and debugger bidirectional connection. Some initial quick tests showed that this approach was very suitable.

By another coincidence, I discovered that WxWidgets (our cross-platform system, not only for GUI) already includes support for the famous Scintilla editor, an OpenSource editor engine, widely used by many editors. WxWidgets even provides two levels of wrappers – a plain, core wrapper, and a high-level wrapper class system. This fits perfectly into the WxWidgets logic.

But still, that is only plain editor support – not a GUI. Then I found a very suitable, extensible editor and GUI implementation, based on that WxWidgets Scintilla system – as Open Source under the WxWidgets license. Hence, we are allowed to use that source code in a commercial application. That editor is called wxStEdit.

I verified that this source was suitable for our LISP IDE, and put in a lot of extra work to extend it. wxStEdit development finished in around 2008, and it still was compiling and working mostly fine. Nevertheless, in the course of extending that GUI, I found and fixed a lot of defects at all related levels (Scintilla, WxWidgets Scintilla wrapper and wxStEdit).

So it was this set of coincidences that suddenly opened both wings of a big gate!

See here for part 2 of this interview.

This interview is also available in one post on the Bricsys blog.

Bricsys shows Autodesk how to do mid-term updates – again!

5 Replies

BricsCAD V18.2 for Windows is out. The new stuff in this mid-term update is again showing up Autodesk’s lack of progress with its once-flagship product, AutoCAD. I’m sure Autodesk would love customers to accept that there’s only so much anyone can do with a DWG-based CAD product once it reaches a certain level of maturity. Customers should get used to nothing of significance being added year after year. Diminishing returns, and all that. Pay to continue using the product, but don’t expect it to get better.

What a shame for Autodesk, then, that Bricsys exists. By consistently providing a raft of significant improvements with each full and mid-term release, Bricsys shows up that idea as nonsense. It’s perfectly possible to keep improving CAD at a very rapid rate, particularly if you’re not worried about competing with other products in your range. There’s a reason AutoCAD’s parametrics are restricted to 2D, and BricsCAD’s 3D parametrics in a DWG product proves that the reason isn’t technical. It’s strategic. Also strategic is cutting the guts out of an already much-weakened AutoCAD team, because you would really prefer your customers to be using your trendier and/or more expensive products.

I should point out that BricsCAD V18 customers who have a perpetual license, even without maintenance, will be receiving V18.2 with all its improvements free of charge. Contrast that with Autodesk, which is, despicably, withholding even bug fixes from selected customers. Autodesk’s attitude to customers who aren’t constantly paying up front is one of utter contempt. Autodesk feels entitled to your money; Bricsys wants to earn it.

So what’s Bricsys done to earn your money with BricsCAD V18.2?

Mostly, it’s lots of relatively small-sounding things that add up to significant productivity enhancements. There are several items that are playing catch-up to AutoCAD, such as long-overdue in-place text editing. There are big performance improvements in drawings with PDF underlays due to a smart multi-resolution cache mechanism. The 3D-to-2D generation mechanism has also been significantly sped up. Constraints (2D and 3D, unlike AutoCAD) are easier to create. Several 3D direct modeling operations have been made easier. That also helps with sheet metal design, which has seen other improvements.

In Bricsys BIM V18.2, a lot of smarts have been added. The mechanism for converting CAD models (including those made in BricsCAD Shape) to BIM models, BIMIFY, already did some fascinatingly clever things, but that’s been improved further particularly in the areas of structural member and room recognition. For those of us in Australia, support for our steel sections is very welcome.

For me, that’s not the big news. Oh, no. The big news for me is a thing called BLADE – the BricsCAD LISP Advanced Development Environment.

If you’re a CAD Manager or in-house developer and you’ve been waiting until BricsCAD had VLIDE, wait no longer. But this isn’t just catch-up. This is a big leapfrog over Autodesk’s sadly neglected IDE for CAD’s primary user programming language. There’s so much good stuff in BLADE that I can’t hope to do it justice here, so I will be covering it extensively in future posts. For now, here’s a statement for you:

If you program in AutoLISP or Visual LISP, you should be doing it in BLADE.

It’s that good. Really. Watch this space for details.

The download is small, the install is fast, it won’t harm your AutoCAD installation, and you can evaluate it free for 30 days. Links:

That awkward moment when I just failed to create BIM

1 Reply

I recently updated my resume, and I thought it might be relevant to include an episode from my early career. This post is an expansion on what I had to say about that episode.

I was managing a tiny CAD training and development company, Educad. Much of my time there was spent developing software called NIDIS (originally called NEEDS), a project that was started in 1987 or 1988 with Nixdorf Computer as the client. It was intended to take over the market among first the home building companies of Western Australia, then Australia, then the World!

What’s special about NIDIS is that it was a precursor to BIM. Using a 3D-adapted version of the 2D Educad architectural software within AutoCAD, designs of domestic homes could be efficiently created and infused with a degree of intelligence. This was then linked to the Nixdorf minicomputer-based software that contained pricing and other information about the various building components. This combined system enabled accurate quantity take-offs to be performed.

This was supposed to be a short project, but due to a massive amount of “scope creep” it took two years. I was really pushing the limits of what AutoCAD could be persuaded to do at that time and had to break new ground in several areas. Some of it was a kludge, but I made it work. Finally, the software was essentially completed, with a custom tablet menu (remember those?), full documentation and everything. Nixdorf CAD-spec PCs with big screens, tablets, AutoCAD and NIDIS were installed in the drawing office. It was successfully tested in Beta. The take-offs were very accurate. Everything looked good to go.

Then, two weeks before it was due to go into production, this project died. The building company that was sponsoring it, Mansard Homes, went into liquidation as it struggled unsuccessfully with the combined effects of very high interest rates and bad publicity about poor building quality and cost overruns. Nixdorf dropped the whole project like a hot potato and the product was never sold. I didn’t have any rights to the software and couldn’t do anything with it.

But it was software that was based around a 3D model of a building that contained some intelligent information, albeit extremely crude by today’s standards. I wrote, quite literally, Building Information Modeling software. It was completed in 1989, before the name BIM had even been used. The idea had existed since the mid 70s, but I didn’t know that at the time so I made it up as I went along.

I didn’t actually invent BIM, but I made something that resembled BIM that actually worked. And then it didn’t.

This is easily the most spectacular failure of my career. Still, I’m kind of proud of it.

Edit: for historical context, this video shows an unrelated system that was developed at about the same time as NIDIS.

Are your drawings SHOUTING?

9 Replies

This post was inspired by a question raised by Jamie Myers in the CAD Managers Unite! Facebook group.

Long ago, before CAD was in common use, I was taught technical drawing at school. One of the things I was taught was to follow drafting standards, BS308 at the time. Later, I was expected to follow AS1100. One of the things I was taught was to always use capital letters in text on drawings, using the approved ISO font. Without a machine, without a template. This stuck to me to such an extent that even today I use all caps when handwriting notes. Note to wife? Caps. Shopping list? Caps. I can’t help it, it’s hardwired.

Let’s do that paragraph again, this time using the case as it would be seen on most drawings in my experience, and as I would automatically tend to enter it on a drawing:

LONG AGO, BEFORE CAD WAS IN COMMON USE, I WAS TAUGHT TECHNICAL DRAWING AT SCHOOL. ONE OF THE THINGS I WAS TAUGHT WAS TO FOLLOW DRAFTING STANDARDS – BS308 AT THE TIME. LATER, I WAS EXPECTED TO FOLLOW AS1100. ONE OF THE THINGS I WAS TAUGHT WAS TO ALWAYS USE CAPITAL LETTERS IN TEXT ON DRAWINGS, USING THE APPROVED ISO FONT. WITHOUT A MACHINE, WITHOUT A TEMPLATE. THIS STUCK TO ME TO SUCH AN EXTENT THAT EVEN TODAY I USE ALL CAPS WHEN HANDWRITING NOTES. NOTE TO WIFE? CAPS. SHOPPING LIST? CAPS. I CAN’T HELP IT, IT’S HARDWIRED.

Show those paragraphs to 100 people in the street and ask them which is the most legible, and I’m pretty sure the mixed-case one will be chosen by the vast majority. It also uses up less space, which can be an issue on a crowded drawing.

You wouldn’t use all caps on the Internet unless you were SHOUTING because otherwise you would be mistaken for one of those unhinged conspiracy theorists. Just as I’m hardwired to write in upper case, I’m also hardwired to skip blocks of upper case text on the Internet (e.g. Terms of Use) without even attempting to read it.

Why, then, do so many of us still use ALL CAPS in drawings? Inertia? Standards?

There are some legitimate arguments that can be made to support the continued use of upper case on drawings. I was taught that capitals were used to ensure that when a drawing was reproduced, taken out on site and subjected to folds, dirty fingers and oil stains, the chances of something being rendered illegible was smaller in the case of a capital letter. It has been pointed out that ‘up’ and ‘dn’ are identical when inverted. Quick, is ‘l’ an upper case I or a lower case L?

I understand all caps usage varies substantially from country to country and the language used will also make a difference.

Let’s have your viewpoint on this subject. Please comment and/or pick a poll option. It’s a deliberately binary poll so you can’t fudge and have to pick one, and it’s about which one you think is better (most suited for purpose), not which one you use.

Loading ...

This and usually a few other polls live at the top of the left sidebar (on a PC browser). Here is the polls archive.

How to sign your LISP files

Gallery – Gent visit 2017 – Sights

How to obtain a digital signature to sign your LISP files

2 Replies

In an earlier post, I explained why you might want to digitally sign your LISP files. If you decide to go ahead with that, then this post explains how you can obtain and install the digital signature you will need to sign your files. This is the most difficult part of the process and it involves spending money.

Getting a digital signature

Although you can make your own digital signature (there’s an Autodesk Knowledgebase article describing the process), there’s little point in doing this. You can sign your files, sure, but that signature won’t be seen as trusted by software that checks for it. Anybody can create a signature like that, including one that impersonates you, and it doesn’t prove anything. The only purpose for such a home-made signature would be to test the methods you’ll be using to apply a proper trusted signature later.

Edit: if you do want to make your own signature, BlackBox informs me that the MakeCert tool in the Windows SDK mentioned in the Knowledgebase article is deprecated. He suggests using this PowerShell Cmdlet instead.

You’re going to need a signature that is trusted. That means you’re going to have to pay somebody trustworthy to trust you. There are a set of certifying authorities, trusted by Microsoft, Autodesk, etc. who can issue code signing certificates to companies and people. You need to prove who you are to one of those authorities and pay them to certify that you are who you say you are. So before you start, make sure you or your business are visible in terms of directory listings, publicly visible phone numbers, etc. If you are representing a company asking for a certificate, you can expect to be asked to produce evidence that you really represent that company. You can expect to confirm that your email and phone number are really under your control.

You only need to do this once a year, or even once every several years if you pay in advance. You might find that the evidence you need to provide changes at renewal time; for example a Yellow Pages listing that was OK in 2015 was no longer accepted when I renewed in 2017, so I had to register my business with another listing.

In my search for a certifying authority, I found that K Software, a reseller for Comodo, was the cheapest source for a code signing certificate, see here. An OV certificate will be fine for signing LISP.

K Software takes your money (USD $67 to $84 a year depending on the length of time you need), gets Comodo to provide the certificate, and provides a handy tool (KSign) that allows you to simply apply the certificate to various files without some of the messing about that’s otherwise required. It’s not useful for LISP files, though. Comodo also provides the support, and I’m happy to report that in my experience their customer service is excellent.

Note: it’s important that you pay close attention to the instructions when applying for your certificate. For example, the browser you use to apply for the certificate is vital. Choose one that’s suggested (e.g. Firefox) and which you expect to use later to obtain the certificate.

Installing a digital signature

Once your evidence is accepted and your payment has gone through, you will be sent an email with a special code, allowing you to obtain the certificate. It’s important that you’re using the same browser on the same computer that you used when applying for the certificate.

Once you click the link and obtain the certificate, you’ll want to export it. In Firefox 58.0, use Options > Privacy & Security and scroll to the bottom to see View Certificates. Select the certificate and pick Export. This will create a .P12 file that you can back up and install on this or another computer. To install the certificate, double-click the .P12 file and follow the prompts to assign it to the current user in the default location (Personal).

That’s it. You should now have a certificate installed that you will be able to use to sign LISP and other files. To check this, start the Windows Certificate Manager (C:\Windows\System32\certmgr.msc). Have a look in Current User > Personal > Certificates and you should find your newly installed certificate.

The next post in this series will explain how to apply this digital signature to your LISP files. That’s the easy bit.

Autodesk subscription offer – the first cracks appear in the all-rental wall

2 Replies

Thanks to a comment by Fabien, I recently learned of a new offer from Autodesk to convert perpetual licenses to subscription (rental). It turns out that this is a global offer from 7 February to 20 April 2018.

Such offers come and go from time to time and most are not particularly interesting. This one is. Not because you’ll want to take it up (you probably won’t), but because of what it represents.

Here’s how it appears on Autodesk’s site:

What’s really interesting about this offer is this sentence:

If you are not satisfied, you can switch back to your perpetual license.

With that, we see the first solid acknowledgement from Autodesk of the reason so many existing customers are stubbornly refusing to put themselves in rental chains, despite the cracking of price whips. Customers like their perpetual licenses and are unwilling to give them away. This offer holds out the promise that they can be returned. There’s a lot of fine print that severely restricts the utility of the offer and I can’t see many savvy customers falling for it, but at least an attempt (however weak) is being made to placate perpetual license holders.

The offer is explained in the FAQs and more detail is available in the Terms & Conditions page. Here’s an overview of how it works.

You trade in your perpetual license of AutoCAD, LT, Suites or several other products using this link. These can be out of maintenance and could date back to Release 14 from 20 years ago*.
You sign up for subscription of an Industry Collection for 1 or 3 years. Of course, the subscription cost of an Industry Collection is pretty substantial and way more than the maintenance costs of, say, AutoCAD – even with Autodesk’s promised price hikes. For example, the AEC Collection is USD $2,018 a year under this offer, down from $2,690.
The subscription cost is 25% less than it is without this offer. It’s still pretty expensive, particularly as you can’t use more than two applications in the Collection at once, but it is a bit less than is would be,
You are given the option of backing out of the deal (“switch back” is the Autodesk term) within a specific 30-day window if not satisfied. That window is at the end of the full 3-year period, or after 2 years if you sign up for 1-year increments. You get your perpetual license back. You don’t get your money back.
If you switch back, it’s up to you to make sure you have the media and necessary details to reinstall the old release.
If you switch back, you don’t get to resume maintenance if you had it. If you didn’t already have your product under maintenance, this is fair enough.
If you switch back, your perpetual license is reverted to its original release. Oh, except if you started at 2017 or 2018. In that case, you are reverted to 2016.

That last part is a nasty, petty detail. Somebody at Autodesk actually thought that up, presented it at a meeting and had it accepted as a good idea. That’s the mentality we’re dealing with here. It’s not so much “How can we better serve customers so they want to give us more money?”, it’s more “How can we hurt customers who don’t do what we want?”

If you take up this offer, the idea is to get you using the new software because there’s a bit less finality about the decision. You might be so impressed by it that you forget you’ve discarded your escape plan and signed yourself up for perpetual payment of large amounts. You might also find that you’ve saved all your files in new formats and can’t go back without losing data, particularly if you’ve used the vertical products that really, really don’t like having their drawings saved back to earlier releases, even within the same nominal DWG format. So maybe there’s a bit more finality than first appears, but by the time you’ve got to that stage it will be too late.

Is this an attractive offer? Only if you were going to subscribe to an Industry Collection anyway and have an old dormant license hanging around. In that case, go for it, save 25% of a large amount. Other than that, it’s really not an offer that will have widespread appeal and I suspect most customers will give it a miss.

Autodesk is getting increasingly desperate to get its long-term customers on the rental gravy train, and the cracks have started to appear in the subscription-only facade. This offer’s not great but I suspect the offers are only going to get better as the “Another great quarter!” patter wears thinner and thinner. The offers will have to get much better than this effort to persuade your average perpetual license owner to get on board.

* Pedantic historical point: in multiple places, this promotion associates Release 14 with the year 1998, implying this is the earliest year you could have bought an eligible product. This is incorrect. Release 14 was released in February 1997 and was replaced by AutoCAD 2000 in March 1999.

Gallery – Gent visit 2017 – People

Why digitally sign your LISP files?

4 Replies

After I mentioned in an earlier post that I had digitally signed the sample LISP file I had provided, this generated some interest. In this post, I’ll explain why you might want to sign your LISP files. In a later post, I’ll explain how to do it.

These days it is standard practice for developers to digitally sign their code. Operating systems and applications are displaying increasingly scary warnings when coming across unsigned code. Here is an example of the sort of message you get when you load an unsigned LISP file into AutoCAD from a location that has not been explicitly configured as a trusted location:

If you’re a CAD Manager dealing with your own internal code, it’s not too onerous to configure AutoCAD in Options > Files such that a folder is trusted by AutoCAD and place your code in there. The folder should be read-only; if it isn’t, AutoCAD warns you when you try to configure it. If you do this, the scary warnings don’t appear to bother and confuse your users, even if your code is unsigned.

Another way a CAD Manager can avoid the warnings is to set the SECURELOAD system variable to 0. That’s generally not recommended because it turns off AutoCAD’s security features. While you’ll probably get away with this, there’s always a chance that a user will load some malware and then you’ll have to explain yourself to management.

If you’re not just using your code internally and it’s going to be used by other parties, then you’re not going to have that level of control over the user environment. In recent AutoCADs it’s possible to set up the installation deployment such that users can’t turn off the security settings. If the CAD Manager at the location using your code has done this, your potential users are going to be presented with unprofessional-looking scary warnings.

If you sign your code, users might still get a warning, but it’s less scary. It identifies you as the verified source of the code so they will have more confidence in picking the Always Load button. Once they’ve done this, other signed code of yours will be automatically trusted.

There’s another important reason you might want to sign your code, and that’s protection against other people’s modification of your code. If somebody edits your LSP file and then gives it to someone who tries to load it, the user is presented with an even scarier warning:

Note that this warning no longer has your name on it. This means it’s possible to protect yourself from people (internal or external) who well-meaningly hack about with your code and then try to blame you when it goes wrong. It also gives a level of protection against your code being infected by malware.

Note that all of the above only applies to AutoCAD 2016 and later. AutoCAD 2014 introduced some LISP loading security measures, but the signature stuff came a couple of releases later. Earlier AutoCAD releases, along with compatibles such as BricsCAD and ZWCAD, will just ignore the digital signature. It’s just a comment in the code as far as they’re concerned.

LISP files with the LSP, MNL, FAS, or VLX file extensions can be digitally signed. There’s a bug in the original iterations of AutoCAD 2016 and AutoCAD 2018 that prevents signed VLX files from working. This was patched later in both releases (2016 SP1 and 2018.0.2), but if you’re distributing your code externally there’s always a chance that your VLX might end up in the hands of somebody using a broken release. Also, VLX files that are digitally signed cannot be loaded into AutoCAD 2015 and earlier, broken or not. You should bear that in mind before distributing signed VLX files. I don’t do it and would advise against it. Thanks, Autodesk.

Given this information, if you decide that signing your LISP is a good idea, watch this space for information on how to do it.

Setting your application or document window size using LISP

1 Reply

I intend to produce a few videos containing tips, tutorials, product comparisons and the like. I’ve set up a cad nauseam YouTube channel, but don’t bother visiting it yet because it’s empty.

One of the things I need to do for these videos make sure I’m capturing the screen at an appropriate resolution. I knocked up a bit of Visual LISP to take care of this task quickly and accurately, and you might as well have it. It’s a simple routine that allows you to accurately size either the main AutoCAD application window or the current document window (drawing area) within the main window.

The file is WindowSize.lsp. It should work in all full AutoCAD releases (not counting LT and AutoCAD for Mac) and AutoCAD-based verticals from 2000 on.

It works in recent BricsCAD releases (except the free and LISPless BricsCAD Shape). I’ve only tested it in Windows, but it should also work in the Mac and Linux versions due to the high degree of LISP compatibility provided even across platforms. It also works in ZWCAD 2018 for the main application window, but don’t use it on the document window because that doesn’t work.

Download it, put it in a location of your choice and load it into your CAD application (for example by dragging and dropping it from Explorer onto the drawing window).

Note: In AutoCAD 2014 and later, loading any LISP or other executable file may result in a warning depending on the release, the security settings, whether the file is located in one of AutoCAD’s trusted locations, and whether the file is digitally signed. I’ve digitally signed the file to reduce the incidence of warnings, but you could still see something like this:

The verified publisher should be cad nauseam as shown above. If you pick Always Load then you shouldn’t see the warning again for this file or any others signed by cad nauseam. Feel free to edit the file for your own needs, but if you do the signature will become invalid and you’ll be warned again when loading the file.

Once it’s loaded, enter the command WindowSize. The prompt sequence goes like this:

Command: WINDOWSIZE Window to size [Application/Document] : Width in pixels <1280>: Height in pixels <720>:

Now, back to work on the first of those videos.

Autodesk kills ArtCAM, proves subscription is terrible for customers

18 Replies

This story goes back over 50 years. A British company called Delcam was founded in 1965 and developed many products. These included ArtCAM, an application for producing 3D parts using 2D artwork as a base. It won a Queen’s Award for Innovation in 2003. In 2014, Autodesk acquired Delcam for approximately USD$286 Million and ArtCAM (among others) became an Autodesk product.

As with all Autodesk products, sales of perpetual licenses ceased a couple of years ago. Owners of perpetual licenses were encouraged to ditch them and switch to subscription instead. Financially encouraged, with “discounts” and promises of price rises for uncooperative customers. You’ll be familiar with this part of the story.

Now, Autodesk has killed ArtCAM. The FAQ is here, but as of right now you can’t buy a new ArtCAM subscription. You can renew an existing subscription until 7 July 2018. Support ends on 1 November 2018. Support will be of limited value because bugs are highly unlikely to be fixed, especially if what I hear about the development team being fired last November is true.

Are you an ArtCAM customer wondering what this means for the future? Here’s what happens if you followed Autodesk’s advice and switched to subscription:

You stop using the software as soon as your subscription runs out. Immediately. No negotiation will be entered into.

Here’s what happens if you didn’t follow Autodesk’s advice and kept your perpetual license:

You get use the software for as long as it still works.

Which of these scenarios would you say is preferable from a customer point of view? Yes, it’s a rhetorical question similar to, “Would you prefer to: a) cut your own head off with a blunt rusty saw; or b) not do that?”

Remember when I said subscription was a trap and you shouldn’t fall for it? Was I wrong?

OK, hands up all those customers who still think Autodesk subscription is a good idea. Anyone?

I’ve added ArtCAM to the Autodesk Graveyard. Anybody who thinks this can’t happen to their product should read that page and ponder how many Autodesk customers thought their product would permanently persist.

Autodesk has lost some of its best people

15 Replies

If you follow certain people on social media this may not be news to you, but Autodesk has just suffered a shocking loss. People at SOLIDWORKS World were amazed to see Lynn Allen, probably the most famous person in CAD, and for decades the face of Autodesk, in attendance.

Image credit: Craig Black via Facebook

No, she wasn’t spying on the competition; she’s praised aspects of what Dassault is doing and has described the event as “pretty amazing”. In her own words, she’s now a free agent. Lynn, a highly professional and entertaining presenter, was undoubtedly Autodesk’s biggest drawcard. No more.

This story is much bigger than one person,though. Other highly competent long-term Adeskers to move on include docs and tips wiz Heidi Hewett, highly professional AU manager Joseph Wurcher, Inventor guru Jay Tedeschi, marketing manager Justin Hoey and PR director Noah Cole. Just the people I’ve mentioned here have well over a hundred years of experience and knowledge, but they are just a handful of the 13% of employees Autodesk is losing this time round. This cull is following on from another 10%, not that long ago.

The entire Neuchatel office in Switzerland has been closed, although Kean Walmsley survived (thankfully). I guess if you’re just holding station on improving your products and moving into rent-the-same-thing-every-year-and-jack-the-prices-up mode then there’s not much call for research and development.

I’m not going to speculate on whether any of the people I’ve mentioned were pushed out, took advantage of an attractive redundancy offer, or just decided it was an opportune moment to jump from a ship of questionable soundness. That’s a private matter between those people and their former employer. I will say that if Autodesk really wanted to retain these people it could probably have made that happen.

Why would Autodesk allow this much knowledge and skill to walk away? Same answer with everything Autodesk does these days that has people scratching their heads: money. Long-termers cost more money, so lopping them looks like an easy way to cut costs. If they’re competent and knowledgeable they’re worth every penny, though. Top people can be many times more productive and valuable than not-so-top people. Given Autodesk’s not-yet-successful attempt to be Adobe, the beancounters are desperate to make it look like the bottom line is about to improve.

While it’s true that the graveyard is full of indispensable people, my experience tells me that losing top people is almost always a false economy. Because the financial penalties of lost institutional knowledge often aren’t directly attributable and don’t show up on a spreadsheet in a handy “losing X cost us $Y” format, it’s easy to pretend those penalties don’t exist. They do, they’re real, and they’re coming Autodesk’s way.

I wish all of the people affected by these events all the best with their future. Onwards and upwards!

Edit: Principal User Experience Designer Bill Glennie, familiar to many pre-release testers of Autodesk products, has also gone.

Why Bricsys makes the best AutoCAD for Mac

3 Replies

Bricsys has just released BricsCAD V18 for Mac. Here’s the download link and here are the release notes.

BricsCAD V18 is an excellent DWG 2018-based CAD application, and the Mac version lacks little in comparison to the Windows version. It’s so much more capable than the perpetually half-baked AutoCAD for Mac that I struggle to comprehend why anybody with the choice would even contemplate the notably inferior and seriously overpriced Autodesk offering.

That’s not just opinion, it can be supported objectively.

Price first. US prices are shown here for a single standalone license over five years, inclusive of the cost of upgrades. The BricsCAD prices therefore include maintenance (it’s optional); the Autodesk prices are for subscription (not optional). No temporary discounts have been included. I have excluded bargain-basement BricsCAD Classic because it lacks the full set of programming and 3D modeling tools. I have assumed that there will be no price increases over the next five years. Given recent history, that’s probably close to the truth for Bricsys prices. Autodesk, not so much.

Year	BricsCAD Pro	BricsCAD Platinum	AutoCAD
1	970	1330	1470
2	240	240	1470
3	240	240	1470
4	240	240	1470
5	240	240	1470
Total	1930	2290	7350

It’s worth noting that if you want to stop paying Bricsys, you’re left with the latest version to use indefinitely. You can change your mind and get back on the upgrade train later, if you like. That sort of flexibility is long gone at Autodesk, where subscription means no pay, no play. If you stop paying, despite having paid 3.2 times as much for your software over the five year period, you’re left with nothing.

Now, features. You may have noticed that Autodesk is now too embarrassed to list the differences between the Windows and Mac versions of AutoCAD on its web site. The Compare AutoCAD vs. AutoCAD for Mac page is now a shadow of its former useful self, devoid of all detail. If you want to get a reasonable idea of what’s going on with AutoCAD for Mac’s deficiencies, you can check out my post about the 2017 release that lists the missing features.

Alternatively, you can have a look at the equivalent Bricsys comparison page, which you should probably do anyway before spending any money. It’s strange that you now need to visit a competitor’s page to get detailed information about an Autodesk product, but in the CAD world these are strange days indeed.

It’s important to note that the Bricsys comparison page has issues; while the BricsCAD columns are up to date, the AutoCAD columns are a year behind. That page definitely needs an update in order to provide a fair comparison. Don’t rely on it completely (e.g. all of the listed products except BricsCAD V17 for Linux use DWG 2018 as the native format, not DWG 2013), but it will give you an approximate idea. Look at the little red X marks in the rightmost column and you’ll see that a whole bunch of the missing AutoCAD for Mac features, even after all these years, are very significant and their absence could rule out the product for you. Don’t expect much in the way of future improvement. either. AutoCAD for Mac is in maintenance mode, just like the full product.

BricsCAD for Mac is not just more fully-featured, it’s ironically also more AutoCAD-compatible than Autodesk’s effort. For example, try to run a selection of LISP routines in both products. Almost all of it will run just fine in BricsCAD. Anything that uses ActiveX or DCL (dialog box) calls simply won’t work in AutoCAD. You might be all right with some simple routines (if it was written for AutoCAD for DOS then it will probably be fine) but any LISP even moderately sophisticated is going to fail.

BricsCAD for Mac doesn’t just provide capabilities that AutoCAD for Mac doesn’t have and never will, it offers something more than that. It offers a path beyond basic drafting. You can abandon all hope of Revit for Mac – that won’t be happening. AutoCAD-based vertical products? Nope. Inventor OS X? Forget it. But the availability of a product like Bricsys BIM for Mac (not priced above – it’s US$770 extra if purchased seperately) is an obvious drawcard for Mac-happy architects. You can create 3D parametric models on your Mac if you use BricsCAD Platinum, and you can create them without straying far from a familiar AutoCAD-like environment. Sheet metal? Sure (at extra cost).

If you’re a Mac-only person and you’re wedded to Autodesk, you’re not only being ripped off, you’re following a dead-end path. Time to check out the alternatives.