Can not start routing from a graphic

Hello guys, I created a footprint for an inductor that is made on the PCB, in practice a track designed as a spiral connecting 2 pads. So in the footprint editor I realize the spiral on the F.Cu layer using Draw Arc 16 times for a 360 degrees round (I used a Python script to generate the track). The track is done only on the F.Cu layer but the 2 pads are on both sides of course. In PCB Editor if I try to connect a track to the pads on the B.Cu layer works without any problem, instead I am not able to do the same on the F.Cu layer, in this case I have the “can not start routing from a graphic”. I suppose something wrong on the footprint because was done by Python script so I did a O ohm shunt resistor made by hands with 2 pads and a stright line connecting them on the F.Cu layer but the behaviour is the same. What may I do to solve the problem?

In Kicad 5.0 it worked.

Reminded me of a similar post recently:

Maybe it’s a similar problem?

May be but I feel the problem is not on the pad but in any other “graphic” element “connected” or near the pad at footprint level as well. I think it may be a bug. At the moment I placed a via or I route the tracks on the B.Cu layer but I need also to design a PCB coil with tracks in both sides and in this case I think I will not able to find a workaround so I tested the situation on Kicad 5 and it works so may be a bug introduced somewhere in Kicad 6 (I am using Kicad 6.0.8).

In the post I linked to it wasn’t the pad but a nearby edge cut causing the bug. Rather rare situation. If yours is similar you could vote for the bug report.

… which is not necessarily a good thing.

As KiCad is becoming more “professional”, checking for errors is also improving, and KiCad treats tracks and pads differently from graphic items, even if they’re drawn on a copper layer, they are still graphic items.

To fix it you have to make the graphics an inherent part of the pad you want it to connect to. You can do that by first selecting a pad, then a right-click and select Edit Pad asGraphics Shapes [Ctrl + E] from the popup menu. If you do this, then the graphics become a part of the pad, and KiCad will also respect clearances during DRC checks.

As you’re doing it with python, First experiment on a dummy footprint and examine the results in a text editor, then modify your script to do something similar.

There is another gotcha.
It looks like you’re designing a PCB inductor. If the graphics connects different pads together, it will be flagged by DRC as a short. (Because KiCad now recognises the graphics as copper tracks, and the connection is not in the netlist). To fix this you have to fiddle about with the “net tie” (This is still a kludge in KiCad V6).

May you explain better what should I do after Edit Pad asGraphics Shapes [Ctrl + E] because if I try to exit Pad Edit Mode Kicad hangs down. Also if I click Finish Pad Editing Kicad hangs down.

I looked also to NetTie footprints and apparently I see nothing different from my PCB inductor. But they work

What do you mean with “hangs down” Does it get slow, or does KiCad crash?

I have not seen unusual behavior after pad editing mode. It may be related to your footprint.
Can you make a small test project which contains your footprint?
If you do so then I’ll have a look at it if it works for me.

Thanks, I appreciate your help. How can I add/post a zip file here?

Copy and paste should work. You can also just drag it from a file browser into the edit window in your web browser.

proximity-coil.zip (56.5 KB)
This is the original project.

I’m having the same result.
As soon as I leave the pad edit mode, one of the threads on my PC goes to 100% and KiCad becomes unresponsive, and (after letting it sit for about two minutes) I had to kill it.

It may be a fault in your footprint itself, but even so, it should never be able to crash KiCad itself, so it’s (also) a bug in KiCad. Best response is probably to create a bug report for this on gitlab.

OK, thanks. I copied in my lib a NetTie to be able to play a little bit with it. I made also a test schematic obtained changing my PCB inductor with the NetTie (I choose NetTie-2_THT_Pad0.3mm) and it works, I mean I am able to route a track to its pads both on F.Cu and B.Cu so I suspect that if I understand how the NetTie footprint is done I could solve my problem. Seems that it doesn not ned Edit Pad as Graphic Shapes and that the track between the pads is done designing a filled rectangle. The only difference I foud was “net tie” on the keywords field of the Footprint Properties so I modified my PCB inductor but nothing changed. Any suggestion to understand if we can use in some way the NetTie footprint? I tryed to modify it removing its original rectangle and put the spiral of my PCB coil connected to the NetTie pads but it has the same behaviour of my original PCB inductor.
Another minor question is: now I have also to design a 2 layers PCB inductor so I will need a via to connect the F.Cu and the B.Cu spirals but in Footprint Editor I can only put pads. The problem is that via and pads have different DRC values and that vias are covered by the solder mask. It is the first time I need this type of component, until now I rarely designed PCB inductors and low value resitors and shunts but only on one layer and always using Kicad 5.

“Net tie” is an ugly hack that disables DRC for graphics on a copper layer. This was needed when KiCad became aware of graphics items on a copper layer, and this method was already in use for creating net ties.

