Simulation is never as easy as you might like...  This runs: 

Ahh, thank you! That makes sense. I removed R11. The basic simulation with changes in R values works which is why I added the switch network. S6 with R6=16Meg runs, but S3 with R3=2Meg still gives me the time step too small error, unless I start the simulation later than 0. For example, ".tran 0 1500 1000 1" works, ".tran 2000" works, but ".tran 0 1500 0 1", ".tran 3000", ".tran 3000 startup", ".tran 0 3000 0 1" doesn't. I'm trying to understand whats happening. I might just end up removing that switch since I don't think we'd use it anyway.

@Dkraemer, It so happens that your circuit is taking you off the charts and into that bit of the map where it says "Here be dragons". High resistances with big capacitances and a sprinkle of logic and switching circuits is - perhaps unexpectedly - difficult territory for analogue circuit simulation. All simulators suffer what is called convergence failures. They can be highly unpredictable and the causes very difficult to diagnose. (If you want to read more about this sort of stuff I can post some links.) Part of the problem is that the static switch models used here have too high an OFF resistance so they can confuse LTspice. Sounds mad but there's a rule of thumb that the ratio of largest to smallest voltages or current in a sim should be less that about 1e12. The static switches have an off resistance of several orders of magnitude higher than that so that can be a cause of convergence failures. Another part of the problem is that the logic gate (and to a lesser extent, the relay) have some very carefully crafted but still very fast switching edges and delays internal to their operation and you are running a sim for 12k second on a circuit with elements that can switch in around 1ns which again breaks the 1e12 ratio. One way round this (which I used in my demo of your simplified circuit) was to reduce the resistor and capacitor values to reduce the time span needed to show circuit operation. That can help but can also be misleading. For example some real logic devices can oscillate or "fizz" if the input changes too slowly around the mid-logic-swing threshold and this may not be evident if the edge speed is increased by reducing the RC time constant (it is quite hard to simulate the conditions that can cause this behaviour anyway because most sims are quite deliberately, effectively noiseless and many of the parasitics of a real circuit are excluded, usually in the interests of getting a sim to run in less than several hours). The EasyEDA logic gate models have a somewhat lower than real input resistance (to keep them within the likely 1e12 ratio of external resistances) which means that if those external resistances are above about 10Meg then the circuit voltages can be loaded more than in a real circuit. This loading may not show up with a reduced R in the RC circuit whereas with the original R and a reduced C, you may see voltages ending up higher or lower than expected. In a real circuit this stuff can still happen. Moisture and accumulated dirt on a PCB can drastically reduce the resistance between tracks and pins. I had an instance recently where I was using a water washable flux on a PCB handling some very small currents. The circuit just would not work until I very carefully washed it under warm tap water and then dried it overnight. The flux residue had brought the surface resistance of the PCB down enough for everything to leak into everything else. This is the major reason that nowadays you do not see long interval timers made using analogue (RC, comparators, 555 timers etc.) techniques. A simple little clock oscillator (and yes that could still be a humble 555 timer) and a digital divider chain such as the CD4060 and a couple of gates is much less prone to dirt on resistors and the PCB, aging electrolytics and temperature. Oh, and relays really are just so last century... :) BTW: when you see a box of warning messages pop up, it's worth reading and, if posting about it, copying and pasting all of it because it often contains useful if arcane clues as to what has gone wrong.

Thank you for that excellent explanation! I'll look at the CD4060. I like that idea better. I was trying to recreate the currently used timer since people here love them so much and they're VERY resistant to change. It's especially awesome that the CD4060 has an internal oscillator so I don't need to add one! WOO!

@andyfierman Do you have a model for the CD4060? There isn't one in the library.  Also, it's my understanding that the blue symbol with the s means there's a spice model attached. Obviously not since I always get the "no model exists" error.

"it's my understanding that the blue symbol with the s means there's a spice model attached." It should mean that but in practice it is only true for spice symbols: 1. that have a model uploaded into the EasyEDA spice model library or the built-in LTspice library, neither of which users have access to; 2. a user has created for use in a schematic into which they have pasted a spice model; 3. a symbol that allows a .subckt or .model to be appended to but which is only available to that user. In fact AFAIK option 3 no longer exists anyway. Option 2 can be made to work you have a copy of the same model as the symbol creator and have the same spice pin ordering as the creator. In practice however, very few people get spice symbol creation right and even if they do, they even more rarely put anything meaningful in the symbol description let alone a link to the model they have used. This is demonstrated by your "Obviously not since I always get the "no model exists" error."" comment. This is why I said in an earlier topic that if you find user contributed spice symbols with my name as the owner, they should just work. There will be mistakes in some as I have had to update a lot of them in the move from Ngspice to LTspice and some I have missed or broken. For those, do the Report Error thing. You can do that with the other User Contributed spice symbols but you may not get any results. I also mentioned that yes, there is a CD4060 model in the system library but for reasons I have no control over , it is available in the native Chinese version of EasyEDA but not in the rest-of-the-world version. I have pointed this out but it's not fixed yet. I may be able to think of a workaround but it will take some time and there is another - EasyEDA related - problem. As explained in this topic: [https://easyeda.com/forum/topic/EasyEDA-Spice-simulation-needs-help-a3a54df212604abeaf776a3c1e99d444](https://easyeda.com/forum/topic/EasyEDA-Spice-simulation-needs-help-a3a54df212604abeaf776a3c1e99d444)<br> <br> basically there is a limit to the number of cycles of a periodic waveform that EasyEDA permits to avoid big (long, lots of edges so big data files) overhwelming the cloud resources. And that limit is well below the maximum count of a 4060. I have done sims with a 4060 but in EasyEDA it is only possible to run them for the first maybe 12 bits. The models were all developed on LTspice and tested on a local installation but the libraries are not publicly available as they have a huge amount of my own IP in them. If you scale the timer to the first few bits of the 4060 outputs to test the logic and then just wire the real thing using the higher order bits to get the real timings it should be fine. But that of course requires that the spice symbols are made available in the system library. (The basic problem is that I have some but not complete access to the model libraries...)

Sigh. That's too bad. I tried #3 sometime ago for a different chip and that didn't work, so now I know why. Thank you for letting me know.