Re: Simulating simple electric circuits

Dave Baum wrote:
Are you trying to do logic simulation (digital) or analog circuit
simulation?

Mh, a mix of both :) I want to simulate (in principle simple)
magnetic relay circuits. The only "evil tricks" that are used are

- shortcuts (e. g. a relay coil is bypassed and thus the relay gets
no voltage and it relaxes)
- low currents (so a relay has current but doesn't switch)

I don't want to go into too much more detail about this one
because I have a hunch you are really looking at digital, but if
you're interested in the analog approach let me know and I'll fill
in more of the details.

Good hunch :) But thanks for the explanations. The fully analog
network approach is definitely overkill here.

For digital:

Event based simulation is typical here. These simulations
generally are concerned with voltage, not current. A circuit
consists of signals and devices. At any given time, each signal
has a certain state (high/low, on/off, 9 level logic, whatever).
Devices are connected to one another by signals. You'll also need
events (a signal, a time, and a new state), and an event queue
(events sorted by time). This is easier if each signal is driven
by at most one device:

1) pop the next event off the queue
2) if the event's signal's state is the same as the new state, go
to 1
3) set the event's signal's state to the new state
4) for each device that is attached to the signal, run the
device's code, which should look at all of its inputs, and post
new events to the queue for any outputs (do this even if the
computed output is the same as the current output). These events
are usually posted for some time in the future (1
simulation 'tick' is fine).
5) go to 1

This approach is pretty simple to do in Python. I wrote a sample
digital simulator a while back and the core of the simulator was
around 50 lines of code. Rounded out with some basic logic gates
and helper functions to probe the simulation, it was around 150
lines. It was only 2 level logic and signals could only be driven
by a single device.

The devices that you want to model (switches, loads, etc) don't
have explicit inputs and outputs, and you'll need to deal with a
signal being driven from multiple sources, so it will get a bit
more complicated. You will probably also need 9 level logic (or
something equivalent) to deal with the fact that ground beats a
source through a load when determining a node's state.

The basic idea is that each signal has multiple drivers, each of
which has an internal state. When a device wants to set an
output, it only changes its driver's state. The signal then has
code that looks at the state of all drivers and combines them in
some way (this is called a resolution function). That combined
state is what devices see when they read the signal.

It isn't *that* complicated to implement, but if you can turn your
problem into one with 2 level logic and no multiple drivers, then
it will be easier to write and debug.

Sounds more familiar than the analog approach. Maybe I misunderstood
something ... but I can't transfer my problem to this way of
thinking yet. My biggest problem is the fact that relays aren't
really interested in voltage, but current.

Also, I find it difficult to transfer this circuit logic to boolean
logic I can contruct logic gates from. Sometimes, electric circuits
are used in different directions.

This is how far I've come with my first approach yet:

I set up the mentioned "controller" which, at the beginning, tries
out all possible ways through the network and saves them. So, for
every possible circuit it knows which switches must be closed and
which relays will work if it's "on". In theory, it should now be
possible to try out every path, tell the relays if they have
voltage/current, and let the relays report back in to the
controller if their status changes so it can again test the
circuits that may have changed. I haven't tried out the last step,
but I will in the next days. Is there any logic error in my
strategy?

Regards,


Björn

--
BOFH excuse #122:

because Bill Gates is a Jehovah's witness and so nothing can work on
St. Swithin's day.

.

Relevant Pages

  • Re: ruthenium condemns ABX
    ... > Generally, in at least line level audio signals, driven from a low ... > Switching an audio signal at microphone- or phono cartridge levels is ... > I'm not sure if this is comparable to relay switch action. ... that audio is far removed from quantum effects. ...
    (rec.audio.opinion)
  • Re: ruthenium condemns ABX
    ... I am aware of some aspects of those physics. ... Generally, in at least line level audio signals, driven from a low ... Switching an audio signal at microphone- or phono cartridge levels is ... I'm not sure if this is comparable to relay switch action. ...
    (rec.audio.opinion)
  • Re: UK. ANCHOR HOUSING.Switch-over to DVB-T.
    ... This relay will be upgraded before the switch-over. ... analogue signal then there should be no need to change our ... My inquiries suggest that this relay will continue to use the same narrow band of signals so a new wideband aerial should not be needed. ... course his company have a vested interest in the 'upgrading' so his explanation will be interesting to say the least! ...
    (sci.electronics.misc)
  • Re: System for switching circuits of high-wattage devices
    ... and the audio equipment requires about 2000-2500 ... >circuits so that I dont blow fuses, ... >important that my audio equipment keeps running thoughout an event. ... >the CD players may not be able to handle the delay caused by the relay. ...
    (sci.electronics.misc)
  • Re: Hijacking part of a radio signal
    ... Although correct spelling doesn't seem as important as it once was unfortunately, in such esteemed and knowledgeable company I apologise for my single slip. ... Some comms relay satellites were hijacked by the Russians about 15 years ago, who used them to relay their own signals which were buried under the normal transmission using a spread spectrum signal. ...
    (uk.tech.broadcast)