开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育

Re: KiCad 8 Error while using demo project

 

On Fri, Mar 1, 2024 at 10:21 AM, Pedro Martín wrote:
There are no read-only projects but read-only directories.
Yes, I know that, and so does KiCad. It is displaying a banner on each window saying the "schematic is read only" and the "PCB is read only", yet it is still trying to autosave the files to those read only directories.?

The other issue is that this error occurs when viewing the demo projects that are installed by KiCad for use as demos by new users. These projects are opened from the File->Open Demo Project... menu and then this error message starts popping up every now and then while the user is trying to test drive KiCad. It's not a good introduction.

KiCad could offer to copy the demo project to another location when a demo is opened, but I suspect that would just seem like a barrier to a new user that just want to open a project an take a look.


Re: ngspice linear AC simulation?

 

Hi Jean-Michel,

You are correct. At least in KiCad 8, the simulation plot window for an AC simulation always shows a decade logarithmic frequency scale. The ngspice simulator executes the linear frequency sweep if that is what you ask for, but KiCad always displays a logarithmic frequency scale. The plot settings dialog is incorrect when it says "Number of points per decade" for a linear sweep. It should say "Number of points" for a linear sweep, and that is why you probably don't want to do that.?

Your command ".ac lin 101 100 1meg"?is?asking for 101 equally spaced points between 100 Hz and 1 MHz. If you subtract 100 from 1M you get a frequency span of 999,900 Hz. To get 101 points this span is divided by 100 to get a frequency step size of 9,999 Hz. So the first step is 100 Hz, the second is at 100 + 9999 = 10099 Hz, the third is at 10099 + 9999 = 20098 Hz, etc. until the final steps are at 990,001 Hz and 1 MHz. So your first three decades contain only two data points, one at 100 Hz, and one just past 10 kHz.?

Open the Simulation/Sallen_Key demo project (using File->Open Demo Project...) and simply change the command from ".ac dec 10 1 1meg" to?".ac lin 101 1 1meg"?and look at the difference in the plots. The original uses 60 points spread equally across the 6 decades with 10 points per decade. The second has two points in the first 3 decades and the other 98 spread over the last three decades with most of the points crammed up near the? 1 MHz frequency end. That is why linear frequency sweeps are usually used over a fairly narrow range of frequencies not over multiple decades.?

Until KiCad allows displaying a linear frequency scale to plot the results there is no reason to use a linear frequency sweep unless you want to see the data over a narrow range of frequencies in which case you can zoom in to see those frequencies only (but still on a logarithmic frequency scale).

You could put in a feature request to allow selecting linear frequency scales for display which would make using linear frequency sweeps more attractive.

HTH


Re: KiCad 8 Error while using demo project

 

There are no read-only projects but read-only directories.

Copy the project into a folder of your own and the problem should disappear.

Regards,
Pedro


El vie., mar. 1, 2024 a 17:28, Dennis
<dennisc@...> escribió:

[Edited Message Follows]

The same error message reappeared shortly after I posted my previous message. I now suspect that KiCad may be trying to autosave the project into the read-only Program Files directory. It shouldn't do this for a read-only project.

I can trigger the same message by manually trying to save the file.


Re: KiCad 8 Error while using demo project

 
Edited

The same error message reappeared shortly after I posted my previous message. I now suspect that KiCad may be trying to autosave the project into the read-only Program Files directory. It shouldn't do this for a read-only project.

I can trigger the same message by manually trying to save the file.


KiCad 8 Error while using demo project

 

I have just installed Kicad 8 and was trying to use one of the demo projects to check out the new features. I thought this error message appeared when I was using the 3D Viewer, but I am not certain (it appeared on my second monitor that was showing the schematic). I dismissed the error and then it reappeared a short while later while I was doing something else (not using KiCad). Both the schematic and PCB windows display a banner saying the files are read-only. I captured the error message on its second appearance. It has not reappeared while I was preparing this message. Has anyone else seen this message or does anyone know what may be causing it?



Application: KiCad Schematic Editor x64 on x64
?
Version: 8.0.0, release build
?
Libraries:
wxWidgets 3.2.4
FreeType 2.12.1
HarfBuzz 8.3.0
FontConfig 2.14.2
libcurl/8.5.0-DEV Schannel zlib/1.3
?
Platform: Windows 10 (build 19045), 64-bit edition, 64 bit, Little endian, wxMSW
?
Build Info:
Date: Feb 23 2024 02:24:15
wxWidgets: 3.2.4 (wchar_t,wx containers)
Boost: 1.83.0
OCC: 7.7.1
Curl: 8.5.0-DEV
ngspice: 42
Compiler: Visual C++ 1936 without C++ ABI
?
Build settings:
?


