Simulation von Digitalen Schaltungen

Niko Ortner · 21. März 2016, 15:27

Ich versuche, digitale Schaltungen zu simulieren. Das ist ganz einfach gehalten. Es gibt keine Spannungspegel oder so, sondern nur ob eine Leitung aktiv ist oder nicht.
Zur Veranschaulichung ein Beispiel:

Simple Schaltung:
Links oben ist eine Dauerversorgung. Dinge, die daran angschlossen sind, sind immer aktiv.
Rechts die roten Kreise sind LEDs die den Zustand der Leitung, an die sie angeschlossen sind, wiederspiegeln.
Ganz unten ist eine Verbindung zu was anderem in der Schaltung. Solche Verbindungen sind bidirektional.
In der Mitte ein Relais mit einem Wechslerkontakt (wovon nur der Öffner verwendet wird).

Man beachte, dass hier nirgends Masse-Leitungen eingezeichnet sind. Da alle Bauteile sowieso immer fix an Masse angeschlossen sind, ist es unnötig, diese Leitungen auch noch einzuzeichnen. Dass die LEDs eine andere Betriebsspannung als die Relais haben ist hier auch irrelevant. Es geht wie gesagt nur darum, festzustellen, ob eine Leitung bzw. ein Bauteil aktiv ist.
Eine Leitung ist dann aktiv, wenn mindestens ein Bauteil ein Signal "auf die Leitung sendet". Und das ist auch nicht wie z.B. bei TTL, dass zwei Ausgänge nicht direkt verbunden werden dürfen da sonst bei unterschiedlichen Ausgangszuständen ein Kurzschluss entsteht. Wenn eine Leitung nicht aktiv ist, dann bedeutet das hier, dass sie einfach nicht mit der Versorgungsspannung verbunden ist.

Hier wird links der Zustand der Schaltung gezeigt, wenn von der Verbindung unten kein Signal kommt. Die Leitungen C sind nicht aktiv, die rechte LED deshalb auch nicht, das Relais zeiht nicht an, verbindet dadurch die Leitungen A und B, es entsteht eine Verbindung von der Versorgung zur linken LED und somit ist diese aktiv.
Rechts daneben das Gegenteil. Von der Verbindung unten kommt ein Signal zu C, die rechte LED ist aktiv, das Relais auch und zieht an, trennt dadurch A und B und dadurch ist die linke LED nicht mehr aktiv.

Die Schaltung sollte "Schritt für Schritt" simulierbar sein. Das heißt, bei jedem Schritt wird zuerst der neue Zustand aller Bauteile und Leitungen berechnet und dann erst werden alle Zustände übernommen. Sinn der Sache ist der: Da auch "Rekursionen" wie diese vorkommen können:

, würde die Simulation hier nie fertig werden und je nach Implementierung eine Endlosschleife oder einen StackOverflow zur Folge haben.
Davon abgesehen möchte ich wissen, wie lange es dauert, bis sich in einer Schaltung keine Zustände mehr verändern.
Das sollte aber nicht so weit gehen, dass einzelne Leitunssegmente pro Simulationsschitt berechnet werden:

Es ist auch OK, wenn Leitungen sofort neu berechnet werden, sobald z.B. ein Relais einen Kontakt schaltet. Nur umgekehrt sollte es nicht sein: Bauteile sollten ihre Zustände nicht sofort verändern, wenn sich die Zustände von angeschlossenen Leitungen verändern.

Wichtig ist für mich auch, dass unnötige Updates vermieden werden. Wenn z.B. eien Leitung bereits aktiv ist und durch eine Veränderung eine Weitere Verbindung zu einer Versorgung hergestellt wird, dann sollen nicht nochmal alle Teile der Leitung und alle angeschlossenen Bauteile neu berechnet werden. Das System sollte nämlich auch bei größeren Schaltungen um die 20000 Objekte nicht mit Updates explodieren.

