My D-latch won't work. I've been troubleshooting for a while; anyone have any ideas?

[twillocks]

I cannot get it to switch to Q'. Any help would be greatly appreciated.

[LandBelenky]

change your feedback node to Globally Initilize on Compile or Load.

The way you have it now, it initilizes with False every time, therefore NAND is always true and Q' is always on.

surely there must be a better way to do this.

[twillocks]

I'm sorry; I've just realized that I wasn't very clear. It initializes with Q' on, but when it switches to Q, I cannot switch it back. I did try changing the feedback node to Globally Initilize on Compile or Load, but it still won't switch back properly. The only way it will switch back is if I select enable by itself.

[LandBelenky]

there appears to be a difference between using Run and Run Continuously.

Here's my version.  I think it does what you want.  I used a local variable instead of a feedback node because I can't really tell when that feedback mode gets initilized.

[altenbach]

---

@LandBelenky wrote:

there appears to be a difference between using Run and Run Continuously.

---

Yes, the right way is to put a while loop around it (also containing a small wait).

[nathand]

Run Continuously is rarely if ever a good idea (in a decade of LabVIEW development, I've never used it).  Generally if I want to test a subVI that I intend to run in a loop, I create a new temporary VI with a while loop (and a timing node) that calls the subVI.  Run continuously is like hitting the "Run" button over and over again, so if you have a node that initializes only on the first call, it will get reinitialized on every execution because every execution is treated as the first call.

Local variables are also usually a bad idea - in this case, you're setting up a potential race condition.  A properly initialized feedback node would be better.

[LandBelenky · Accepted solution]

Actually, in this case, Run Continuously is not the same as hitting the Run button over and over again.

If you take the VI from the first post, change the feedback initilization to 'On Compile or Load' , you will see different behavior if you use Run or Run Continuously. 

That difference alone is enough to convince me never to use a feedback node except inside a loop.  In that case, I always use a shift register.

In my solution in #4, I don't see how there can be a race condition.  The output at Q depends directly on the input.  It's sequential, so it cannot appear out of order, and there is no intervening code or any other method to change the value of Q, so it doesn't race.

Nevertheless, here's an even easier solution:

[nathand]

---

LandBelenky wrote:

In my solution in #4, I don't see how there can be a race condition.  The output at Q depends directly on the input.  It's sequential, so it cannot appear out of order, and there is no intervening code or any other method to change the value of Q, so it doesn't race.

---

Sorry, for some reason when I wrote that I had a momentary lapse of thinking that Q was a control, not an indicator, thus the race condition comment (if you were to click it while it was running).  You don't have a race condition there, but a local variable still isn't an ideal solution.

[twillocks]

Thanks alot for the help; I figured it out.

[altenbach]

Is there a valid reason for all that whitespace in your image? The useful parts could fit the size of a postage stamp. 😞