Horizon EDA Version 1.0!

[tooki]

User experience,interface as well as compatibility (Mac, Windows and Linux) is key, the rest will come later (unless you heavily fail on it)

As written before, I don't have the time and hardware to bother with Mac os.

To be honest though, that’s a dumb decision — a good app that runs on the #1, #2, and #3 desktop OSes is a lot more valuable than one that runs on #1 and #3. Even more so as the Mac platform has continued to gain ground outside of its classic stronghold of media production. (Almost 10 years ago, I worked at a software company that made a Windows program for research and academia, and we got daily inquiries into a Mac version. For many customers, especially large ones seeking site licenses, the lack of a Mac version removed our product from consideration entirely, as all our major competitors supported both. Linux inquiries were but a tiny fraction as many as Mac.)

[Lukas]

User experience,interface as well as compatibility (Mac, Windows and Linux) is key, the rest will come later (unless you heavily fail on it)

As written before, I don't have the time and hardware to bother with Mac os.

To be honest though, that’s a dumb decision — a good app that runs on the #1, #2, and #3 desktop OSes is a lot more valuable than one that runs on #1 and #3. Even more so as the Mac platform has continued to gain ground outside of its classic stronghold of media production. (Almost 10 years ago, I worked at a software company that made a Windows program for research and academia, and we got daily inquiries into a Mac version. For many customers, especially large ones seeking site licenses, the lack of a Mac version removed our product from consideration entirely, as all our major competitors supported both. Linux inquiries were but a tiny fraction as many as Mac.)

To clarify things a bit more about mac OS: People tried getting it to work on mac OS, but hit a roadblock when it came to OpenGL: https://github.com/horizon-eda/horizon/issues/271 Fixing this would probably require in-depth knowledge about Gtk's Quartz backend and of course a mac computer at my disposal, neither of which I have. It's not that I'm actively working against mac OS support, it's just something that isn't within my technical abilities without investing a significant amount of time.

[Oleander]

Is there a way to hide the left toolbox in a board/schematic editor ? It takes a lot of useful editor area. 

[Lukas]

Is there a way to hide the left toolbox in a board/schematic editor ? It takes a lot of useful editor area.

There's the "distraction free mode" that hides the left and right sidebars: https://blog.horizon-eda.org/progress/2020/07/05/progress-2020-06.html#distraction-free-mode-pr-413

[Oleander]

Is there a way to use mils (1/1000 of the inch) as a main distance unit  ?
When I enter 'mi' or 'mil' - it is converted to millimeters.

[Lukas]

Is there a way to use mils (1/1000 of the inch) as a main distance unit  ?
When I enter 'mi' or 'mil' - it is converted to millimeters.

I've been waiting for this question since the very first release. Apart from me not liking imperial units, I see another real problem, namely accumulating rounding errors. The internal representation of lengths is nanometers. A length of 1mm will be displayed as 39.37mil, which after editing will become 0.999998mm. While the error might no be an issue, I don't have a good feeling about it.


Apart from that, version 1.3.0 just got released: https://github.com/horizon-eda/horizon/releases/tag/v1.3.0

[Lukas]

Version 1.4.0 just got released: https://github.com/horizon-eda/horizon/releases/tag/v1.4.0

Apart from the usual set of new feature this release includes two important bugfixes for windows users:

• No more laggy rendering on Intel GPUs, this fixes number 8 in https://www.eevblog.com/forum/eda/horizon-eda-version-1-0!/msg3107642/#msg3107642
• 3D preview doesn’t crash randomly with “gl error 1285”

[djac]

Hello Lukas,

Today I was once again looking for a replacement for KICAD and came across your Horizon and read through the documentation. And here your idea that library management is the crucial pivotal point in an EDA program immediately caught my eye. This is the main reason why I am looking for an alternative to KICAD, because it is extremely complicated and not intuitively solved. Most of the work in creating schematics is spent on creating or searching for symbols or footprints, the rest is rather the smaller part.

In particular, the idea of creating a central repository on Github is really good. Anyone can simply put a tested "part" there and it is then available to the general public. Once there is a community of users who use the program, they will embrace the idea enthusiastically and the collection will swell rapidly because everyone has the problem that it takes up far too much time.