Eine Sache noch: Der gespeicherte Zustand soll möglichst nicht direkt in den Objekten, die die Bauteile und Leitungen repräsentieren, verpackt sein, sondern in separaten, klonbaren Datenstrukturen gespeichert sein. Sinn der Sache ist der: Ich möchte die Zustände zwischenspeichern können, ohne dabei alle Informationen der Bauteile mitzukopieren. Dadurch kann ich nach jedem Schritt prüfen, ob die neuen Zustände gleich den alten sind bzw. "Backups" von Zuständen machen und diese später wieder laden.
Dabei wird hilfreich sein, dass jedes Bauteil bzw. jede Leitung und jeder Anschluss eine GUID besitzt. Diese wird bereits zum Abspeichern verwendet und kann sicher auch verwendet werden, um festzustellen, welche Simulationszustände zu welchem Bauteil gehören.

Also wenn jemand Ideen hat, wie man sowas hinbekommt, dann immer her damit. Wenn irgendwas unklar bzw. nicht ausreichend erklärt ist, erkläre ich das gerne genauer.

nafets · 21. März 2016, 15:50

Um Endlosschleifen zu vermeiden würde ich versuchen, jeden vorherigen Status zu speichern und dann zu überprüfen, ob sich einer von diesen wiederholt. Ist dies der Fall, liegt dann ja klar eine Endlosschleife vor.

ErfinderDesRades · 21. März 2016, 15:58

mathematisch gesehen sind solche Schaltungen Graphen.
Graphen kann man als Veralgemeinerung von Bäumen auffassen. Ein Baum ist ja kreisfrei und gerichtet, von Root zu den Leafs hin, aber beim Graph sind Zirkelbezüge gültig.
Deshalb kann man Graphen auch nicht im Treeview abbilden, sondern muss so UML-ähnliche Diagramme bemühen, die von Fall zu fall unterschiedlich ausfallen können.

Egal.
Inne Informatik kann man Graphen relational modellieren.
Lies dir Wikipedia zu Graphne, Kanten und Knoten und Zeugs, das hat alles eine enge Verwandaschaft zu Tabellen und Relationen.

Ich weiß jetzt nicht, was du im einzelnen ausrechnen wilslt, aber die Graphen-Theorie hält grundsätzlich unerhört möchtige Werkzeuge und Theorien bereit - ist aber vlt auch mit Kanonen auf Spatzen, zB mit Fourier-Transformation auf deine paar digitalen Bauteile da loszugehen.
Aber vlt. auch nicht.

Niko Ortner · 21. März 2016, 16:08

@nafets
Da ich sowieso diskrete Schritte haben möchte ergibt sich das Problem eigentlich.

@ErfinderDesRades
Die Bauteile ansich sind bereits da. Das hab ich wirklich vergessen zu erwähnen. Ich habe bereits ein Programm um die ganzen Schaltungen aufzubauen und ich möchte da jetzt die Simulation hinzufügen.

Trade · 21. März 2016, 16:20

Anmerkung zu EDR: Die Datenstruktur Graph lässt sich relativ leicht über eine Adjazenzmatrix darstellen.

Grüße

Niko Ortner · 23. März 2016, 12:54

*Push*

ErfinderDesRades · 23. März 2016, 13:08

Tja, ich hab nicht recht verstanden, was die Simulation macht, insbes. was einen Schritt der Simulation ausmacht.

Hast du da einen stabilen Zustand, und greifst dann da ein?
Woraus sich dann lauter Folgerungen ergeben?

Schmandal · 23. März 2016, 13:17

Zuerst möchte ich dazu sagen, dass ich wenig Ahnung von der Materie habe, aber das Thema an sich sehr interessant ist. Die Idee von @ErfinderDesRades ist gar nicht mal schlecht. Allerdings ist FFT evtl. ein bisschen (was genau ist größer als eine kanonenkugel und fliegt gut) auf Spatzen geschossen :). Ist dein Programm aufgebaut wie eine Schaltung an einer realen Schalttafel (die Dinger zum stecken)? Dann könntest du wahrscheinlich auf eine ganz simple Matrix (Matrizen) zurückgreifen, um alle Zustände zu prüfen (ggf. mit Vektoren etc). Da wäre die Anzahl der Bauteile dann ja vollkommen egal?

Ist vielleicht nicht der ideale Ansatz, aber ich denke in die Richtung würde ich bei so einem "großem" Projekt recherchieren. Aber just my 2 Cents.

