This can easily be done with a custom footprint
1 Like
Itās unlikely they will completely remove targets. They are rendered now, because ātheyā want to maintain backward compatibility with old projects. This is an important point for KiCad, and not likely to change.
Indeed. I also have not seen any example here of something that can not be done just as well or better with a (custom) footprint. Apparently Dennis_Heidner is not interested in this, and Iām getting annoyed by the constant bumps in this thread, so I will set it to āMutedā to fix that for myself (this has no consequence for anyone else).
There should not be a need for KiCAD users to create custom foot prints for a simple target.
Instead of promoting better & common ways for PCB layouts - that custom foot prints of common objects promotes diverting paths.
You havenāt paid attention to all posts. You can change the layer in the Properties manager.
Also, have you actually tried all other suggestions? Have you tried the ācenter dimensionā? If you want a crosshair look, you can group it with a circle.
Iāve got a feeling that you are somehow fixated to this one KiCad object. You have several options to help with your workflow, but have you tested them with open mind? You just add post after post telling why target is good (although most of us donāt seem to have even noticed the lack of it) and footprint or something else has this or that wrong, and I donāt even understand what you mean by ābetter & common waysā or ādiverting pathsā. I canāt help getting an impression that you are making excuses. You would be more convincing if you would show that you have actually tested all the alternatives thoughtfully and thoroughly and show where exactly they are deficient. To me it looks like you have skillfully dodged the answers to your complaints.
As for the fear of ending support for targets totally in KiCad ā Iām not a KiCad developer, but I have followed the development several years closely and read some of the source code. I agree with Paul: removing the support is very unlikely.
First, it wonāt happen by accident, nobody will change the code that way. I say this because I have read a part of that code which handles targets. I have worked as a software developer and have been involved in other Open Source projects, and I have seen and can understand that sometimes an implicit undocumented feature can be removed by accident. But support for targets in KiCad is explicit, it canāt be deleted accidentally.
Second: actually I would say that purposefully removing the support would mean more work than just keeping it. Itās mostly maintenance free (an actual KiCad developer can correct me if Iām wrong), and removing it would require going through the code, testing etc.
Third: Paul, again, said this already: for the developers keeping old designs lossless in new versions is important. Removing targets would mean needing to convert them to something else, which would need more work than just keeping it.
So, I donāt see how it would be removed from KiCad.
Targets canāt be added to a design through the normal GUI, but as we have seen, it can be added by copying and pasting (in the GUI from another design, or in text format). And they can be modified with the Properties panel. If you need something else, please read the thread again and try the alternatives for real without prejudice.
Targets canāt be added to a design through the normal GUI, but as we have seen, it can be added by copying and pasting (in the GUI from another design, or in text format). And they can be modified with the Properties panel. If you need something else, please read the thread again and try the alternatives for real without prejudice.
Since copy paste can be triggered through python scripting nothing really stops a add-on author of adding a icon to add the function to the GUI if its a usability issue.
We removed targets on purpose. We will eventually replace them with custom footprints on board open. This will happen once maintaining the specialized code handling them becomes more problematic than writing a simple routine to replace them. This will happen eventually. I would strongly encourage you to build an alternate workflow for your process.
Discussion of this was at Wishlist (if possible for 6.0): Move "Add a Layer alignement target" cross from Edge.Cuts to F.Fab because it screws up every PCB (#10006) Ā· Issues Ā· KiCad / KiCad Source Code / kicad Ā· GitLab
tldr; Layer alignment targets are not commonly supported by other software packages and this uniqueness tends to cause problems for fabs.
I appreciate the link. But Iāve got 30+ boards that have used targets, not to place a fiducial on all layers, but to place a target for mechanical alignment.
Itās similar to same technique I used in the 70ās. Even for single layer boards. Two board layers, One for copper backside, the second for the mechanical alignments.
Yes, there were targets on both mylar layers so I could pin them together - but they were targets outside what would be the edge cut nowdays. Targets inside the working area - were on a top layer and only used to create measurement reference points.
The problem with targets creating problems for pcb users, the zone problems, works fine in KiCAD 8.x so long as the layer is edited away from edge-cut, margin,
Iāve tried and confirmed it works fine. Really the only thing that needed to be done was allow a target to be placed on one of the other single layers. If KiCAD user still had wanted target on all layers, a click for ALL layers.
Leaving the object in future versions and just changing the UI when the object is right clicked leaves in the backward compatibility. And it makes it possible to use targets as dimensional measurement points.
Changing the default layer away from edge-cut, to one of the Drawing user layers, would solve the PCB fab company problems - few in any use those drawing layers.
Iāve also added graphics (logos as a foot print on the schematic). Mostly Iāve decided to use the top sheet as a place for logos, mounting holes, and errata text as I discover things that need to be changed in a future board revision.