If you joined us last week to see the visual changes to be expected when you download 17.4, doubtless the next thing you need to know is how migrating will impact your automation. And, if you’ve installed the software already, you’re one step farther ahead!

Automation comes in two primary forms. First, there are scripts (and macros) which you record once and replay to perform the same operations Second, there are the custom SKILL tools that your team may have implemented. Today, we’ll focus on the first type – scripts – and changes you should be aware of when moving from 17.2 up to 17.4.

Macro Scripts

Have been a user of macros in the past? If so, you may have noticed an issue replaying them in 17.2. While the replay of the macro would ask you for the origin point to use for the script, it would always reference the original locations from when you recorded. This makes the macro less portable.

With 17.4, the behavior is back to what you would expect. Start using your existing macros again or record new ones that will speed up your design work (and save your fingers) by removing the repetitive nature of certain tasks.

Important note for those of you who create repeating macros – those that include the “repeat_again” statement at the bottom: Repeat again allows you to keep running the macro (picking a new origin each time). Since your macro isn’t running when waiting for your origin pick, pressing escape won’t cancel the script. When you are finished with a repeating script, type “return” on the command line to stop.

Make those macros work magic for you!

Color / Visibility

17.2 scripts work well to change the visibility and colors of layers in your design. However, they are not portable from one design to another when the two designs don’t share a common stack-up. The image below shows a 17.2 script which changes the color of two layers in a design; below that is the same script, but recorded in 17.4:

I’m sure you spotted the difference right away. In 17.2, the script references rows and columns in the color form’s grid. With 17.4, the scripts instead reference the layer’s class and subclass names. 1, 1 has been exchanged for Base, Via.  Because of this, you can use the same script in a four-layer substrate and one with twelve layers to turn off the base layer vias.

Now, the 17.2 script will function the same in 17.4. The tool still knows where row 1, column 1 is in the table. If you have recorded scripts in 17.2 for use with a design, there is no need to record them again. However, if you record new scripts in 17.4, these are not backward compatible to 17.2. Boldly go forward with your new scripts!

Speaking, as we are, about color and visibility, this is a good segue to another change many of you have asked for. Individual layers may be added to the visibility tab in the “User Selected” selection. This was done for each individual design. In 17.4, if you instead have a standard set of layers you want in this section, and you want to avoid manually adding them in each new design start, enable the “display_custom_vis_layers” user preference option.

The tool will read a file of the layers to show in this section when the variable is enabled. The file can be in your local environment or even at the site level, allowing for a common experience for all your users. An example of this file is shipped with the tool and can be found in the share/pcb/examples folder. As shown below, add the entries (in order to be displayed) that you want to see:

If a layer, like Not_Existing, doesn’t exist in the current design, that line will be silently ignored. Create a single file of the layers that are frequently used across all your substrates and rely on the tool to show those that are part of the active drawing. Easy!

Cross-Section

Your cross-section editing needs may not get scripted all that much, depending on how you initialize your designs. Many design teams I talk to have technology files for the different stack-up variations they support, allowing them to simply import the techfile to fully configure their cross-section (and many other things!).

If you do not, and instead you rely on scripts to initialize or tweak your layer stack, then you will need to record your scripts again. Your 17.2 scripts won’t replay directly in 17.4, unlike the color form updates above. See below for a comparison of the two scripts. This is 17.2:

… and this is the same script from 17.4 to perform the same operations:

Should you make a lot of cross-section edits in this way, you may want to consider moving to SKILL for making those same changes. This will free you of the need to maintain your scripts from release to release, while also allowing them to run faster (the forms don’t need to come up to be an interpreter for the changes to be made to the database).

If you aren’t familiar with SKILL and need help getting started, see the share/pcb/examples/SKILL folder for many examples and a full list of the functions available. Beyond that, there are the SKILL forums online and, of course, your customer support experts. A one-time investment will save you time down the road!

Constraint Manager

Our final area for this week is Constraint Manager. You no doubt noticed the modern look and feel of the interface. Did you wonder if those changes necessitated any updates to your recorded scripts? The answer is yes!

The changes are like those for the cross-section. Shown below, a simple script example changes the minimum line width on a layer to 100 um from its default value of 75 um.

The same actions look, by-and-large, the same in 17.4. It’s the subtle differences which need to be updated in your files:

To be sure that your script is compliant, our recommendation is to record the script again. If instead, you generate these scripts procedurally with SKILL or another tool, then your generator will need to be tweaked to the new standards.

Conclusions

These are the biggest areas of scripting changes to be aware of. If you are going to maintain parallel 17.2 and 17.4 development environments, be sure that you don’t overwrite your 17.2 scripts! You’ll still need them when working in that release.

We always try to minimize changes required to scripts, as we respect that it causes you additional work. At times, though, changes are required to better support your needs. That’s the case here, with 17.4. Bear with us. The changes are more than worth it!