Gonger96 · 23. März 2016, 13:30

Bei vielen Simulationsprogrammen wird einfach mit nem Timer von + nach - alles durchgegangen. Macht auch irgendwo Sinn, der Strom macht's ja nicht anders, nur in schnell.

Niko Ortner · 24. März 2016, 15:40

@Gonger96
So genau muss es nicht sein. Hier sind keine Masse-Leitungen eingezeichnet, weil alle Bauteile sowieso mit dem zweiten Anschluss (sofern zutreffend) an Masse hängen. Davon abgesehen sind Leitungen, die aktiv sind, mit der Versorgungsspannung verbunden (wie hoch auch immer die sein mag).Leitungen, die inaktiv sind, sind es einfach nicht. Also inaktive Leitungen sind nicht mit Masse verbunden, sondern einfach nicht mit der Versorgunsspannung verbunden (also das Äquivalent von hochohmigen Ausgängen bei diskreten Bauteilen).

@ErfinderDesRades
Im Startpost zeigt das 5. Bild ein Beispiel. Ignorier den Teil oben, wo "Falsch" steht, denn so sollte es nicht funktionieren. Darunter sind von links nach rechts 5 Zustände der schaltung gezeigt.
Ganz links ist der Ausgangszustand.
Dann wird ein Schritt berechnet und heraus kommt das rechts daneben. Also von irgendwo her kommt unten ein Signal und dadurch wechselt die Leitung von inaktiv zu aktiv.
Dann wird der nächste Schritt berechnet und heraus kommt das, was eins weiter rechts gezeigt wird: Das Relais hat von inaktiv zu aktiv gewechselt und dadurch den Wechslerkontakt umgeschaltet. Wie das Umschalten genau gemacht werden soll weiß ich auch noch nicht. Die rechte LED hat ebenfalls von inaktiv zu aktiv gewechselt.
Nächster Schritt: Die Leitung oben in der Mitte wechselt von aktiv zu inaktiv, weil sie jetzt nicht mehr mit der anderen, aktiven Leitung verbunden ist. Beachte auch, dass der andere andere Anschluss des Wechslerkontaktes jetzt aktiv ist, da er ja mit der anderen, aktiven Leitung verbunden ist.
Und dann nochmal ein Schritt: Die LED wechselt von aktiv zu inaktiv, weil die Leitung, an der sie angeschlossen ist, inaktiv ist.

Hast du da einen stabilen Zustand, und greifst dann da ein?
Woraus sich dann lauter Folgerungen ergeben?

Das würde nicht ohne weiteres funktionieren. Siehe dazu Bild #4 im Startpost. Würde man alle Folgerungen und deren Folgerungen und so weiter sofort berechnen, dann würde der Simulationsschritt bei dem Beispiel nie fertig werden.

Also für die Simulation gelten folgende zwei Einschränkungen:

Wenn sich der Zustand eines einzigen Teils der Leitung verändert, dann sollen alle Zustände aller Teile einer Leitung sofort berechnet werden. Also eben nicht so wie in Bild #5 bei "Falsch" gezeigt.
Wenn eine Leitung an ein Bauteil angeschlossen ist und sich der Zustand der Leitung im aktuellen Simulationsschritt verändert, dann soll der Zustand des Bauteils erst im nächsten Simulationsschritt berechnet werden.
Wenn eine Leitung an ein Bauteil angeschlossen ist und sich der Zustand des Bauteils im aktuellen Simulationsschritt verändert, dann soll der Zustand der Leitung erst im nächsten Simulationsschritt berechnet werden.

Ich hab das Projekt mal angehängt. Vielleich hiltft das beim Verständnis, wie es aktuell aufgebaut ist. Projektmappe öffnen, Debuggen, oben links auf "Datei" klicken und die TestCircuit.xml-Datei öffnen, die in der Zip liegt.
Die ganzen Bauteile sind im Components-Ordner. Die Vererbungshierarchie sieht so aus:

VB.NET-Quellcode