A better implementation for net ties is being postponed to some future KiCad version.

I know there are several scripts for creating PCB inductors with spirals made for KiCad. Some in Python, others even in java.

I noticed that one full turn or your inductor has 16 arc segments. Why so many?

As a hobby I’m working on a CNC library that translates Python to Gcode and it also has a function that approximates a spiral with arc segments, but each turn is just two arcs. I’ve pasted the code below, maybe you can do something with it.

#---------------------------------------------------------------------------- 
def disc_cw( xxx, yyy, zzz, radius, step):
	""" Cut a disc Clockwise, from center, spiraling out to radius.
	with a lead-out at the end.
	Mills descends into a pre drilled hole to zzz. Then makes an
	spiral approximated by half circles and with "step" as stepover
	untill "radius" is 	reached.
	Last it does a circular lead-out with radius "step" and simultaneously 
	retracts zzz by 2mm. """

	comment( "disc_cw: " + XYZnn( xxx, yyy, zzz) +
		Valnn( "Rad", radius) + Valnn( "Step", step) )

	if step <= 0:
		comment( "Disc_cw error, Step <= 0: " + str( step))
		return
	if radius <= 0:
		comment( "Disc_cw error Negative radius: " + str( radius))
		return

	rapid( xxx, yyy)
#	Zrapid( zzz + 1)	# 2019-09-11 Removed because of use for cylinders.
#	if( zzz > Zabs):
	Zcut( zzz)
#	else:
#		""" 2019-09-11 If a cylinder is cut first, and then a disk, then zzz is
#		below the area which has to be cut. In this case it could go up with a rapid
#		instead of cut. """
#		Zrapid( zzz)
	arcs = []		# Create an empty list.
	rem = radius		# Remainder...
	count = 0
	""" Rules for this algorithm:
	1). xxx1 & xxx2 are the X coordinates of the arc endpoints.
	2). xxx2 > xxx1
	3). Arcs with endpoint xxx1 have their center at xxx
	4). Arcs with endpoint xxx1 have a radius of xxx - xxx1
	5). Arcs with endpoint xxx1 have a negative iii value.
	6). Arcs with endpoint xxx1 have therefore iii value of xxx1 - xxx.
	7). Arcs with endpoint xxx2 have a positive iii value.
	Todo: algorithm error when radius is negative.
	"""
	while rem > 0:
		xxx2 = xxx + rem
		xxx1 = xxx - rem + step
		iii2 = (xxx2 - xxx1) / 2
		iii1 = xxx1 - xxx

		if xxx2 > xxx:
			arcs.append( [xxx2, iii2] )
		if xxx1 < xxx:
			arcs.append( [xxx1, iii1] )

		count += 1
		rem = round( radius - count * step, 4)	# Smaller rounding errors

	arcs.reverse()
	# First arc may be smaller then step. Modify it as Lead-in:
	# Set iii to half the difference between xxx[0] and xxx.
	arcs[0][1] = (arcs[0][0] - xxx) / 2

	for arc in arcs:
		acw( arc[0], yyy, None, arc[1])
	# Add a full circle to make it complete.
	acw( xxx + radius, yyy, None, -radius)

	# Circular lead-out. with simultaneous small Z retract.
	if radius <= step * 2:
		# Small radius, lead-out is half circle.
		acw( xxx, yyy, zzz + (radius / 2), -radius / 2)
	else:
		# Circular lead-out with radius step  and the endpoint in the direction
		# of the centerpoint, for fluid rapids if multiple discs are stacked in
		# a cylinder.
		Pyt = sqrt( (radius - step) ** 2 - step ** 2 )
		iii = step ** 2 / ( radius-step)
		jjj = Pyt * step / ( radius - step)
		acw( xxx + radius - step - iii, yyy - jjj, zzz + 2, -step )

Note, in 6.99 (and upcoming 7.0) the situation is already improved. While we still will make some further net tie improvements in future versions, it’s no longer a hack.

I can define how many arcs for revolution, I tryed from the original 4 to 16 to see if that was the reason of the error.

Is there a ready 6.99 release for Windows that I can download? And may I install together 6.0.8 or have I to install jst one (in that case I could make a virtual machine for the other)?

Two is enough, more does not add anything usefull, less vectors is faster drawing.

The x.99 versions are always called “KiCad-nightly”. You can download them from the KiCad website. The link is on the bottom line of the windows download page. You should also be able to run the nightly version simultaneous with the latest stable version. Note that I run Linux, so I’m not very familiar with windows idiosyncrasies.

OK, thanks, I normally use also Linux (Mint) but on another PC and now I am working abroad but I always have with me some Linux VM so I may use also one of them to test Kicad 6.99