I then installed the programme to try it out. The first impression is good. Nice logical presentation, the programme reacts quickly, etc.

But now comes the big "but".

The documentation is completely inadequate. First of all, you explain some basic ideas much too abstractly. I can't do anything with the Powernet thing, for example. What is that supposed to be good for? Well, the program grumbles when I want to connect two netlists just like that. But what practical relevance does this have, what advantages can I derive from it? To which connections does the power net refer, only to ground or also to +Vcc and -Vss or is it generally good for splitting into subnets. I don't want to waste my time with the question: what did the artist mean by that? This is always best done with the help of examples.

The lack of concrete examples is consistent throughout the manual. An example of this is the chapter on creating "parts". Instead of just general explanations, an additional concrete example would be very helpful. How do I create, say, a quadruple OpAmp. With screenshots and explanations such as what changes when gate and unit are trivial, as with a resistor. I tried to create a part LTC2057, but couldn't figure out what to do in which order. If something is not intuitive, it must be in the manual!

But there also seem to be logical breaks in your library concept. Let's take the simple components like resistors etc. You seem to have the idea that the definition of a resistor includes parts, manufacturer, ohmic value, maximum power and footprint. This completely misses the point in practice. Just think how many parts come together if you iterate over all manufacturers, values according to E192 etc.. The disk space on GitHub may quickly reach its limits.

The concept does not fit. For an EDA, the value of a resistor and the manufacturer are completely irrelevant, but not the symbol and the footprint. The former are purely declarative attributes that have no place in a library. There, the connection resistor-symbol-footprint is sufficient. The latter are project-specific and have to be added on the fly in the schematic editor or wherever else it makes sense. And for this you can provide a few attributes that are generally valid for all components, e.g. manufacturer, series, order number, component designation (e.g. R14, not editable), value, power, comment (free text), all of which are sensibly preassigned with "" or "unknown" and which have a specific meaning in the schematic editor, component printout and component list. For this, these attributes must then be stored in files in the project directory and not in the pool.

In any case, no one will use a program that first has to create a complete part for a simple resistor or pick it out of millions of entries. The rest may be as good as it wants, but that is a knockout criterion.

Your program seems to have really good facilities and ideas, but if you also want to succeed, you would have to change your priorities:

1. a most carefully prepared documentation. I know this is the unloved child of every programmer (I've been programming all my professional life, so I know what I'm talking about). But without it, you won't get a community around this program.

2. look at your program from the point of view of a user who doesn't care about the internals and beauties of your code, and whose only goal is to get a finished board with the help of a very user-friendly program, and with as little time and mouse clicks as possible. This can be achieved by using the program intensively as a user.

3. You can implement all extensions and refinements later, but first it is important to create a solid basis all around.

As it is now, I won't want to use it, but I would be really happy if you could bring the thing to a successful end.

Best regards
Dieter

[nctnico]

But there also seem to be logical breaks in your library concept. Let's take the simple components like resistors etc. You seem to have the idea that the definition of a resistor includes parts, manufacturer, ohmic value, maximum power and footprint. This completely misses the point in practice.

On the contrary! If you look at how part libraries are being build & used at larger companies you'll see that all these properties are included. Otherwise you need to do manual work when creating the BOM. When creating a schematic you are not picking a symbol + footprint but a part that exists in the real world and therefore it needs the parameters that tie it to the real world. All the big EDA packages work this way because it is the only way to keep a handle on the logistics of getting a board produced. So yes, creating a part with all the parameters before drawing a schematic IS the right workflow.

[Pitrsek]

+1 for what nctnico said. Library is handled in correct way with HorizonEDA. Actually it is one of the greatest strength of the tool.

[PlainName]

So yes, creating a part with all the parameters before drawing a schematic IS the right workflow.

Shouldn't that be qualified with "when being used at larger companies"?

[nctnico]

So yes, creating a part with all the parameters before drawing a schematic IS the right workflow.

Shouldn't that be qualified with "when being used at larger companies"?