Re: Ignore courtyard DRC and library update

 

I see yes,

Some old versions did do this, but now running 8.00 and it's gone!


Re: Ignore courtyard DRC and library update

 

Hi,

Courtyard is board side specific. So if you place anything to the other side, it will generate no error.

The problem here is that there are components under each other on the same side.


Lev

On Fri, Mar 1, 2024, 10:11 applewiz2000 <rob@...> wrote:
Yes,

It would be nice if KiCAD could be set to ignore DRC errors for THT parts on the opposite side.
With RF boards the connectors (thru hole) are routinely mounted behind the circuit (SMD) to get short traces.

To avoid different keepout for both sides only the thru-hole pads have to be avoided.
This also happens with parts like PCB pots.
We have to be aware though it needs a bit of room to "swing the iron" and not put SMD parts hard up against THT pads.

-Rob


Re: Ignore courtyard DRC and library update

 

Yes,

It would be nice if KiCAD could be set to ignore DRC errors for THT parts on the opposite side.
With RF boards the connectors (thru hole) are routinely mounted behind the circuit (SMD) to get short traces.

To avoid different keepout for both sides only the thru-hole pads have to be avoided.
This also happens with parts like PCB pots.
We have to be aware though it needs a bit of room to "swing the iron" and not put SMD parts hard up against THT pads.

-Rob


ngspice linear AC simulation?

 

Until KiCAD 6 I was able to define a linear ngspice AC simulation by including a text
.ac lin 101 100 1meg
for simulating a linear frequency range from 100 Hz to 1 MHz with 101 samples/decade
but with the current KiCAD 7.0.11 freshly installed on Debian GNU/Linux and ngspice-42
the display remains with a logarithmic frequency scale despite Sim Command -> Custom
properly detecting my request.
In ngspice I would
.control
ac lin 101 100 1meg
.endc
but these statements are not detected as custom commands, even when setting LTSpice
compatibility flag.
Is there a way to achieve a linear frequency AC simulation with KiCAD as graphical frontend to ngspice?

Thanks, Jean-Michel


Re: KiCad 8.0 - Simple transformer simulation

 

Hah! Embarassing. Thank you very much Tony, you're quite right. You solved my problem. Much appreciated.


Re: Ignore courtyard DRC and library update

 

Thank you!
I am aware that there are alternative solutions (or lets call them workarounds)
available out there.

But I was specifically asking here for a possible (or future) KiCAD integrated
way which -ideally- does collision avoidance/visual feedback during the placement
process. If I want to drag a i.e. too high component into an area which has some
height restrictions, things should turn red and when I still want to place it,
it should tell me that I cannot place the thing there because of *meeh* + two
buttons: "Understood, nevermind." / "Ignore and place anyway and create a collision
because I know what I am doing."


Regards,

Clemens

On 29/02/2024 14.03, Robert via groups.io wrote:
Most of the boards I design have similar constraints, usually multiple
areas with different height limits, and on both sides of the board.
Normally what I do is create graphical keep-out areas on the User layers
as a visual cue, and then tread carefully. Even so, the mechanical
designer will take my step file and check it for clashes in mechanical
CAD.
Regards,
Robert.
--
Plain text email sent from robert's alpine raspberry


Re: Ignore courtyard DRC and library update

 

Most of the boards I design have similar constraints, usually multiple
areas with different height limits, and on both sides of the board.
Normally what I do is create graphical keep-out areas on the User layers
as a visual cue, and then tread carefully. Even so, the mechanical
designer will take my step file and check it for clashes in mechanical
CAD.

Regards,

Robert.
--
Plain text email sent from robert's alpine raspberry


Re: Ignore courtyard DRC and library update

 

I think you can make FreeCad to do these kind of collision detection.

I usually do it manually though.


Lev

On Thu, Feb 29, 2024, 13:10 Clemens Koller <cko@...> wrote:
Question in this context:

Is there a way to define a "keepout area" below the LCD for components
lower than a defined height? (i.e. to use the space for passives < 1mm bit
not higher.)

Regards,

Clemens

On 29/02/2024 04.22, brian wrote:
> 1) I also have a board with an LCD. I simply made the courtyard around
> the connector. The courtyard does not have to represent the outline of
> the part, you can make it a dot if you want.
>
> 2) I haven't figured out the migrate button either.
>
>
>
> On 2024-02-28 4:45 p.m., Lev wrote:
>> Hi all,
>>
>>
>> Thanks for KiCad 8
>>
>>
>> I have two questions regarding KiCad 8.0
>>
>> 1.
>> I have an LCD on my pcb, and have a large courtyard for it. Under my
>> LCD, there are lot of other components. When I run the DRC tool, I get
>> many false courtyard overlap errors. Is there any way to squelch
>> these? They might shadow real errors.
>>
>> 2.
>> I see a migrate library button. How does it work? If I push it, it
>> says I shall select libraries. If I select them, it says the same
>> error message.
>>
>>
>>
>> Thanks,
>> Lev
>>
>>
>
>
>
>
>
>






