Waiting for existance of file to proceed

[BertMcMahan]

---

@Jim12345678 wrote:

Aha! You noticed!

I've been programming in LabVIEW for 22 years and I get no end of grief for my approach, but it lets me do things that would simply be impossible if I followed convention.

---

Dunno about the other guys but I'm curious to see some examples.

[mcduff]

---

@BertMcMahan wrote:

---

@Jim12345678 wrote:

Aha! You noticed!

I've been programming in LabVIEW for 22 years and I get no end of grief for my approach, but it lets me do things that would simply be impossible if I followed convention.

---

Dunno about the other guys but I'm curious to see some examples.

---

+1

[altenbach]

---

@Jim12345678 wrote:

... but it lets me do things that would simply be impossible if I followed convention.

---

You only need to break convention in the 0.001% of cases it's needed. 😄 (... and this would still be following convention 🐵

[Jim12345678]

See attached.  I consider this to be an extremely simple program.  I expect to be told how horrible it is.  It works.  It's clear.  It's easily expandable.  I have 64 GB of memory. I don't care if I'm wasting a few kilo bytes here or there.  It has to operate at human acceptable speeds. The user is biologically incapable of perceiving the difference between 1 and 1.1 milliseconds. Saving a few milliseconds in execution time isn't worth distilling the code down into some more "efficient" but utterly unintelligible nugget of crossed wires and shift registers.   20 years ago I would have done that.  I've learned not to.

[Frozen]

That is a very interesting non-conventional coding style.

IMHO, this coding style makes the sub-vi's overly complicated and much harder to read... but hey, at least you are consistent! I find the code posted by GerdW for the wait on file vi *much* more readable than the original. Same type of clean-up could make ALL the sub-vi's more readable.

However, I cannot see how this style is able to "do things that would simply be impossible if I followed convention"

[johntrich1971]

---

@Frozen wrote:

That is a very interesting non-conventional coding style.

IMHO, this coding style makes the sub-vi's overly complicated and much harder to read... but hey, at least you are consistent! I find the code posted by GerdW for the wait on file vi *much* more readable than the original. Same type of clean-up could make ALL the sub-vi's more readable.

However, I cannot see how this style is able to "do things that would simply be impossible if I followed convention"

---

I agree with this. Why reinvent the wheel (queue)? What are you doing with this coding style that would be impossible if you followed convention? This program could be rewritten quickly following convention and be much more readable, maintainable, and less likely to break in the future.

[Kevin_Price]

Quote corrected in place (edits in red):

---

I've been programming in LabVIEW for 22 years and I get no end of grief for my approach, but it lets me do things that would simply be impossible for me if I followed convention.

---

I'm not trying to pile on, honestly.  I think both the quoted poster and we responders can benefit by taking a moment to reflect on that edit.

What I see in the code is structured problem solving that seems to be rooted in a resistance to LabVIEW's core principle of dataflow.  You haven't focused on filling your toolbox with a lot of fancy tools but have instead focused on getting jobs done with the tools you have.  And there's definitely value in that.  

But what I'd gently suggest is that this focus may also have been self-limiting.  Like the old phrase, "if all you have is a hammer, every problem looks like a nail."

I've been doing LabVIEW for right around 22 years myself, and for about the first 15 I very rarely worked alongside any LabVIEW colleagues.  I got into DAQ hardware in some depth while learning LabVIEW software conventions much more slowly and incrementally.  It was a lot of years before I heard of the concept of a "state machine", longer before I knew why I should care, and even longer before I felt like I could *think* about an application in terms of a state machine.

It takes time, it takes intentional effort, but there really *is* a payoff for learning various conventional techniques.  It isn't just that you have more tools available for the solution, it's that those tools let you *think* about the problem from different angles.

It's good that you're solving problems and it's good that you've established a consistent structure.  It can *also* be good to expand your horizons...

-Kevin P