ScreenObject 'Irgendwas was angezeigt werden und mit der Maus interagieren kann.
Clamp.Contact 'Eine Klemme kann mehrere Kontakte haben. Kontakte können Eingänge, Ausgänge oder bidirektional sein.
Relay.Contact 'Ein Relais kann mehrere Kontakte haben. Alle Kontakte sind Wechsler.
GrabPoint 'Für Maus-Interaktion zum Ziehen.
WirePlug 'Man kann Leitungen dran anschließen. Jedes WirePlug-Objekt hat eine GUID.
Component 'Irgendwas, was Teil des Schaltplans ist. Jedes Component-Objekt hat eine GUID.
Board 'Ein Projekt kann aus mehreren Unterbereichen bestehen. Die Klasse erbt nur aus Bequemlichkeit von Component, ist aber eigentlich nicht wirklich Teil des Schaltplans.
Wire 'Eine Leitung. Wire-Objekte sind immer an exakt zwei WirePlug-Objekten angeschlossen.
Device 'Irgendwas, was ein simples Bauteil ist. Zeichnet sich in erster Linie dadurch aus, dass es rotierbar und mit nur einem GrabPoint-Objekt verschiebbar ist.
CControl 'Im Grunde genommen ein 64k RAM-Chip.
Clamp.Clamp 'Eine Klemme, an der externe Geräte angeschlossen werden können
Connector 'Verbindet Leitungen, die sich auf unterschiedlichen Boards befinden, wenn für beide Connector-Objekte der gleiche BusName und PinName verwendet wird.
Led 'Zeigt einen Zustand an.
Relay.Relay 'Ein Relais halt. Kann mehrere Kontakte haben.
Transistor 'Wird für den RAM-Chip benötigt. Basis ist Eingang, Kollektor ist Ausgang.
VPlus 'Versorgungsspannung. Gibt immer ein Signal aus.
WirePoint 'Wird verwendet, um Leitungen zu "verlegen".

@Moderation
Ich hoffe es ist OK, dass sich im Libs-Ordner in der Zip-Datei zwei Dlls befinden. Man soll ja außerhalb des Showrooms keine ausführbaren Dateien anhängen. Bin- und Obj-Ordner sind aber gelöscht.

ErfinderDesRades · 24. März 2016, 16:20

also deine Simulation scheint mir ein Walkthrough durch den Graphen zu sein.

Das kann man mit Async sogar recht übersichtlich gestalten, man sollte aber eine Breath-First-Traversion wählen, denn bei Rekursion wird Async bisserl komisch.

BFT sagt dir was? das ist die iterative Alternative, um Bäume zu durchlaufen - dabei wird eine Queue auf- und ab-gebaut.

Vlt. Sample dazu hier: codeproject.com/Articles/10296…ithout-any-additional-Lin

Ganz am schluss hab ich Floodfill-Algos gebastelt, und einer der beiden ist BFT.
Damit kann man auch auf deine Schaltungen losgehen.
Um Zirkel-Wege zu vermeiden sollteste sogar eine weitere FloodFill-Anleihe machen: Nämlich bereits besuchte Knoten markieren, und in Folge nicht nochmal besuchen.

(achso - und wenn dir der Artikel was bringt, rate ihn hoch. Ich zumindest finde ihn wichtig (das mittm Floodfill noch am wenigsten))

Niko Ortner · 13. April 2016, 16:44

So, habs geschafft.

Die Lösung ist eine Mischung aus den Ansätzen von @Gonger96 und @ErfinderDesRades

von + nach - alles durchgegangen

Walkthrough durch den Graphen

Ich mache im Grunde folgendes:

Alle Objekte suchen, die von sich aus aktiv sind. Also beispielsweise so ein VPlus-Objekt. Oder irgendwelche aktiven Ausgänge von Bauteilen.
Als temporärer Zustand für alle Objekte wird inaktiv festgelegt.
Rekursiv, von den in Schritt 1 gefundenen Objekten ausgehend, den temporären Zustand des Objektes auf aktiv setzen und mit allen verbundenen Objekten das gleiche machen, und mit deren verbundenen Objekten und so weiter.
Alle Objekte, die hier gefunden werden, sind mit der Versorgungsspannung verbunden, denn sie sind ja mit den Objekten verbunden, die in Schritt 1 gefunden wurden.
Den aktuellen Zustand auf den temporären Zustand festlegen. Alle Objekte, die in Schritt 3 gefunden wurden, sind somit aktiv. Alle Objekte, die in Schritt 3 nicht gefunden wurden, sind nicht mit der Versorgungsspannung verbunden und somit inaktiv (der temporäre Zustand wurde nie auf aktiv gesetzt).