Re: Ignore courtyard DRC and library update

 

Question in this context:

Is there a way to define a "keepout area" below the LCD for components
lower than a defined height? (i.e. to use the space for passives < 1mm bit
not higher.)

Regards,

Clemens

On 29/02/2024 04.22, brian wrote:
1) I also have a board with an LCD. I simply made the courtyard around
the connector. The courtyard does not have to represent the outline of
the part, you can make it a dot if you want.
2) I haven't figured out the migrate button either.
On 2024-02-28 4:45 p.m., Lev wrote:
Hi all,


Thanks for KiCad 8


I have two questions regarding KiCad 8.0

1.
I have an LCD on my pcb, and have a large courtyard for it. Under my
LCD, there are lot of other components. When I run the DRC tool, I get
many false courtyard overlap errors. Is there any way to squelch
these? They might shadow real errors.

2.
I see a migrate library button. How does it work? If I push it, it
says I shall select libraries. If I select them, it says the same
error message.



Thanks,
Lev


Re: Ignore courtyard DRC and library update

 

1) I also have a board with an LCD. I simply made the courtyard around the connector. The courtyard does not have to represent the outline of the part, you can make it a dot if you want.

2) I haven't figured out the migrate button either.

On 2024-02-28 4:45 p.m., Lev wrote:
Hi all,


Thanks for KiCad 8


I have two questions regarding KiCad 8.0

1.
I have an LCD on my pcb, and have a large courtyard for it. Under my LCD, there are lot of other components. When I run the DRC tool, I get many false courtyard overlap errors. Is there any way to squelch these? They might shadow real errors.

2.
I see a migrate library button. How does it work? If I push it, it says I shall select libraries. If I select them, it says the same error message.



Thanks,
Lev


Ignore courtyard DRC and library update

 

Hi all,


Thanks for KiCad 8


I have two questions regarding KiCad 8.0

1.
I have an LCD on my pcb, and have a large courtyard for it. Under my LCD, there are lot of other components. When I run the DRC tool, I get many false courtyard overlap errors. Is there any way to squelch these? They might shadow real errors.

2.
I see a migrate library button. How does it work? If I push it, it says I shall select libraries. If I select them, it says the same error message.



Thanks,
Lev


--
Levente Kovacs
Senior Electronic Engineer

W:


Re: KiCad 8.0 - Simple transformer simulation

 

开云体育


On 28/02/2024 17:21, CW via groups.io wrote:
I am trying to simulate a simple transformer in KiCad 8.0.0 release build. I attach the project files for reference. I am using the 'coupled inductor' model with a .SUBCKT but I do not see the expected results in simulation when driving one inductor with a sinusoid. Would greatly appreciate any advice or pointing out any errors in the way I've implemented this.
The problem is your transformer subckt:

.SUBCKT BasicTransformer 1 2 3 4
L1 1 2 10m
L2 2 3 100m ---------> should be L2 3 4 100m
K12 L1 L2 0.99
.ENDS BasicTransformer

The secondary was not connected.

--
Regards,
Tony


KiCad 8.0 - Simple transformer simulation

 

Hello,
I am trying to simulate a simple transformer in KiCad 8.0.0 release build. I attach the project files for reference. I am using the 'coupled inductor' model with a .SUBCKT but I do not see the expected results in simulation when driving one inductor with a sinusoid. Would greatly appreciate any advice or pointing out any errors in the way I've implemented this.
Thank you.




Re: Minimum Track Width for Very Long Tracks

 

The project changed as various engineers reported concerns, both potential
and actual. Instead of one huge board there are now four relatively small
boards, two at the top and two at the bottom. Top-to-bottom comms is a
logical extension of the CAN bus, whilst the I2C bus will run the width of
each board, a distance that doesn't give me any cause for concern, either
in terms of signal length or physical length. So thank you for your
suggestions, but to my relief the potential problem has gone away.

The project is a larger version of a product that has already been built,
and that did use one large board that took the I2C over a significant
length. I used 0.4 mm track width, and all was OK, though being a
demonstrator it hasn't been through environmental testing. So maybe the
roasting is yet to come, both for the board and for myself :)

I wouldn't want to run SPI over anything other than a short distance, as
that would be begging for trouble IMHO. I have in the past run I2C over
many metres of cable with no special drivers (just carefully designed
filtering), but it was only low speed.

Regards,

Robert.