No. For over 20 years already I have used this workflow at all companies I worked in (big & small) and am still using it even though I'm a one-man-band. It helps a lot at the logistics end. You create a component once and then re-use, re-use and re-use. Especially for parts like resistors which are used a lot it is extremely convenient not having to question what type to order. When I create a BOM it comes complete with order numbers for Farnell & RS so I can copy & paste the items I don't have in stock straight into the website. Filling the database with common parts like resistors and capacitors to get started is tedious day's work but from then on you start raking in the rewards.

[djac]

@nctnico

However, this approach is extremely impractical for the following reasons:

A project is first in the development phase and it is about the creation of prototypes, and this also several times.

Initially, it is only a matter of technical decisions. Let's take a 1K resistor as an example. The technical decision also includes the design, let's say smd 603, which also affects the design of the PCB. I want to find such an initially incomplete element, i.e. R,603, in the library.

Only those attributes are preassigned that are necessary for the immediate PCB creation. Of course, there are other technical decisions to be made, such as resistance value, possibly also tolerance, power or temperature coefficient. However, these attributes have no relevance for the PCB creation.

I would like to be able to add all these attributes, if they are needed at all. The technically relevant data will probably be added in the schematic editor, but manufacturers etc. are usually irrelevant in the development phase. This topic will therefore only be addressed when the development is completed and the actual production begins. What is needed here is an editor for the bom list, with the help of which the missing attributes can be added, but do not have to be.  The manufacturer, for example, does not matter for most resistors, which one is selected is more a question of the achievable purchase prices and no longer concerns the development department, which thus leaves this attribute unoccupied and thus leaves the decision to the purchasing department.

In any case, these additional attributes have no relevance to the task that an EDA tool has to cope with and thus do not belong in the library. This data is project-specific and will change again and again in the course of the product's life without affecting the PCB itself. It is therefore crucial to simply add these attributes, e.g. by double-clicking on a symbol in the schematic editor, which opens a window for this purpose.

Of course, this does not exclude the procedure of defining everything in advance in the library, because these descriptive attributes may well exist in the library. Those who like it should do it and dig through hundreds of thousands of resistor entries until they find what they want.

The decisive factor, however, is the possibility of simple updating in the schematic editor, etc. (without changing the library by default). Only in this way can the tool adapt to the different work processes in the different organisations and not vice versa. An engineering office that only builds prototypes has different needs than a company that serves the mass market with finished products.

Your concept may correspond to your preferences, but it is too rigid and does not fit in with the processes in other organisations or with the preferences of other people.

[nctnico]

In most practical situations parts like resistors and capacitors don't have manufacturers and part numbers specified in the parts database. Just a minimal specification like the value and tolerance. For capacitors only voltage and dielectricum. This is perfectly reasonable for an assembler to deal with and there is no need to be super rigid about it.

However if you need to be more specific then an additional part should be created in the database. For example a resistor with a tolerance of 0.01% with a specific aging coefficient. If you leave that to the schematic only it will be very prone to errors. One of the features in Orcad (for example) is to check the parts against the database. This is an extremely useful tool to make sure that your BOM will be complete. Another feature of Orcad is to go through the BOM and look for a specific part value. If it turns out you have 50 times 100nf 0402 10V and 10 times 100nf 16V then you can quickly turn all these into 100nf 16V by linking them to a different part in the database. All the fields will be updated automatically. Actually: the only information that is relevant for the schematic are references to the database. The data in the schematic is just a copy of that.

[djac]

Then we are actually in agreement with regard to the requirements of an eda tool.

The descriptive attributes are available in the database, but the necessary entries are only R and footprint in the case of a resistance.

I can't say whether this works in Horizon, because I didn't get that far due to the incomplete documentation. But what I can't do is open a window in the schematic editor to change or add project-specific values. I don't want to have to switch between schematic and part editor every time just to enter the resistance value. That is much too inconvenient. In the schematic editor, a window opens after double-clicking on a symbol, but the resistance value is only displayed and cannot be changed.

[nctnico]

Then we are actually in agreement with regard to the requirements of an eda tool.

The descriptive attributes are available in the database, but the necessary entries are only R and footprint in the case of a resistance.