Das funktioniert auch bei großen Schaltungen noch sehr schnell.

Vereinfacht sieht das so aus

Alle simulierbaren Objekte implementiern dieses Interface:

VB.NET-Quellcode

Public Interface ISimulatable
'Wird z.B. zum Speichern und Laden des Zustandes verwendet.
ReadOnly Property Guid As Guid
'Der aktuelle Zustand des simulierbaren Objektes
Property CurrentState As Boolean
'Setzt den temporären Zustand auf inaktiv.
'Wird rekursiv für untergeordnete Objekte aufgerufen.
'Fügt das Objekt der SimulationContext.AllSimulatables-Liste hinzu.
'Ist ein Objekt bereits vonsich aus aktiv (z.B. VPlus), dann wird es zusätzlich zur SimulationContext.InitiallyActiveSimulatables-Liste hinzugefügt.
Sub PrepareSimulationStep(Context As SimulationContext)
'Setzt den temporären Zustand auf aktiv.
'Wird rekursiv für die Objekte aufgerufen, die mit dem aktuellen Objekt verbunden sind.
Sub VisitActive(Context As SimulationContext, Source As ISimulatable)
'CurrentState wird auf den temporären Zustand festgelegt.
'Wenn VisitActive für dieses Objekt aufgerufen wurde, ist es über irgend einen Pfad mit der Versorgungsspannung verbunden.
Sub ApplyCalculatedState()
End Interface
Public Class SimulationContext
'Alle simulierbaren Objekte.
Public ReadOnly Property AllSimulatables As List(Of ISimulatable)
'Nur die simulierbaren Objekte, die von sich aus aktiv sind (z.B. VPlus)
Public ReadOnly Property InitiallyActiveSimulatables As List(Of ISimulatable)
'Von allen Connector-Objekten diejenigen raussuchen, die mit dem angegebenen Connector-Objekt logisch verbunden sind.
Public Function FindAllConnectors(SourceConnector As Connector) As IEnumerable(Of Connector)
Return AllSimulatables.OfType(Of Connector).Where(Function(i) i.BusName = SourceConnector.BusName AndAlso i.PinName = SourceConnector.PinName)
End Function
End Class

Die Relay-Klasse sieht dann so aus:

VB.NET-Quellcode

Partial Public Class Relay
Inherits Device '-> Component -> ISimulatable
'Stark vereinfacht!
Dim WithEvents CoilPlug As WirePlug
Public ReadOnly Property Contacts As New List(Of Contact)
'WirePlug-Objekte lösen dieses Event aus, damit die Objekte, zu denen sie gehören, angeben können, mit welchen anderen Objekten sie verbunden sind.
Private Sub CoilPlug_ConnectedSimulatablesRequested(sender As Object, e As ConnectedSimulatablesRequestedEventArgs) Handles CoilPlug.ConnectedSimulatablesRequested
e.Simulatables.Add(Me) 'Ist direkt mit dem aktuellen Relay-Objekt verbunden.
e.Handled = True
End Sub
'Der tempräre Zustand.
Dim ComputedState As Boolean
Dim _CurrentState As Boolean = False
Public Overrides Property CurrentState As Boolean
Get
Return _CurrentState
End Get
Set(value As Boolean)
If _CurrentState <> value Then
_CurrentState = value
For Each i In Contacts
i.SimulationState = value 'Teilt den Contact-Objekten mit, welche Anschlüsse verbunden sein sollen.
Next
End If
End Set
End Property
Public Overrides Sub PrepareSimulationStep(Context As SimulationContext)
Context.AllSimulatables.Add(Me)
ComputedState = False 'Temporären Zustand auf inaktiv setzen.
CoilPlug.PrepareSimulationStep(Context)
For Each i In Contacts
i.PrepareSimulationStep(Context)
Next
End Sub
Public Overrides Sub VisitActive(Context As SimulationContext, Source As ISimulatable)
ComputedState = True 'Das Relais ist mit der Versorgungsspannung verbunden -> Am Ende des Simulationsschrittes auf aktiv setzen.
End Sub
Public Overrides Sub ApplyCalculatedState()
CurrentState = ComputedState
End Sub
End Class

