I looked in the docs but didn’t see this.
Is there a way to do Eagle / KiCad style net names? See the image.
I looked in the docs but didn’t see this.
Is there a way to do Eagle / KiCad style net names? See the image.
Hi,
This does not exist in LibrePCB. To be honest, IMO it is confusing and thus not necessary to have two different styles of netlabels when they actually do the same thing. Or what would be the advantage of the Eagle style labels?
Generally I just recommend to place the labels above the lines, not next to them:
(and theoretically it is even possible to draw your own style of netlabels, but this has several disadvantages so I don’t recommend that…)
Thanks for the response Urban! (this is Parker!). We use it to help differentiate between notes about the signal verse actual net names. Usually to indicate that the signal / net goes to another page of the schematic or somewhere else.
Which does bring up a good use case for such labeling that Eagle or KiCad don’t do. Having a way to show what other pages of the schematic the signal is on. Automotive diagrams do this but I haven’t seen an EDA tool do this by default.
Side note: The Eagle library importer is amazing!
Ah, hi Parker, nice to see you here!
Hmm alright, so if I understand correctly, you don’t necessarily put the actual net name into this label? In that case theoretically you could create a custom library element for that, though it would not adjust dynamically to the text length and is not so convenient to use. I’m really not sure if it makes sense to make this a built-in feature, maybe it is more a thing of personal habits
That’s indeed something interesting. I already got this question from people in the machine industry because the tools for drawing wiring diagrams for control cabinets also generate these cross-references. I didn’t know this is also done in the automotive sector. Maybe this would be worth implementing.
Thanks, glad you like it
We do put the net list label in the tag/label. Its a way to tell the difference to a net note (which is just floating text next to a net) verse the actual net name.
I can work around it if required. Is there a attribute for a component that can auto be populated depending on the net the pin is attached to? Similar to your first idea of a library element.
Going back and manually adding them wouldn’t be the end of the world either
Side Note: The “x” part of the current net text does look like its disconnected and not really part of another section of the schematic. Maybe that is why its bugging me.
There are two mechanisms which could be useful here. The first one is that pin labels can be configured to display the name of the connected net instead of the component signal name. The corresponding dialog is in the component editor:
However, note that this will only display the name of the connected net, but it does not allow you to rename the net through this label.
Another way is the supply symbols approach. You might take a look at the “Supply VCC” component in the base library:
This basically works the other way around. You set a net name as the VALUE of a component. This value then gets displayed on the schematic because of the {{VALUE}}
text. In addition, the “forced net” config will propagate this name to the net connected to it. So the net name is enforced by the component, not by the net (though currently renaming works only in disconnected state, this will be fixed some day).
I think both ways are not ideal for your use-case but you might still want to try it. Also keep in mind that both ways will suppress the “less than two pins in net” ERC warning as the label’s pin is considered as a real component pin.
Thanks! This helps me out a bunch and gets me to what we need.
This is a bit off topic for this thread but is there a time line for a feature like the Eagle “paintroller” tool? Basically allows you to copy only specific attributes and then pastes them on other elements?
It’s already implemented for the footprint editor, but not released yet. For the other editors there’s no time line yet (feel free to open an issue on GitHub to make us keeping it in mind).
They will appear automatically once you place this component on the board. Without placing it, the schematic editor doesn’t know yet what footprint is chosen (due to an underlying concept different to Eagle).
Got it! Just started layout on this project.
In the Layout Editor, is there a miter tool or is only while drawing the traces?
Yeah the board editor is generally quite simple so far, not many convenience tools available. But such things will be added step by step
I figured as much.
Definitely see the potential. Will be finishing up this PCB design this week. I am impressed by the stability of the software. Zero problems I have run across which is a far cry from Eagle and KiCad… and Altium
Glad to hear that you are getting on
Just one thing irritates me a bit: What are J3 and J4 exactly? They look like THT pads but with a very weird shape. Rectangular holes cannot be manufactured. Are there any intersections of custom pad outlines? Didn’t the package editor show any warnings about these pads?
Yes it is throwing an error for that part.
The part is a large threaded boss for attaching high current cable lugs to. Part number: B4A-PCB-RLM. IHI - THT - B4A-PCB-RLM-KIT Ring Lug Mount Block
Datasheet for the mechanical footprint. https://lugsdirect.com/PDF_Webprint/B4A-PCB(-45)-CUTOUT-LAYOUT-FOOTPRINT.pdf
Here is the library i have been building up if you want to take a look:
https://github.com/LonghornEngineer/LHE-LibrePCB-Part
Is there a better way to design this in Libre? I am really excited that the pad editor supports plated slots from the get go, no silly workarounds!
Alright, I think you misread the drawing in the datasheet (it took me a while too!) The pad outline should be larger than the slot:
And I recommend to always read the messages in the library editor The “hole outside copper of pad” error states exactly what is wrong with that pad.
I must have missed that! Yeah looks like I took the soldermask opening as the copper pad! Thanks for catching that.
TBH I thought the route just extended past the pad.