To Script or Not to Script, That is the Question

BEFORE YOU WATCH - the purpose of this video is to provide a very high-level overview of scripting in Altium Designer. This is not a 'how-to.' It provides an overview of what you will need to know going into this effort. Unfortunately, this is not a trivial effort.

Along with this video, please consider the following commentary:



Many high-end tools offer the ability to script. It is a feature that interests most engineers who are always looking to automate repetitive or tedious tasks. Embarking on a script, especially one that has to do with evaluating the position of primitives, is much like writing a novel. It may be exciting initially, but it can take a lot of time and perseverance to get it up and running flawlessly. More often than not, even though we have the interest, work obligations get in the way.

For example, if one can repeat key clicks and mouse motions 100 times and do it in 5 minutes, is it worth investing 20 minutes researching if a specific feature exists and, if it does, how to use it? Then, is it worth investing 1 or 2 hours if it needs to be coded? If mashing a bunch of keys and mouse clicks dozens of times is a one-time proposition, then most of us grin and bear it. We may consider other options if we have to do it again at some time in the future or know that our colleagues could also benefit from automating this task.

This question was posed to one of our experts in Altium scripting. As scripting was not tricky enough, Altium made it more difficult by not providing all the processes and options. When someone approaches Nine Dot Connects about a script, it is carefully reviewed to ensure that scripting is a viable option.

As for whether one should pursue a script, consider one or more of the following criteria:

• Does it meet (a) specific need(s) which typical users believe is needed, in which they have difficulty remembering or implementing the process without making mistakes?
  

• Does it significantly speed up routine processes therefore saving valuable time?
  

• Does it automate a manual process that is so complex, obscure, or esoteric that it is tough to remember correctly?
  

• Does it automate or incorporate a too-complex feature (computationally or otherwise) for the user to do manually?
  

• Would it be simple and fast enough so it saves significantly more time than it takes to use it?
  

A good script is more than pressing a run button. It needs to provide feedback. It should have control and reporting dialog boxes to confirm it is being run, allow setting options, and summarize immediate results.

If the script is going to be sold, it needs to provide much more value than it costs to invest in the tool.

In all cases, it must not conflict with procedures a company has already established (such as file naming and storage protocols, configuration management, etc.).

It must also be done fairly regularly so the user does not forget how to use it. For example, a script to draw schematic templates (with borders, zones, title block, parameters, fields, section indicators, different sheet sizes, top vs. continuation sheets, logo insertion, etc.) could be nice for a design service, but not of a lot of value to a customer at one company who would only do it once.

It would be of little value if its sole purpose replicated the tool's intrinsic function, such as checking for connectivity. It is much safer to check and report on conditions than to modify or create a layout because of the esoteric relations to other things.

To be created and used correctly and effectively, scripts should do relatively simple and well-bounded tasks (although repetition is straightforward). For example, a script to move vias onto the nearest grid would be simple but fixing the aftermath would be complex and perhaps even impossible.

And finally, make sure that all other workarounds have been sought or considered before embarking on this effort.

More Information