Und dazu passend die Contact-Klasse:

VB.NET-Quellcode

Public Class Contact
Inherits ScreenObject
Implements ISimulatable
' /---- PlugNC
' /
' PlugC ----/| ---- PlugNO
' |
' |
' ---
' | | --- CoilPlug
' ---
Public ReadOnly Property Guid As Guid Implements ISimulatable.Guid
Public ReadOnly Property PlugC As WirePlug
Public ReadOnly Property PlugNC As WirePlug
Public ReadOnly Property PlugNO As WirePlug
Public Property SimulationState As Boolean
'Wenn das Relais angezogen hat (also aktiv ist), dann ist PlugC mit PlugNO (Normally Open) verbunden. Ansonsten mit PlugNC (Normally Closed).
Private Sub PlugC_ConnectedSimulatablesRequested(sender As Object, e As ConnectedSimulatablesRequestedEventArgs) Handles PlugC.ConnectedSimulatablesRequested
If SimulationState Then
e.Simulatables.Add(PlugNO)
Else
e.Simulatables.Add(PlugNC)
End If
e.Handled = True
End Sub
'PlugNO ist mit PlugC verbunden, wenn das Relais aktiv ist. Ansonsten mit nichts anderem.
Private Sub PlugNO_ConnectedSimulatablesRequested(sender As Object, e As ConnectedSimulatablesRequestedEventArgs) Handles PlugNO.ConnectedSimulatablesRequested
If SimulationState Then
e.Simulatables.Add(PlugC)
End If
e.Handled = True
End Sub
Private Sub PlugNC_ConnectedSimulatablesRequested(sender As Object, e As ConnectedSimulatablesRequestedEventArgs) Handles PlugNC.ConnectedSimulatablesRequested
If Not SimulationState Then
e.Simulatables.Add(PlugC)
End If
e.Handled = True
End Sub
'Die Contact-Objekte benötigen selbst keinen Zustand (wird von der Relay-Klasse mit SimulationState gesetzt).
Public Property CurrentState As Boolean Implements ISimulatable.CurrentState
Get
Return False
End Get
Set(value As Boolean)
End Set
End Property
'Die Contact-Objekte arbeiten bei der Simulation nicht aktiv mit, sondern verbinden nur die WirePlug-Objekte.
'Deshalb wird nicht wie in der Relay-Klasse Context.AllSimulatables.Add(Me) aufgerufen, sondern der Aufruf nur an die WirePlug-Objekte weitergeleitet.
Public Sub PrepareSimulationStep(Context As SimulationContext) Implements ISimulatable.PrepareSimulationStep
PlugC.PrepareSimulationStep(Context)
PlugNO.PrepareSimulationStep(Context)
PlugNC.PrepareSimulationStep(Context)
End Sub
Public Sub VisitActive(Context As Simulation.SimulationContext, Source As Simulation.ISimulatable) Implements Simulation.ISimulatable.VisitActive
End Sub
Public Sub ApplyCalculatedState() Implements Simulation.ISimulatable.ApplyCalculatedState
End Sub
End Class

Die WirePlug-Klasse sieht so aus:

VB.NET-Quellcode