No, it is better to take it one step further.

I can't say whether this works in Horizon, because I didn't get that far due to the incomplete documentation. But what I can't do is open a window in the schematic editor to change or add project-specific values. I don't want to have to switch between schematic and part editor every time just to enter the resistance value. That is much too inconvenient. In the schematic editor, a window opens after double-clicking on a symbol, but the resistance value is only displayed and cannot be changed.

Yes, and that is inline with how it should work. You have to define all resistor values in the database before you are able to use them. Just putting values into a schematic is not an organised way of working (good for DaveCAD^tm but an EDA tool is usually used to create a board). It will lead to errors due to inconsistencies. At some point you'll have a board made and at that point all parts will need some minimum specification for the purchasing department (even if that is yourself) to deal with the part. In case of a resistor it is handy to have a value, case size and tolerance for example.

[Lukas]

can't do anything with the Powernet thing, for example. What is that supposed to be good for?

To get the usual power/gnd symbols. That's about it.

Well, the program grumbles when I want to connect two netlists just like that.

That's actually documented: https://horizon-eda.readthedocs.io/en/latest/imp-sch.html#nets-and-net-segments

The lack of concrete examples is consistent throughout the manual. An example of this is the chapter on creating "parts". Instead of just general explanations, an additional concrete example would be very helpful. How do I create, say, a quadruple OpAmp.

I agree that the documentation still has quite some scope for improvement, nevertheless people figured it out: https://github.com/horizon-eda/horizon-pool/pulls

The concept does not fit. For an EDA, the value of a resistor and the manufacturer are completely irrelevant

As other people already mentioned, this is by design, inspired by how it's done in the enterprise world. The schematic/netlist is the single source of truth for the BOM. You can't tell someone else like your assembly house or purchasing department to get you a 1k 0603 resistor. You better tell them to get a panasonic ERJ-3EKF1001 and you get exactly what you want.

In any case, no one will use a program that first has to create a complete part for a simple resistor or pick it out of millions of entries

That's what the parametric search is for. That way you know, that the resistor you're thinking of is actually something that you can get. The partinfo integration even tells you the stock of your favourite distributor.

2. look at your program from the point of view of a user who doesn't care about the internals and beauties of your code, and whose only goal is to get a finished board with the help of a very user-friendly program, and with as little time and mouse clicks as possible. This can be achieved by using the program intensively as a user.

This is exactly why I started the project. I wasn't happy with what the then-present open source PCB design tools, so I made my own. The nice thing about being user and developer in one person is that things can be exactly the way I want them to be, only limited by time and imagination.

I don't want to have to switch between schematic and part editor every time just to enter the resistance value.

You don't. You go the part browser and pick another one with the desired value.

All in all, my goal isn't to make Horizon EDA appeal to the widest audience possible. I'm quite happy with how things are progressing community-wise on github, IRC and other places.

[tycz]

The concept does not fit. For an EDA, the value of a resistor and the manufacturer are completely irrelevant

As other people already mentioned, this is by design, inspired by how it's done in the enterprise world. The schematic/netlist is the single source of truth for the BOM. You can't tell someone else like your assembly house or purchasing department to get you a 1k 0603 resistor. You better tell them to get a panasonic ERJ-3EKF1001 and you get exactly what you want.

There's nothing wrong with specifying a component as 'resistor 1k 0603'. I do this routinely. The looser the spec, the easier it is for the broker/factory to by parts that fit the requirement, the cheaper the parts will be. Try it sometime.

I don't want to have to switch between schematic and part editor every time just to enter the resistance value.

You don't. You go the part browser and pick another one with the desired value.

This workflow absolutely sucks for entering analog circuitry. Normally when I design something analog I place my components first and wire them up. Only once I can see the topology do I start assigning values. It seems like a great additional effort required to create the circuit mentally and calculate the values before even seeing the the thing on the page!

It's can also be useful to be able to create a circuit without values if under time pressure, like the board layout must be ready by the end of the day to meet a deadline.

But there also seem to be logical breaks in your library concept. Let's take the simple components like resistors etc. You seem to have the idea that the definition of a resistor includes parts, manufacturer, ohmic value, maximum power and footprint. This completely misses the point in practice.

