Visa read only working after run button press

[RavensFan]

---

@James.M wrote:

---

@RavensFan wrote:

My opinion, and there are others on the forums who will disagree, is that errors should never be fed into a shift register.

---

Personally, I only feed them in to shift registers when I have an error handler at the start of the loop (usually a consumer loop that goes to the error case instead of waiting to dequeue a message). In a state machine type of architecture, like above, the error should just be handled at the end of every loop and wouldn't need to be added to a shift register.

So I think "never" is a little extreme, but I agree that passing all your errors back through your code is never the way to do it.

---

I did say "never".  But then I did go on to describe putting them into the shift register as long as you handle them in the next iteration of a state machine.  I agree with  you that handling the errors at the end of the current state is the better alternative as you now have a context as to what the current state is to better know what to do with the error.

So perhaps while I said that "errors should never", I probably should have worded it "I never put errors".  I put it a little to the strong side, but that is to fight a tendency, or policy, or recommendation that I think I saw in my early LabVIEW training and often see repeated on the forums that errors should always be fed into a shift register.  And without backing up such a statement without some suggestion of how to handle errors is a disservice to novice LabVIEW uses and winds up to code that just stops working properly when an application gets what could be considered an expected error (such as a timeout error on serial communication).

[James.M]

---

@RavensFan wrote:

I did say "never".  But then I did go on to describe putting them into the shift register as long as you handle them in the next iteration of a state machine.

---

So you did. Don't know how I missed that.

Yeah, I remember an "Aha!" moment when I first found out about the right way to handle errors like above. it wasn't ever really emphasized or taught in any of my tutorials and the one other LabVIEW guy I worked with didn't like to share any of his skill with the newbie.

It's weird how NI puts emphasis on proper error handling, but hasn't put much time in to the best techniques. I think the templates they have now (QMH, SSM) are getting better, though, for sure. That might make all the difference for newbies.

[MarkGreally]

Thanks for all the comments guys. As the only person in my office using labview and having only begun to use it a few months ago all the comments and critisisms are really appreciated.

[James.M]

If you're doing a lot of self-teaching and you plan on working with LabVIEW for a while, I highly suggest getting outside input whenever you can. I always learned the most when viewing the code of others, or having others review my code.

There was a point in time where I had an application that I was really proud of, but started having some performance issues. (At the time I didn't really know anything about asynchronous calling or parallelism.) There was a LV instructor (CLA) in town teaching a class, so my boss asked him to come take a look at my code and then gave me the company card to take the guy out to dinner as thanks. He tore my code apart, I learned a ton, and my ego shrank. It turns out, without another LV developer around, it's easy to go off on tangents that seem like good code to you, but are at the cost of another aspect in the end.

User Group Meetings are usually a good way to get to something local.

Developer Days are semi-local and a cheaper alternative to NI Week.

If you get certified, there are CLD Summits and CLA Summits that are an awesome way to exchange ideas with others.

NI Week is expensive, but a lot of fun and a lot of information. It's mostly sales (with some classes), but is a great way to grow your network.

[MarkGreally]

I agree. But I even learn a lot on the forums. I might register for some of the seminars which may be useful and dont cost anything.

[billko]

---

@James.M wrote:

---

@RavensFan wrote:

I did say "never".  But then I did go on to describe putting them into the shift register as long as you handle them in the next iteration of a state machine.

---

So you did. Don't know how I missed that.

Yeah, I remember an "Aha!" moment when I first found out about the right way to handle errors like above. it wasn't ever really emphasized or taught in any of my tutorials and the one other LabVIEW guy I worked with didn't like to share any of his skill with the newbie.

It's weird how NI puts emphasis on proper error handling, but hasn't put much time in to the best techniques. I think the templates they have now (QMH, SSM) are getting better, though, for sure. That might make all the difference for newbies.

---

I think emphasis was placed in putting the error cluster into a shift register so you don't ever swallow the error.  However, with good error handling techniques, you won't ever have an error at the output tunnel.  (You should always have a strategy to handle unexpected errors.  Those are the ones that will bite you.)  So for me, it generally doesn't matter if it's in a shift register or not.  Unless it's a FOR loop.  Then everything with an input and output goes in a shift register.

[JÞB]

---

@James.M wrote:

If you're doing a lot of self-teaching and you plan on working with LabVIEW for a while, I highly suggest getting outside input whenever you can. I always learned the most when viewing the code of others, or having others review my code.

There was a point in time where I had an application that I was really proud of, but started having some performance issues. (At the time I didn't really know anything about asynchronous calling or parallelism.) There was a LV instructor (CLA) in town teaching a class, so my boss asked him to come take a look at my code and then gave me the company card to take the guy out to dinner as thanks. He tore my code apart, I learned a ton, and my ego shrank. It turns out, without another LV developer around, it's easy to go off on tangents that seem like good code to you, but are at the cost of another aspect in the end.

User Group Meetings are usually a good way to get to something local.

Developer Days are semi-local and a cheaper alternative to NI Week.

If you get certified, there are CLD Summits and CLA Summits that are an awesome way to exchange ideas with others.

NI Week is expensive, but a lot of fun and a lot of information. It's mostly sales (with some classes), but is a great way to grow your network.

---

I could not agree more!  

I spend a lot of time "Lone Wolf" coding.  This can cause endless frustrations learning all the mistakes you can make with LabVIEW and you can spend a lot of time reinventing the wheel.  Learn all you can about software design patterns....and more importantly anit-patterns! learning to sniff out "Code Smell" is the first step to becoming effecitve in developing solutions for your clients.

<Story>

I inherited some code for a client when the developer transfered to another department at that client.  Wonderful code that ran a nice little SCADA system except for some huge gaps in both LabVIEW Knowledge and Software design.  The biggest mistake was failing to get the "User's Story."  The main UI had 14 Tabs filled with debug and setup information.  The user wanted some set-up options and a simple status display:O.  It was a complete rewrite.  The original developer did come in for a tour when the system was completed-  I believe he then availed himself of the self paced online training.  

</Story>

The Forums, NI Community, On-line Training, LUG Meetings, Dev Days, NI Days and NI Week are invaluable to the "Cowboy Coder."  And, do look for those local NI Alliace Partners and Certified LabVIEW Consultants!  Most of us really would love to look at your code and give you some feedback!