Public Class WirePlug
Inherits ScreenObject
Implements ISimulatable
Public ReadOnly Property Guid As Guid Implements ISimulatable.Guid
Public ReadOnly Property AttachedWires As List(Of Wire)
Public Event ConnectedSimulatablesRequested As EventHandler(Of ConnectedSimulatablesRequestedEventArgs)
Private Function RequestConnectedSimulatables() As IEnumerable(Of ISimulatable)
Dim Args As New ConnectedSimulatablesRequestedEventArgs(Me)
RaiseEvent ConnectedSimulatablesRequested(Me, Args)
If Not Args.Handled Then
Throw New NopeException("ConnectedSimulatablesRequested muss behandelt werden.")
End If
Return Args.Simulatables
End Function
Dim ComputedState As Boolean
'Wird von übergeordneten Objekten auf True gesetzt, um Ausgänge aktiv zu schalten.
Public Property ForceOutputActive As Boolean
Dim _CurrentState As Boolean = False
Public Property CurrentState As Boolean Implements ISimulatable.CurrentState
Get
If ForceOutputActive Then
Return True
End If
Return _CurrentState
End Get
Set(value As Boolean)
If _CurrentState <> value Then
_CurrentState = value
OnInvalidated()
End If
End Set
End Property
Public Sub PrepareSimulationStep(Context As SimulationContext) Implements ISimulatable.PrepareSimulationStep
Context.AllSimulatables.Add(Me)
ComputedState = False
If ForceOutputActive Then
Context.InitiallyActiveSimulatables.Add(Me)
End If
For Each i In AttachedWires
i.PrepareSimulationStep(Context)
Next
End Sub
Public Sub VisitActive(Context As SimulationContext, Source As ISimulatable) Implements ISimulatable.VisitActive
ComputedState = True
For Each i In AttachedWires
If Not i Is Source Then 'Zur Optimierung wird immer mitgegeben, von wo aus das Signal kommt. Dadurch Muss VisitActive nicht nochmal an dem Quell-Objekt aufgerufen werden.
i.VisitActive(Context, Me)
End If
Next
For Each i In RequestConnectedSimulatables()
If Not i Is Source Then
i.VisitActive(Context, Me)
End If
Next
End Sub
Public Sub ApplyCalculatedState() Implements ISimulatable.ApplyCalculatedState
CurrentState = ComputedState
End Sub
End Class

Verwendet wird das Ganze so:

VB.NET-Quellcode

'Im MainWindow:
Private Sub ExecuteSimulationStep()
Dim Context As New SimulationContext
For Each i In CurrentProject.Boards.SelectMany(Function(b) b.BoardComponents)
i.PrepareSimulationStep(Context)
Next
For Each i In Context.InitiallyActiveSimulatables
i.VisitActive(Context, Nothing)
Next
For Each i In Context.AllSimulatables
i.ApplyCalculatedState()
Next
End Sub

ErfinderDesRades · 13. April 2016, 16:59

Niko Ortner schrieb:

Das funktioniert auch bei großen Schaltungen noch sehr schnell.

Wenn das dein Ziel war, dann ist "Simulation" der falsche Begriff.
Sondern du wolltest nur den "UnterSpannung"-Zustand von Schaltungs-Elementen berechnen, ausgehend von ein paar bekannten Elementen.

Da hat dann Async auch nix verloren, und - ja, ein WalkThrough ist schnell.

Eine Simulation wäre genau das Gegenteil von schnell - die hätte ja bei jedem Schritt des Walkthroughs innehalten müssen, und den neuen Zwischenzustand präsentieren.

Niko Ortner · 13. April 2016, 18:17

Ich denke, das kann man problemlos als Simulation bezeichnen.
Ob ein Leitungs-Segment pro Schritt neu berechnet wird, oder viele, sehe ich da jetzt nicht als entscheidenden Faktor.
Das sind die Ergebnisse aufeinanderfolgender Simulationsschritte eines (zugegebemermaßen viel zu aufwändigen) Volladdierers:

Also man sieht schon auch, wie sich Veränderungen "durchhangeln".

ErfinderDesRades · 13. April 2016, 18:26

jo, da wackelt was (das System dahinter ist mir Laien nicht erkenntlich).
ist da jetzt zwischen jeder sichtbaren Veränderung ein kompletter WaklThrough, oder ist das ein einziger WalkThrough , wo du irgendwie ein Innehalten + Anzeige eingebastelt hast?

Niko Ortner · 13. April 2016, 20:45

Ersteres.

Simulation von Digitalen Schaltungen

Simulation von Digitalen Schaltungen

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

Niko Ortner schrieb:

Benutzer online 1

Tags

Ähnliche Themen

6 Benutzer haben hier geschrieben