On the contrary! If you look at how part libraries are being build & used at larger companies you'll see that all these properties are included. Otherwise you need to do manual work when creating the BOM. When creating a schematic you are not picking a symbol + footprint but a part that exists in the real world and therefore it needs the parameters that tie it to the real world. All the big EDA packages work this way because it is the only way to keep a handle on the logistics of getting a board produced. So yes, creating a part with all the parameters before drawing a schematic IS the right workflow.

As far as I can tell, Horizon is unique in it's total inability to edit component values. Altium, for example, will happily let you change values on the fly if you wish to do so. Other packages may have this mode as an option, but it's not normally forced like this. I find that for some components it's really useful to have all the parameters welded together such as connectors and potentiometers. For other components such as resistors and caps, it's a horrible inconvenience.

[djac]

@nctnico

"You have to define all resistor values in the database before you are able to use them."

As I said, the structure of the library should be flexible enough to allow such a way of working. But you and your approach are not the navel of the world, there are well-founded other work processes and a tool should be able to map them as well. A good tool should be so flexible that it can be used under the most diverse work and organisational processes. It is not its task to impose a certain approach on the user.

@ Lukas

"the documentation still has quite some scope for improvement"

I think that is a big understatement. I have rarely seen such superficial and incomplete documentation.

"That's what the parametric search is for."

To place a simple field, forest, meadow resistor takes far too long. I mostly prototype, and 90% of the simple components come from stock, only special types have to be ordered for a project. But your tool would force me to enter all the types with all their attributes into the database first. All too complicated and time-consuming for my needs.

"As other people already mentioned, this is by design, inspired by how it's done in the enterprise world."

Well, if you think that inflexibility is a sign of quality, so be it. Then I'll just have to stay with KICAD or keep looking.

[Pitrsek]

A good tool should be so flexible that it can be used under the most diverse work and organisational processes. It is not its task to impose a certain approach on the user.

Sorry but this is not true, each and every tool imposes a certain philosophy and workflow. Good luck going against the grain of the tool... If the tool would cater to every possible workflow, it would be unusable mess. Ask 5 engineers and you'll get 6 opinions...
Honestly I do not see what is the fuss about. You are free to define as much or as little parameters as in library as you see fit, you just have to define them before you work(which will actually save you time in the end). There are scripts that come with Horizon that allow you to batch create family - you can create "Generic" Manufacturer with only resistance value mapped, or resistance and package, oh maybe tolerance is important to you as well... you can decide how far you want to take it. From 1k only to ERJ-3EKF1001, your choice.  You can create part with TBD value as well.

Well, if you think that inflexibility is a sign of quality, so be it.

Sorry I can't disagree more. Horizon lets me structure the library whenever way I feel like with component cases and custom parameters, all searchable. + ability to reuse symbols. I think we could discuss other aspects of the tool as how it stands compared to KiCad, but for library comparison, there is no comparison.

[nctnico]

Well, if you think that inflexibility is a sign of quality, so be it. Then I'll just have to stay with KICAD or keep looking.

BTW: A library system similar to what is already in Horizon will be added to KiCAD in an upcoming release due to demand from professional / corporate CAD users.

[nctnico]

But there also seem to be logical breaks in your library concept. Let's take the simple components like resistors etc. You seem to have the idea that the definition of a resistor includes parts, manufacturer, ohmic value, maximum power and footprint. This completely misses the point in practice.

On the contrary! If you look at how part libraries are being build & used at larger companies you'll see that all these properties are included. Otherwise you need to do manual work when creating the BOM. When creating a schematic you are not picking a symbol + footprint but a part that exists in the real world and therefore it needs the parameters that tie it to the real world. All the big EDA packages work this way because it is the only way to keep a handle on the logistics of getting a board produced. So yes, creating a part with all the parameters before drawing a schematic IS the right workflow.

As far as I can tell, Horizon is unique in it's total inability to edit component values. Altium, for example, will happily let you change values on the fly if you wish to do so. Other packages may have this mode as an option, but it's not normally forced like this. I find that for some components it's really useful to have all the parameters welded together such as connectors and potentiometers. For other components such as resistors and caps, it's a horrible inconvenience.