Re: Minimum Track Width for Very Long Tracks

 

On 1/12/24 07:00, Alan Pearce via groups.io wrote:
Yeah, but if you have a 'transmission line' you would avoid needing to
vary the track width or doing other things to create impedance bumps.
And using I2C to go 40-50 feet is taking it way beyond what it was
designed for. Going those sort of distances one uses other techniques,
or runs the I2C much slower.
I should also mention an extremely fast setup called SPI which is totally dependent of the slew of rise and falls of the signals, to make it work, typicaly src terminated as in the case of the connection between an rpi4b's gpio pins, and a mesa 7i90HD interface card that runs my biggest lathe, an 85 yo Sheldon 11x54. Exchanging 32 bit packets of data over a 3 wire buss, typically a piece of std ribbon cable. That stuff has a typical impedance of 122 ohms. And it runs at the clock speeds of the system so the pi transmits at 42.66 megabaud, and the mesa card answers at 25 megabaud. The way I did it was to turn the pi upside down which made the ribbon cable just over an inch long. I first had a pi3b in there, but when the faster rpi4b came out swapped the card, keeping the sd card. I don't believe it has made a mistake in 8 years.

It may be a transmission line, but its very short, I've heard rumors it still works with a 1 foot cable. Using std 6" jumper wires didn't work unless I put a 10 pf cap on one of the gpio pins to slow the rise and fall times, discovered when I put a scope probe on the line and that made it work. That was far enough back up the log it was an analog scope, the usual dual trace 100 mhz Hitachi. I bought the digital storage version when it came out, then bought Siglents best a couple years ago, a 4 colored trace 350 mhz model. You can look at the ringing of a signal edge and see the clipping of the negative overshoot being squared off by the conduction of the isolation substrait diode in the ic's input at a -.6 volt level. I had read about it, but that is the first time I'd actually seen it. Actual conduction time was about 1.3 nanoseconds. You'd be amazed at what you can see with a fast enough scope.

Take care guy.

On Fri, 12 Jan 2024 at 00:12, Gene Heskett <gheskett@...> wrote:

On 1/11/24 13:52, Alan Pearce via groups.io wrote:
I wouldn't have thought you would need to treat I2C lines as
transmission lines, the data rate is quite slow (even at high speed
I2C you are still only at 4MHz). It is not as though you are laying
out a memory array where a heap of parallel address and data lines
need to be synchronised to a double data rate clock, and so edge
timings are highly critical. The I2C transfer clocking is designed to
deal with a small amount of ringing on the clock and data lines.
Considering it was originally designed to be run in a wire harness in
a TV set, it should be quite robust.

But as to track width on a PCB, as you are not constrained by
requiring impedance controlled tracks, make them wide enough that they
will be robust in manufacturing of the PCB (i.e. don't create
under-etching problems, corner peel problems, etc) so that the PCB
house minimises rejection rates, and then during assembly &
integration the tracks are robust enough to withstand knocks and rough
handling without causing micro-cracks in the tracks. Personally I
would go for something like 0.5mm, only thinning when needed to
squeeze through gaps between pins and pads.
And every time you do that, there's a huge bump in the impedance at that
point. If you don't have a T.D.R., make it or get one. I've made one a
few times, and made it work well enough to tell a tower crew looking for
a burnout in a transmission line which joint to take apart to find the
top or bottom of a line fire. Saves at least a day getting the fire
damage repaired and the tv station back on the air.

I2c is the most ticklish transmission they ever threw at us, designed to
work at ttl voltage levels, the drivers have so little surplus power
that it can't be properly terminated to make it a real transmission
line. That limits it to under 40 feet. src terminated, maybe 50 feet.
With more modern fasrer circuitry.

On Thu, 11 Jan 2024 at 16:39, John Woodgate <jmw@...> wrote:

0.2 mm sounds OK, but it's only eight thousandths of an inch. Any defect, even a change of hardness/annealing, in the copper creates a stress-concentration joint, leading to a crack. I think you should make the tracks as wide as possible, for good reliability.

On 2024-01-11 16:01, Robert via groups.io wrote:

The lines concerned are I2C clock and data, and yes, I will be
considering them as transmission lines. However, there's no point
laying something down that is electrically just fine if the board cannot
be manufactured reliably or the tracks break during assembly (it will
get bolted down, but before that happens someone will have to pick it up
and move it into position).

Chinese PCB houses can routinely achieve 0.15 mm on normal sized boards.
So am I worrying about nothing, because they will in fact have no
trouble with a track (say) 0.2 mm wide and 500 mm long, if that's what I
would choose from an electrical viewpoint?

Regards,

Robert.

* Plain text email - safe, readable, inclusive. *









.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis





.
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis