Error -1073807339

[trinityghost1]

Wow, just that easy, huh? Lol. Works like a charm now.

I knew it had SOMETHING to do with the error from the PS, because if you just run them in parallel instead of serial (without the error wire connected) then it'd run just fine, but as soon as you connected them it would throw the time out error. I'd love to know why specifically (from what you've been saying, it sounds like it's something along the lines of the PS being super old/outdated and too slow which leads to the time out on the DMM). Interesting how this whole time I was thinking the DMM was the problem because of its Read.VI, but the problem has been the PS all along I believe. Also, I already knew about quick search and use it all the time since learning about it in Core 1, but I appreciate the heads up and maybe some other people lurking might benefit from it being mentioned.

So, on to the questions: Is there any way to know more specifically what the error is that's coming from the PS that is causing the DMM to time out? Is it actually okay to just "clean" the error in this way, considering potential future applications in a professional setting? Cool if so, but it almost seems like a cheat, lol. Is there anything more I should know about this new tool of "Clean Errors" I now have in my back pocket, like when I should (and especially SHOULDN'T) use it in the future? I'm also curious about all of this "PS warning is also related to timing so it may just be our fast PCs are the cause" stuff. Can you elaborate on this and how you know it in more detail, and/or direct me to some resources where I might learn more about timings and speeds of both equipment and computers and how they interact with each other like in this problem? Basically I'm thinking about future problems down the road and how I might troubleshoot them, like if there are more specific ways to figure out timing problems, like if there is a variable for some kind of data transfer rate in the PS or something like that, maybe in the manual or something. Like, how would I know something is a timing issue (like with adding delays), or if my fast PC is causing the issue, in a future problem? Is there something I should commonly check where I could be like, "oh yeah, that looks like a timing issue. You can tell by looking at this variable over here, and you can check how fast your PC is over here and see how different the numbers are," you know what I mean? Also I'm a bit new to probing (I've done it a bit, but I haven't really used it to troubleshoot anything yet), could you elaborate on how I can use it here to figure out how long of a delay is needed? Sorry if I'm asking too many questions here lol, I realize it's like I'm writing a novel here but I figure I might as well use this opportunity to learn as much as possible since this problem seems to be coming to a close if the Clear Errors VI is a perfectly fine solution for this.

After reading you guys talking fondly about the Magic Delay Fairy mod, I'll definitely have to give it a shot 😁. Anyways, thank you everyone for all of your help! My original plan was to write this program in a for loop and have the PS generate random voltages which the DMM would read and output to an array, so when I get around to coding that I'll upload it to this thread too (hopefully there are no other problems 😂)

[trinityghost1]

Also, some more questions now that I've started playing with it more: do I even need the delay? It seems to work just fine without it for me once the error is cleared. Even if I don't need the delay in the original program, should I still use one for the For Loop? How do you determine how long a delay should be in any given LabVIEW program? I'm still pretty clueless about delays in LabVIEW besides knowing they affect CPU usage, but even then I'm not exactly sure how you figure out the exact number you should set for a delay in any given situation.

[Frozen]

---

@trinityghost1 wrote:

Also, some more questions now that I've started playing with it more: do I even need the delay?

---

In case you have not picked up on it (tough to do in text) the whole "magic delay fair" is a joke! If you need a delay to make your instruments work, then you are programming it wrong (you program or the instrument).

So, no, you do not need the delay...  you need to correct your program, or instrument drivers.

[trinityghost1]

Yeah I figured it was a bit tongue-in-cheek, but with the link given to the VIPM mod (https://www.vipm.io/package/jki_magic_delay_fairy/) I thought it might actually be a real thing, lol! Thanks for the heads-up, regardless. I'm still interested in understanding the do's and don'ts about using delays though, like how you generally decide when to use them and how long the delays should be for.

edit: I think I may have misread you earlier, Frozen. Are you saying you NEVER use delays in any of your programs? I know at least in Core 1 they talked about how it can be important for managing the CPU's resources, but are you saying even then you don't bother? Could you elaborate on this further at all? Again, I'm still a beginner in LabVIEW so I greatly appreciate whatever you guys can teach me. It's very useful to me to hear what sort of standard and practices you all have with your programming, and more important why you do things the way that you do.

[NIquist]

You don't believe in the Magic Delay Fairy???  Unfortunately, I just re-installed it, and it does not seem to work anymore.  The block diagram window re-sizes but no animated fairy or random delays.

It IS a real thing though...  Maybe if I wish real hard...  or click my heels three times...   or reboot...   🤔

[trinityghost1]

I'll have to use that in the future with my LabVIEW-inclined co-workers! 🤣

Also I finished the for loop version, figured I'd post it, mark NIquist's post on the Clear Errors VI as the solution, and call it a wrap on this problem (although if you can get around to answering my wall of text of questions from earlier at some point, I'd greatly appreciate it 😁). Amazing how fast you can complete programs when you don't have weird random errors that mess everything up, eh? 😂

[GovBob]

Judging from message #18 you are getting a warning vs. an error from the power supply. The boolean in the error cluster is different. Maybe the DMM's driver is not tolerant of any numerical coming in on the error cluster input? I don't have that DMM to check. 

[NIquist]

In an ideal LabVIEW world, you would only use a delay when you explicitly want your program to pause for some time.  The 100% CPU usage being fixed with a Wait.vi throttle for example.  As your architectures get more complex you will find better solutions like a timed loop, or the timeout case in the event structure, but for simple, quick code using a delay to wait for a slow hardware interface isn't a bad thing.  You will get into trouble when you use it as a crutch though.  If you are waiting for a response from some hardware that takes 100mS before it's available, you could add a 200mS delay.  But what happens if another command takes 250mS to respond?  Soon you are chasing your tail.  A better way is let low-level VISA drivers read the interface until it receives a termination character and then sets a DATA READY flag informing you it's done.  It all depends on the hardware you're dealing with as you've seen with these old power supplies.  

Instead of worrying about delays I would suggest you focus on dataflow, error handling and learn some simple but VERY useful templates like the state machine, producer-consumer and queued message handler.  There are start-up templates in the Create New Project option and plenty of tutorials on-line.  Also, look through the Example Finder and find some VIs that interest you and modify them (copy them locally first) to add features and learn to use your probes and debugging tools.

[crossrulz]

---

@trinityghost1 wrote:

Yeah I figured it was a bit tongue-in-cheek, but with the link given to the VIPM mod (https://www.vipm.io/package/jki_magic_delay_fairy/) I thought it might actually be a real thing, lol!

---

Hint:  Look at the release date (April 1, 2015).  Back in the day, JKI and NI would have April Fool's "press releases".  The Magic Delay Fairy was one of those from JKI.  The real classic one is the JKI Wire-Nut Toolkit.

As far as delays are involved, I find myself using them less and less over the years.  I've learned that 99% of my instrument drivers do not actually need them.  I sometimes need delays due to waiting for a UUT to respond to something before performing a measurement..

[Frozen]

---

@trinityghost1 wrote:

Are you saying you NEVER use delays in any of your programs? I know at least in Core 1 they talked about how it can be important for managing the CPU's resources, but are you saying even then you don't bother? Could you elaborate on this further at all?

---

In a perfect world, a well behaved and well written instrument drivers should not need a wait, ever. I highly recommend working at removing any hard-coded waits in any instrument communication as it will inevitably come back to bite you. For example, triggering a oscilloscope sweep (any instrument) and waiting until the operation-is-complete  before requesting the data from the instrument. A hard-coded wait will work until you change one of the scope parameters (like number of averages). Better way would be to ask the instrument if it is done capturing the data with an *OPC? command.

On the other hand, an un-throttled while or for loop should always have a wait to release control back to the CPU so it can do other things.

Of course using an event structure (in this particular case) so you are not polling at all, would even be better.

Hope this clears things up.