模拟简单的电路 [英] Simulating simple electric circuits
问题描述
大家好，
我正在尝试模拟简单的电逻辑（异步）
电路。通过简单我的意思是我只想知道我是否有b $ b有当前字样。或没有当前或（这是非常数字的）并且唯一的
元素需要（对我的特定
问题有一定程度的抽象）
- 来源（这里开始潮流）
- 地面（这里是结束潮流）
- 关节
- 开关（能够让电流通过与否，取决于
外部影响）
- 负载（可以指示电流流向外部的变化 -
就像一个灯泡）
有没有这个库？我找不到一个。
我尝试使用双向链接的对象来实现它;
每个对象都有ports。对于每个端口，都有
- 输入功能（如果当前
进来，则由邻居调用）
- 对邻居的输入功能的引用，能够让
电流以其他方式流动
有一个主人 ;电流控制器告诉
的对象是来源反对开始当前的对象通过呼叫它的邻居。
呼叫通过网络，直到它们到达地面。对象。
具体来说，来源传递电报。这些
调用的实例，以及它通过的所有人寄存器自己用它
（电报在关节处重复）。然后，地面物体用所有收到的电报将
调回控制器。就像这样，我已经能够通过网络获得所有可能的方式。
但这就是我的想法消失的地方。让我们假设在这样的电流中间有一个负载
，e。 G。一个灯泡。因此，如果当前
流过它，就会注意到这一点，因为有一封电报
通过它。但如果现在之前的联系人切断怎么办呢？
当前，我怎么能通知切割后面的所有对象？过去几天我尝试了几种方式，但都会导致令人困惑的（以及
非工作）代码。 （对不起，我还不能提供任何正常工作的代码）
通常可以归结为需要检查
整个网络中的所有可能方式每一个变化。对于我来说，这不应该对我来说是一个很大的问题，但感觉很脏，而且我觉得b $ b气味不一致。
我想到的另一种方式是
- 让装载对象有一个计时器，将其状态重置为no
flow ;大约200毫秒后
- 脉冲网络每隔约100毫秒从所有来源到地面
- 并在途中重置所有加载计时器。
这感觉更脏。
有几种专业级的仿真工具可以追踪很多其他参数，它们一般是如何工作的，是否有不同的
不同战略？我想知道我是不是太复杂了，或者我是否会看到问题，而实际上并没有。我也看了一下
NetworkX，但是我看不出它是如何使用的。我很感激
所有建议。
感谢您的考虑。
问候，
Bj？rn
PS：这不是作业，这是纯粹的爱好;）
-
BOFH借口＃70：
嵌套蟑螂将以太网电缆短路
5月7日下午7:05，Bjoern Schliessmann< usenet-
mail-0306.20.chr0n ... @ spamgourmet.comwrote：
大家好，
我正在尝试模拟简单的电逻辑（异步）
电路。通过简单我的意思是我只想知道我是否有b $ b有当前字样。或没有当前或（这是非常数字的）并且唯一的
元素需要（对我的特定
问题有一定程度的抽象）
- 来源（这里开始潮流）
- 地面（这里是结束潮流）
- 关节
- 开关（能够让电流通过与否，取决于
外部影响）
- 负载（可以指示电流流向外部的变化 -
就像一个灯泡）
有没有这个库？我找不到一个。
我尝试使用双向链接的对象来实现它;
每个对象都有ports。对于每个端口，都有
- 输入功能（如果当前
进来，则由邻居调用）
- 对邻居的输入功能的引用，能够让
电流以其他方式流动
有一个主人 ;电流控制器告诉
的对象是来源反对开始当前的对象通过呼叫它的邻居。
呼叫通过网络，直到它们到达地面。对象。
具体来说，来源传递电报。这些
调用的实例，以及它通过的所有人寄存器自己用它
（电报在关节处重复）。然后，地面物体用所有收到的电报将
调回控制器。像这样，我已经能够通过网络获得所有可能的方式。
然后你可以获得所有依赖于一个或多个
开关的潜在路径。当且仅当所有这些开关都打开时，每条路径都可以知道它依赖于什么开关
并且活跃。每个
开关都会知道哪些路径依赖它。同样地，如果至少有一条路径
有效，那么每个灯泡
将知道它依赖的路径并且开启。并且每条路径都会知道它所支撑的灯泡
但这就是我的想法消失的地方。让我们假设在这样的电流中间有一个负载
，e。 G。一个灯泡。因此，如果当前
流过它，就会注意到这一点，因为有一封电报
通过它。但如果现在之前的联系人切断怎么办呢？
当前，我怎么能通知切割后面的所有对象？过去几天我尝试了几种方式，但都会导致令人困惑的（以及
非工作）代码。 （对不起，我还不能提供任何正常工作的代码）
通常可以归结为需要检查
整个网络中的所有可能方式每一个变化。对于我来说，这不应该对我来说是一个很大的问题，但感觉很脏，而且我觉得b $ b b气味不一致。
关闭开关时，它会向
依赖它的路径发送消息（可能是通过控制器？）这样他们就会停用
。反过来，这些路径上的灯泡将被通知
它们不再有效。
当您打开开关时，它会发送信息给
的路径依赖于它，以便那些没有另一个关闭开关的人将被激活
。反过来，这些路径上的灯泡会被通知
他们有一个新的电源。
在我看来它会很好用的方式你开始了吗？b
out，但我可能误解了某些方面或忽略了一些问题;）
-
Arnaud
Arnaud Delobelle写道：
5月7日，下午7:05，Bjoern Schliessmann< usenet-
>有一个主当前控制器告诉
来源的对象反对开始当前的对象通过呼叫它的邻居。呼叫遍历网络，直到它们到达地面。宾语。具体地，源通过这些呼叫的电报实例，并且每个人通过
寄存器。自己用它（电报在关节处复制）。
然后，地面物体用所有收到的电报回叫控制器。像这样我已经能够通过网络获得所有可能的方式。
然后你可以得到所有依赖于一个或多个
开关的潜在路径。当且仅当所有这些开关都打开时，每条路径都可以知道它所依赖的开关是什么，并且是活跃的。并且
每个交换机都知道哪些路径依赖于它。同样地，每个
灯泡会知道它依赖的路径，并且如果在
，则至少有一条路径处于活动状态。并且每条路径都会知道它的功率是多少
灯泡
原则上，我也这么认为，但我不喜欢这个事实这个
涉及所有可能的电路只能确定一次。但是它好像没有合理的，不同的方式。
当你关闭一个开关时，它会向你发送一条消息。路径
依赖它（可能是通过控制器？）这样他们就可以停用
了。反过来，这些路径上的灯泡将被告知它们不再有效。
当你打开一个开关时，它会发送一条消息给路径
依赖于它，以便那些没有另一个关闭开关
的人将被激活。反过来，这些路径上的灯泡将被告知他们有一个新的电源。
是的。看起来我必须做扩展的簿记。为了这。我是
寻找一种更有活力，更通用的方式。
在我看来它可以很好地适应你的启动方式
out，但我可能误解了某些方面或忽略了一些
问题;）
感谢您的支持输入。我到目前为止遇到的最大问题是用于互连的
crummy接口，这很快就会让人感到不安。
我看过NetworkX教程，看起来好像这样
可以简化代码。
问候，
Bj？
-
BOFH借口＃173：
循环挂载点的递归遍历
" Bjoern Schliessmann" < us ************************** @ spamgourmet.comwro te
消息新闻中的
：5a *** ********** @ mid.individual.net ...
大家好，
|我正在尝试模拟简单的电逻辑（异步）电路。
[snip]
有些网络模拟器除节点对象外还使用连接对象，
连接已连接到节点但彼此类型不同。但是
我认为这不适用于此。
另一个''技巧''是单向连接所有连接，所以双向连接
是一对相反的单向连接。这可能会更容易
跟踪正在打开（或关闭）的内容。
tjr
Hello all,
I''m trying to simulate simple electric logic (asynchronous)
circuits. By "simple" I mean that I only want to know if I
have "current" or "no current" (it''s quite digital) and the only
elements need to be (with some level of abstraction to my specific
problem)
- sources (here begin currents)
- ground (here end currents)
- joints
- switches (which are able to let current pass or not, depending on
outside influence)
- loads (which can signal change in current flow to the outside --
just like a light bulb)
Is there any library for this? I couldn''t find one.
I tried to implement this using objects that are two-way linked;
every object has "ports". For every port, there is
- an input function (that is called by the neighbour if "current"
comes in)
- a reference to the neighbour''s input function, to be able to let
current flow the other way
There is a master "current controller" object which tells
the "source" object to start a "current" by calling its neighbour.
The calls traverse the network until they reach a "ground" object.
Specifically, the source passes a "telegram" instance with these
calls, and everyone it passes through "registers" himself with it
(telegrams are duplicated at joints). Then, the ground object calls
back to the controller with all received telegrams. Like this I''m
already able to get all possible ways through the network.
But that''s where my ideas go out. Let''s assume there is a load in
the middle of such a current, e. g. a light bulb. So if the current
flows through it it gets notice of this because there is a telegram
passing through it. But what if a contact before it now "cuts" the
current, how could I notify all objects behind the cut? I tried
several ways the past few days, but all lead to confusing (and
non-working) code. (I''m sorry I can''t provide any working code yet)
Often it boils down to the need to check all possible ways in the
entire network with every change. This shouldn''t, in perfomance
terms, be a big problem for me here, but it feels very dirty, and I
smell inconsistencies.
Another way I thought of is
- to let load objects have a timer that resets their state to "no
flow" after ~ 200 ms
- "pulse" the network every ~ 100 ms from all sources to ground
- and reset all load timers on the way.
This feels even more dirty.
There are several professional-grade simulation tools that track
many other parameters, how do they work in general, is there a
different strategy? I wonder if I''m making it too complicated or if
I''m seeing problems where there really aren''t any. I also looked at
NetworkX, but I can''t see how it might be of use yet. I appreciate
all suggestions.
Thanks for you consideration.
Regards,
Bj?rn
P.S.: This is no homework, it''s pure hobby ;)
--
BOFH excuse #70:
nesting roaches shorted out the ether cable
On May 7, 7:05 pm, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n...@spamgourmet.comwrote:Hello all,
I''m trying to simulate simple electric logic (asynchronous)
circuits. By "simple" I mean that I only want to know if I
have "current" or "no current" (it''s quite digital) and the only
elements need to be (with some level of abstraction to my specific
problem)
- sources (here begin currents)
- ground (here end currents)
- joints
- switches (which are able to let current pass or not, depending on
outside influence)
- loads (which can signal change in current flow to the outside --
just like a light bulb)
Is there any library for this? I couldn''t find one.
I tried to implement this using objects that are two-way linked;
every object has "ports". For every port, there is
- an input function (that is called by the neighbour if "current"
comes in)
- a reference to the neighbour''s input function, to be able to let
current flow the other way
There is a master "current controller" object which tells
the "source" object to start a "current" by calling its neighbour.
The calls traverse the network until they reach a "ground" object.
Specifically, the source passes a "telegram" instance with these
calls, and everyone it passes through "registers" himself with it
(telegrams are duplicated at joints). Then, the ground object calls
back to the controller with all received telegrams. Like this I''m
already able to get all possible ways through the network.Then you can get all ''potential'' paths that depend on one or more
switches being on. Each path could know what switches it depends on
and be ''active'' if and only if all those switches are on. And each
switch would know what paths depend on it. Similarly each lightbulb
would know what paths it depends on and be ''on'' if at least one path
is active; and each path would know which lightbulbs it powers
But that''s where my ideas go out. Let''s assume there is a load in
the middle of such a current, e. g. a light bulb. So if the current
flows through it it gets notice of this because there is a telegram
passing through it. But what if a contact before it now "cuts" the
current, how could I notify all objects behind the cut? I tried
several ways the past few days, but all lead to confusing (and
non-working) code. (I''m sorry I can''t provide any working code yet)
Often it boils down to the need to check all possible ways in the
entire network with every change. This shouldn''t, in perfomance
terms, be a big problem for me here, but it feels very dirty, and I
smell inconsistencies.When you turn a switch off, it would send a message to the paths that
depend on it (maybe via the controller?) so that they would be
deactivated. In turn the lightbulbs on these paths would be informed
that they are no longer active.
When you turn a switch on, it would send a message to the paths that
depend on it so that those who do not have another off switch would be
activated. In turn the lightbulbs on these paths would be informed
that they have a new power source.
It seems to me that it would work well with the way you started it
out, but I may have misunderstood some aspects or overlooked some
problems ;)
--
Arnaud
Arnaud Delobelle wrote:On May 7, 7:05 pm, Bjoern Schliessmann <usenet-
>There is a master "current controller" object which tells
the "source" object to start a "current" by calling its
neighbour. The calls traverse the network until they reach a
"ground" object. Specifically, the source passes a "telegram"
instance with these calls, and everyone it passes through
"registers" himself with it (telegrams are duplicated at joints).
Then, the ground object calls back to the controller with all
received telegrams. Like this I''m already able to get all
possible ways through the network.
Then you can get all ''potential'' paths that depend on one or more
switches being on. Each path could know what switches it depends
on and be ''active'' if and only if all those switches are on. And
each switch would know what paths depend on it. Similarly each
lightbulb would know what paths it depends on and be ''on'' if at
least one path is active; and each path would know which
lightbulbs it powersIn principle, I thought so too, but I didn''t like the fact that this
involves all possible circuits be determined only once. But it
seems like there is no reasonable, different way.
When you turn a switch off, it would send a message to the paths
that depend on it (maybe via the controller?) so that they would
be deactivated. In turn the lightbulbs on these paths would be
informed that they are no longer active.
When you turn a switch on, it would send a message to the paths
that depend on it so that those who do not have another off switch
would be activated. In turn the lightbulbs on these paths would
be informed that they have a new power source.Yep. Looks like I have to do extended "bookkeeping" for this. I was
looking for a more dynamic, general way.
It seems to me that it would work well with the way you started it
out, but I may have misunderstood some aspects or overlooked some
problems ;)Thanks for your input. The biggest problem I got until now are the
crummy interfaces for interconnection which quickly get inconcise.
I''ve had a look at the NetworkX tutorial and it seems like this
could simplify the code a bit.
Regards,
Bj?rn
--
BOFH excuse #173:
Recursive traversal of loopback mount points
"Bjoern Schliessmann" <us**************************@spamgourmet.comwro te
in message news:5a*************@mid.individual.net...
Hello all,
| I''m trying to simulate simple electric logic (asynchronous)circuits.
[snip]
Some network simulators use connection objects in addition to node objects,
with connections joined to nodes but not the same type to each other. But
I do not see this as applying here.
Another ''trick'' is to make all connections one-way, so a two-way connection
is a pair of opposite one-way connections. This might make it easier to
keep track of what is turning on (or off) what.
tjr
这篇关于模拟简单的电路的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