You can start out with 'bogus' values and fill in the details later. For clarity you could even define components with 'bogus' as the value. It is a clear indication the schematic isn't ready to produce a bill of materials. Changing values 'randomly' without it being clear that the design isn't finished is horrible. Especially when working on a design with multiple people. In the end an extra round of checks is needed to verify all parts match the database. And if not, what part is actually needed? By that time the person who designed the circuit has moved on to the next task / problem and the work that person did to determine which component needs to be used has to be done again. Been there, done that. I agree that a more structured /rigid approach to creating schematics takes some getting used to but in the end it pays off in terms of efficiency and reduction of errors. Personally I never ever change the value of a part; I always choose a different part from the database and if the value doesn't exist I create a new part in the database. It needs to happen anyway and I can totally forget about the details of the part once it is in the schematic. A correct footprint, BOM entry and board as it is designed (I'm avoiding the word correct here) are guaranteed. No unpleasant surprises due to parts with wrong values, wrong order codes or footprints not matching.

I've been part of a project where the designer of a fairly complex board spend two weeks on figuring out a problem (too much leakage current somewhere) and in the end resorted to measure every resistor. It turned out to be an error in the (manually created) BOM. Those kind of errors don't happen to me.

[djac]

Dear nctnico, no one wants to take away your way of working and your belief that this is the only way to minimise mistakes. You should still be allowed to define all components in the database down to the last dot before you touch the schematics. I don't even want to deny that this can be a thoroughly appropriate way of working, e.g. in teamwork.

However, in other contexts this is too cumbersome and costs too much time. The point here is to provide more flexibility in the interface. The parteditor seems to be able to cope with the minimal definition of manufacturer,R,footprint, resistance value. I have tried this and it works, but I have not been able to find this minimum value in the database because the naming in the database is not clear to me thanks to the poor documentation. Theoretically, you can also omit the resistance value, but you cannot enter it in the schematic. Instead, you have to switch to the part editor, search for the base element, duplicate it, enter the resistance value, save it, switch to the schematic, open the part list there, search for the newly created component and finally place it. It couldn't be more complicated. Nobody does this and the only feasible way is to create all the components before starting the schematic.

That's what I mean by inflexible.

Instead, I would like a minimum (R,footprint) and maximum definition (+ all descriptive attributes that are not necessary for PCB creation) to be possible in the part editor - as is already the case now), but additionally the possibility of adding these descriptive attributes (and only these) in both the schematic and PCB editor. This could be realised, for example, in such a way that a double-click on the component opens a window in which these attributes can be added or changed.Then there should be the option to save these entries only project-specifically in order not to unnecessarily inflate the database, or to also change these values in the database. In the latter case, you need the option of whether the database element is only updated or duplicated under a new name.

These changes would probably be relatively easy to insert into the existing code base. Then, nctnico, we would both be satisfied. Isn't that better than just you being satisfied?

[nctnico]

These changes would probably be relatively easy to insert into the existing code base. Then, nctnico, we would both be satisfied. Isn't that better than just you being satisfied?

You really have no idea about how electronics are designed by professionals  In bigger companies they even have people dedicated to fill the part database. Just changing a value isn't allowed (do that and you might even get fired); you have to put in a request to add a component to the database and wait until it has been added before continueing with the design. It really isn't me pushing this workflow; I'm trying to show you the reasons why the workflow is used c.q. why it exists. Many people have thought long and hard about it. Unlike software an agile workflow doesn't really work for hardware because the turnaround times for having boards routed and produced is so long. First time right gets a product out of the door quicker.

Last year a supplier of one of my customers had to redo a batch of expensive boards because a new employee (fresh from school) changed the values in Altium instead of using the company's component database. His supervisors didn't caught it as well. In Horizon EDA he would not have been able to make this mistake (costing the company more than an Altium license).

[PlainName]

In bigger companies they even have people dedicated to fill the part database.

<Looks around the office... hmm, just the cat>

I guess my gaff isn't big enough for this product, then.