Archive: 5 posts

---

I have gone to great length to test the latency of the tools provided for circuits in LBP2 and am at a quandary. Here's what has me dumbfounded (or as my wife would say, simply dumb): I created a relay (just a node in a circuit that passes whatever signal, analog or digital through it when activated via the activation switch at the bottom of the microchip). I then hooked 30 of these together in sequence with the output of one going into both the input and activation ports of the next. To the input of the first relay, I hooked up a battery. The last relay's output was hooked to a light bulb. The first relay's activation port was hooked to a switch. The first few times I tested this it took 2 seconds for the bulb to light. However, I just recently went back in and tested again. Now I'm seeing no latency at all (perhaps one frame, but that's inconsequential when you consider there are 30 of these hooked up in series. If one added even a single frame of latency, they each would and the result would be 1 second of latency. I've also seen where some claim that selectors introduce one frame of latency as well, but I've hooked 30 selectors in series and they all flip to the next position in the same simulation pass (1 frame). Subsequent changes to the next position (by using the output of the first to go into the next port in the same selector) does require another simulation pass (1 frame). But that's to be expected. Just set up one selector as described above with 30 ports and send it a single frame pulse. It will take it 1 second to get to the end which you can verify by having the first port start a 2 sec timer and the last port stop the same timer. The timer will be 1/2 full when the circuit completes. Is there anyone here who has thoroughly tested the tools and circuits provided and published the results? I have a timing issue with my memory circuit, and need to know where to look for my latency bug. My test of the relay must be flawed since I'm getting varied results, and any advise will be greatly appreciated

2011-02-08 20:27:00 Author: Shanghaidilly Posts: 153

---

Aya (and others) did a lot of research this, but I think it was posted on the beta forum. The gist of it was that there can be latency on a signal change on the bottom input of a microchip or selector (and maybe others), but you can avoid it by making sure the signal that changes at the bottom is also connected to a left side input. For example, if you take the bottom input of a microchip and wire it to an unconnected node on the chip board, latency should disappear. I can't remember the exact details, but this should at least put you in the right direction.

2011-02-08 22:51:00 Author: Rogar Posts: 2284

---

Aya (and others) did a lot of research this, but I think it was posted on the beta forum. The gist of it was that there can be latency on a signal change on the bottom input of a microchip or selector (and maybe others), but you can avoid it by making sure the signal that changes at the bottom is also connected to a left side input. For example, if you take the bottom input of a microchip and wire it to an unconnected node on the chip board, latency should disappear. I can't remember the exact details, but this should at least put you in the right direction. I'll try that. I did some testing last night and discovered something about microchip activation. The microchip, along with all it's circuitry, is activated in the same clock tick as the activation signal. However, any output is not allowed to "leave" the microchip until the next clock tick. I tested this with two separate microchip. One just contained a node and passed the input through to the output. The second contained a sensor tag. When hit with just one clock tick pulse on the activation switch (meaning the microchip was active for only one clock tick), the relay did not pass on it's signal. However, the one with the tag in it did trigger the tag sensor. In summary, the microchip is active immediately with no latency. The latency is applied only to any output wires from the microchip. I will definitely try your method to see if it fools the simulation into allowing the output to occur on the same clock tick as the activation. Edit: reworded since I was using circuit interchangeably with microchip. Makes more sense now. To rogar: That method cannot be done. The activation switch is an input which allows only one connection. If I wire it to a node on the chip, I have no input to send the activation signal and I can't use the node since it is dead until the microchip is activated (catch 22).

2011-02-09 14:13:00 Author: Shanghaidilly Posts: 153

---

The code is designed to decide the fastest way it can possibly do everything. It's funky in a way that things might not always be evaluated the same way depending on how it is wired. In many cases involving microchips though, latency is just unavoidable.

2011-02-09 14:19:00 Author: Foofles Posts: 2278

---

I've also seen where some claim that selectors introduce one frame of latency as well... Yes, but only when using the Cycle input. I have a timing issue with my memory circuit, and need to know where to look for my latency bug. If you're using a feedback system to store data, that's another place you might get latency. Use a Selector instead. The microchip, along with all it's circuitry, is activated in the same clock tick as the activation signal. However, any output is not allowed to "leave" the microchip until the next clock tick. (I just sent you something similar to this in response to the same question you asked via PM, but perhaps others might be interested...) You have to bear in mind that the microchip is itself a component. There's nothing inherently latent about microchip activation, it's only the component update order that makes it seem that way. Imagine you have a microchip containing a battery and a tag. The battery is connected to a light (outside the chip), and the tag triggers a tag sensor (also outside the chip) which is connected to another light. Now, on the first simulation frame after you activate the chip, the component states are re-evaluted in the following order: microchip, battery, tag, tag sensor (I haven't figured out exactly how the update order is determined, but it's clear in this case the microchip update is occuring before the contents, and it also appears that all tags are always evaluated before tag sensors). So, on frame 1, it first looks at the microchip, and re-evalutes its outputs. Since the battery has not yet been evaluated, it's still disabled, so it determines that the microchip's output is off. Next it looks at the battery, and since the microchip is now active, it determines the battery is now active, and updates the battery's output to on, but (and this is the key point) the microchip output will not go on yet, because each component is only evaluated once per frame, and the microchip's already had its turn for this frame. Then it looks at the tag, and since the microchip is now active, it determines the tag is enabled. Finally it looks at the tag sensor and since the tag is now active, it determines the sensor's output is on (which in turn lights up the attached light). So at the end of frame 1, everything's enabled, except the microchip's output, so only one of the two lights will be on. On frame 2, the re-evaluation process it repeated in the same order. This time the only change is that the microchip's output goes high, so by the end of the frame, both lights will be on. The workaround I specified in my other post merely forces the component update order to be different, perhaps: battery, tag, tag sensor, microchip, so both lights will light on the same frame.

2011-02-10 11:57:00 Author: Aya042 Posts: 2870

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.