I’m trying to simulate an RC pulse circuit, but I’m not getting the results I thought I would and I’m getting an error with a label. In theory, the circuit should pulse with a time constant of τ=RxC, but “vout” goes straight to 3.3V instantly and stays there.
Also, I put a label “vgnd” on the ground bus but I get an error with the simulation saying “Warning : IC on non-existent node - /vgnd, ignored
Please check line .ic v(/vgnd)=0”
vgnd has already a GND 0 symbol and is set to 0. V(/vgnd) thus does not make sense.
R2 x xx 2m is 2 milli OHM, more or less short-circuiting C1. C1 therefore does not play any role.
I have never used the kicad simulator but the result seems correct since R2 = 2mOhm and R1 = 500k.
Instead of setting initial conditions, which is often a cause of unforeseen results, better use a pulse voltage source for V1 with a step from 0 to 3.3 V at a given time.
I see. I removed vgnd. Also, 2m should’ve been 2M so I fixed that, but the results are still the same:
Still the same input:
2m = 2M
2Meg = 2e6
Thanks guys! I commented out the .ic lines and just made the vsource a pulse. Then I fixed the discharge resistor to be 2e6 for 2 megaOhms. I’m a total noob when it comes to KiCAD and SPICE so sorry for the dumb questions 
. Here are the results:
You can apply Thevenin’s theorem and predict the curve without simulation.
I guess it comes down to some basic circuit analysis. Basically in your original circuit, R1 = 500K dominates the impedance around the current loop so that voltage drop in R2, Rwire, and C1 will be negligible by comparison. The simulator showing all voltage at the output is pretty much correct. Ignore C1. The circuit will pass 6.6 uA so you will only get 33 nanovolts drop in (Rwire + R3) and the voltage across R1 will be 3.299999967. Seldom would I calculate something out to so many decimal places but it was necessary here to make a point. My HP11C calculator is smoking.
The original circuit is easy to transform to the Thevenin equivalent. It’s just a 2.64V source in series with a 400k resistor to the capacitor. (Why such a large value?) But bearing in mind the voltage is referenced to the upper rail.
The modified circuit is even easier, you can ignore the 2M resistor and it’s just a 5k resistor from a 3.3V source.
I am not sure what you are looking at. I see a 3.3V source referenced to ground, in series with Rwire = 3 mOhms . Next comes 2 mOhms = 0.002 ohms in parallel with 470 uF, and finally 500K ohms to ground. If one does a casual measurement the only significant impedance is that 500K ohms. In the revised circuit the 470 uF capacitor will pass a current that decays after the initial step, so the voltage on the 500K will decay after the initial step.
OP meant it to be 2 megaohms, not 2 milliohms which makes no sense as that is effectively a short circuit.
Recently I have been using two simulators at work; TINA-TI and LTSpice. For one of them, it does not accept K for kilo; must be a lower case k. But I think m is milli while M is Mega. I find this to be consistently inconsistent and confusing. Fortunately it accepts engineering notation such as 4.7e-3 (at least as a keyboard input) for 4.7 milli. I like to label my own KiCad schematics that way and Excel accepts it readily as a number. Unfortunately it is not widely accepted by other humans. I have not yet gotten any opinions from chimpanzees.
It’s the SI standard. Many decades ago I asked my physics teacher why kilo was lowercase k when making it K would improve consistency, viz all > 1 prefixes uppercase and all < 1 prefixes lowercase. He shrugged. (Beyond his pay grade.)
Ngspice is following the original (now more than 40 years old) SPICE notion (see ngspice manual p. 50):
Input is case-insensitive.
milli (1e-3) is m or M
mega (1e6) is MEG or Meg or meg
1e6 is acknowledged
mil (25.4e-6) is there as well
In addition 4k7 is accepted.
That’s terrible. Possibly due to punch card or teletype input in those days. Enough to drive one to be a son of a turkey (would that be a Cluckson?) or adopt BobZ’s scientific notation.
That’s probably not a feasible idea:
All SPICEs use such SPICE notation.
All device models with subcircuit (vendor or user provided) use such notation.
A gross incompatibility would make the simulator unusable after such a unilateral change.
Well I would be interested in knowing if any SPICE does not accept scientific notation. Case insensitive does not apply (at least for one simulator) for k versus K which is not accepted.
But to add yet more confusion, my dad (no longer around to advise me on anything) related that m referred to 1000 (not 1/1000th) per Roman numerals for example. And I am no expert on “Romance” languages. We probably have some native Spanish speakers on this forum. But I think that “mil” in Spanish likewise means 1000. Give me scientific…nah…engineering notation. It reads right into your spreadsheet.
Maybe somebody punched the punch card machine operator? Or he drank too much punch.
But the Romans didn’t have lowercase, that’s from the Middle Ages. They also didn’t have tomatoes, potatoes, coffee, or chocolate. Not so much fun then.
And their keyboards were unwieldly: https://www.quora.com/Is-it-true-that-ancient-Romans-never-used-lower-case-letters 
Incidentally the upper/lower case distinction also pops up with other pairs: Deka/deci, Peta/pico. not to mention the ys and the zs. Hecto is another one that’s lowercase, and deka is apparently da, two letters.
Did they use upper and lower typewriters?
I think they had wine!!
