Enginursday: Configuring EAGLE PCB Design Software with a ULP
A ULP to customize Eagle like the SparkFun engineers
Some people don't like spending the time configuring software and would rather get to work. We've written a drag-and-drop solution to configure Cadsoft's EAGLE to work the way we use it internally.
We provide this functionality with an EAGLE ULP. ULP stands for user language program. It's an interpreted C like language used to write custom features in EAGLE. By default our ULP will download all of our libraries and other useful EAGLE files. It will then configure all of the keyboard short cuts and colors to what we use internally. It will also setup EAGLE to only use our libraries. Don't worry, all of the stock libraries will be left alone. You can still find them in the control panel, but they won't be in the way when it comes time to add parts to designs.
One-Minute Guide
If you want to quickly test out this script, here is a super quick and easy way try it out.
- The first step is to Download The ULP (On some browsers you will have to right-click this download button and manually save the file.)
It doesn't really matter where it downloads, as long as you know where it is.
- Now launch EAGLE and open any schematic or board, or even use a new blank one.
- Drag and drop the ULP you downloaded onto the window. A dialog similar to the following one should pop up.
Figure 1. Main dialog
- Press enter or return, or click the OK button. A second dialog box should open up warning you about potential download speed issues.
- Again, press enter or return, or click the OK button.
The user can tab through the options to change which button enter/return activates like decent software tends to do.
Figure 2. Download status info
- Wait until the dialog box in Figure 1 goes away and you are done!
If something goes wrong, an error message will open in a modal dialog box & you will know.
Options
In the previous section about the ~ three-click install, none of the options were discussed. The defaults are a fairly safe way to test the script. The tool has three main sets of options.
Speaking of options, all the standard ways to run a ULP work; the RUN command, the menu, and the ULP button.
Configuration Level
Our tool gives three levels of configuration. One level only downloads the files you desire. One actually configures EAGLE to have the same look, keyboard shortcuts, etc. as we use here at SparkFun. The final and default option does all of the things.
Figure 3. Configuration level section of tool
Part of the configuration process sets up EAGLE to only use our libraries. With the exception of the user-submitted library, we have tested and actively use the parts in these libraries. This configuration with a limited number of libraries makes EAGLE run faster when searching through parts.
Figure 4. Default SparkFun libraries
The majority of the configuration comes from our eagle.scr. It's this script that sets up the keyboard shortcuts, adjusts layer colors, sets the default grid spacing, etc. Our ULP offers the 'Download only' option for those of you who have personal customizations that you don't want messed with, but want an easy way to get our libraries. This tool is aimed more at the beginner, and the settings should be great for them.
Permanence | Caching
The second major option is the write mode. By default, the files that the ULP downloads will disappear when EAGLE is closed. If the checkbox in the following image is selected, then the files that the tool downloads and creates will remain on your drive. This option is more of a personal preference, and was designed to try to provide flexibility for more advanced users.
Figure 5. Permanence section of tool
Note: This tool will prompt the user before overwriting any files. The names should be unique, but overwrite existing files with caution! As of this writing there is a bug EAGLE that will cause this script to determine that a file already exists even though it doesn't. This false positive is safe and will prompt you, but their engineers are working on fixing it and the bug will eventually go away.
Download Options
By default, our configuration tool will download all of the standard EAGLE files; libraries, design rules, user language programs, scripts, and CAM jobs. It will download these files to their default locations. If the user doesn't want to download our CAM jobs, they can simply uncheck the checkbox in the section they don't want downloaded.
Note: For a complete configuration the user must download at least the libraries. They cannot be set as the default libraries if they don't exist. If you choose a custom download path, you must set this path for the configuration to find and use these libraries each time the script is run.
Figure 6. Download options section of tool
The user is free to change the path where the various file types are downloaded. We have provided the change button as a way to allow the user to configure the directory used. Testing indicated that EAGLE will not allow a script to create new directories without user interaction. The directory selection dialog box is able to create new directories. The button to create a new directory ('New Folder') is located in the lower left corner in the following image.
Figure 7. Directory selection dialog box
Pressing this button will open yet another modal dialog box as pictured in the next image. It's personal preference, but we don't find it a terrible idea to create a new directory in the default location to contain all of the new files. This may be useful in the future if you plan on removing files added by this script. Apologies for not making this the default due to the way EAGLE handles new directory creation. New directories created by the EAGLE GUI are permanent even if you have that option unchecked. We decided against having the script 'manually' delete them for lower risk of deleting something important.
Figure 8. New directory dialog box
The following section of a screenshot shows an example of a custom install path for our EAGLE libraries. The downside to custom install paths is that the script doesn't currently store that information. The user will have to reconfigure the paths each time you run the script. The script uses the currently set paths, so even if the user is only doing the configuration, at least the library and script paths need to match the location where the files live.
Figure 9. Example of edited install path
This ULP can take a long time to run depending on your network connection and other variables. Please check the status in the location shown in figure 10. If there is an error, an error dialog will popup. If the tool windows disappears, it means the tool has finished.
Figure 10. ULP status
Other Info
Auto Update
A second exception to the nonpermanent mode is the script itself. When it runs, the first thing it does is check for an update on GitHub. If an update is found, it will be downloaded and run instead of the version that the user ran.
Going further
That quick introduction to the tool should cover most of the information one needs to get up and running. This ULP is an alternative to the Using the SparkFun Libraries, and Configuring the UI sections of the How to Install and Setup EAGLE tutorial on our site.
As always, our code is open source. We encourage you to take it and play with it. There is a fair amount of error checking, but we know that it's incomplete. We accept pull requests on improvements.
The code between the header and the first function definition is where we've hard coded all of the files this script uses. If you want to repurpose this script, I'd start there. Happy hacking!
The awkward moment when you can write ULPs for EAGLE that are better than EAGLE's actual preference panes.
The "Download the ULP" link is still broken. Is there plans to fix this?
So I'm trying to follow this tutorial but as mentioned below there is an issue with the ULP link. I found the file on GitHub here: https://github.com/sparkfun/SparkFun_Eagle_Settings/tree/master/ulp When I try to use the SparkFunConfig.ulp file I get a syntax error. I am using Eagle 8.3.1. Any suggestions?
I figured it out. Instead of using the right-click and "save link as" method in the file list, I clicked on the file in GitHub and then right-clicked on the Raw button and "save link as". There is most likely a better procedure but it worked for me. It would be nice to fix the link in this article.
The ULP link is broken I believe. Could you fix it please? Thanks!
Hi, I'm getting an error "syntax error" when I drag the sparkfun ulp file onto the schematic or board window. I have the eagle 8.0.2 version running on Win12.
Cheers,
Jacques
FYI: I got errors when I dropped the file onto a library window. It worked ok when I dropped it onto a board window.
Good to know. Which version of EAGLE? What OS are you running?
I'm surprised that with SparkFun's commitment to Open Source that all their boards are Eagle files only. Why not use a platform, like KiCAD, that is as open as the schematics themselves?
That's a tricky one. We are committed to Open Source because we want you the customer to have access to the files and be able to view them. Since Eagle has a free version it fits our needs. While we've periodically looked into different software Eagle seems to fit the needs of our engineers (and our budget) the best without compromising the customers ability to view files. While we are committed to Open Source we also use tools like Windows, MacOS, and Linux in the building because each has its advantages and works well in certain applications. Personally I see Open Source as a tool, or an means to an end, with the end being transparency to the user. But I don't see Open Source as an end in and of itself.
While I understand the draw of Eagle, I feel like if more big companies had hands in the development of free alternates, such as KiCAD, that the software would mature much quicker and thereby gain bigger 'fan base', and in turn allow for more and better development. It would lower the entry cost of designing and producing circuit boards. Its very much the cycle that open OSs such as Ubuntu have seen, and look at their growth.
I'm not saying you should switch, as your goal isn't really "open source as an end in and of itself". You know your process better than anyone on these comments, so I'm just providing one argument in favor of at least doing some development with an open platform like KiCAD.
Thanks for the kind and insightful response!
Eagle files are open, you can even change it with notepad. what difference it would make whether the software open-source or not?
I think the reason is Eagle is more common, it is being around for 28 years. Also Eagle design files are available from major manufacturers, ie: Atmel, TI. I download their experiment board designs to check schematics and use the parts in my own design. So I dont have to create my own library. I never see a design package for KiCAD.
My understanding of Open Source, and correct me if I'm wrong, is that if you take what has been built, designed, or written before you, you are legally obligated to tell people where you got the base design/code/board and make whatever you are making open source as well. By doing so, you have a sort of collaboration that closed source hardware/software/projects don't have.
Now, if you use Eagle (which is a great piece of software) and do as SparkFun has, making lots of open source things, that is great. However, due to the limitations of Eagle, the ideas they have, the projects the start, are limited.
Take for instance their basic signal generator. I saw this and immediately got out some paper and pencils and designed a unit that takes this basic concept and makes in a more robust and fully functional signal generator and data logger (which incidentally also is a product at SparkFun).
I ran into a big issue however when the board eclipsed the maximum size of the free version of Eagle. Not only that, but I soon realized that I could never legally sell any boards I designed with Eagle. So, I was stuck. Do this bit of engineering on my own, and for myself only in Eagle, or start porting this stuff to KiCAD (or some other open product).
That is a project I've put aside for the time being because I don't want to redo the work that has already been done.
That is commonly the case for Open Source but not a requirement, in fact that really just depends on the copyright license that is chosen. We put our stuff under a Creative Commons license that does require that, but there are plenty of other options that are either more or less restrictive. Open Source really just means that the source is available. Placing a pdf of the schematic and board files would be considered open source as well, but if you wanted to build your own you would have to grab a design program and lay it out yourself. Open Source isn't about making it as easy and cheap as possible for people to take and sell your designs, it is about giving the user information. While we encourage people to take our designs and use them, and even resell them, we are more interested in making sure the customer who buys the board can easily view the schematic and if need be the board layout to understand how the board works.
The problem I see using the directory commands the way you do, is everytime there's an Eagle update, you will need to move your scripts, libraries, and ulp files from eagle-7.5.0 to eagle-7.something_new. Why not specify something outside the application path that won't change with every Eagle update?
The user is free to choose any directory they want by clicking the change buttons. I tried using a more customized path. If EAGLE supports creating intermediate directories as required, it doesn't doesn't make it easy. I could get the OS_SIGNATURE, parse it, and then uses the commands and existing paths for that OS to make specific system calls to create the necessary directories. I decided not to do all of that work to make that preference decision for the user. Leaving the files in the old version might be helpful and currently only takes up about 1/2 MB. If you want to change the defaults edit lines 25 through 29 of the ULP. If you customize the ULP, you might want to comment out line 616 to prevent updates from overwriting your changes. A feature to fix that could be implemented in the future.