Visa read only working after run button press

[RavensFan · Accepted solution]

The default datatypes for all of them.

That means "NO ERROR" for the error type.  The reason it runs fine at initial startup is that the uninitialized shift register will have the default datatypes.  If you run the VI, then have an error in that shift register when it stops, that error will remain in teh shift registers the next time you start it.  Not until you close it out and restart, or do some change to the program that causes it to recompile and wipe its memory slate clean, will it restart without the error.

So if you initialize that shift register with the default datatype, then you will never have a problem on any start of the program.

Then you can concentrate on fixing whatever problems are causing the error during the operation of the program.

[crossrulz · Accepted solution]

1.  You generally want 1 error cluster path.

2.  The error values stored in shift registers should generally be initialized to No Error (False, 0, empty string).

3. The resource references should generally be initialized to blank.  Your initialize case populates them.

4.  It would help your readability a lot if you used Unbundle By Name and Bundle By Name.

[MarkGreally]

I have initialised the registers but has not fixed the problem

I am getting a framing error. -1073807253

The following advises initialisation as a possible problem which was my work around originally

http://digital.ni.com/public.nsf/websearch/F3E0621CB71AA16786256F970000FC57?OpenDocument

Where is this coming from the second time round. Is there some junk left in the buffer perhaps??

[RavensFan]

Initialization of the shfit registers fixes the problem when your code won't restart without an error.

You still have to fix the problem as to why your code is getting the error in the first place.

Framing error generally implies that either your serial port configuration doesn't match in terms of start, stop bits, parity.  Or you are getting excessive electrical noise.

[MarkGreally]

Its deffinately not a physical problem. I can see the data on terminal software exactly how it is supposed to be. Its deffinately something to do with the program. By going back to the "init" state each time sorts it out but the whole purpose of initialisation is to do it once at the beginning. When it goes from "qr code" or "write to spreadsheet" to "wait for start" (which is waiting for the user to press buttons) it is somehow losing the configuration.

[James.M]

Use the LabVIEW Probe debugging tool to figure out where the connecton or information is lost. You can probe the wires to make sure everything is handled correctly.

After looking at the code some more, I want to re-state what I said above that you reaaally should switch to Unbundle by Name and Bundle by Name You're running all those wires through each case and each event structure case too, which results in the mess that you have there. It's easy to mismatch wires when they're all run like that without names.

[MarkGreally]

I replaced bundles with bundle by name and it has indeed cleaned things up. The source of the error  ( -1073807298) is on the error out of visa read in the "mac address" state (no surprises there). When I disable this connection so the error is not fed back into the cluster and shift register everything works as it should. This seems like bad practice as everything should be connected, but ignoring this error does work. What is the best approach to handling errors and clearing them, or preventing them from coming in the first place??

[RavensFan]

My opinion, and there are others on the forums who will disagree, is that errors should never be fed into a shift register.  It invites the problem you are having where some odd error basically breaks your application from there forward.  Errors within serial communication, while you don't really want them, can be expected to happen for any number of reasons.  Suppose someone accidentally disconnects a cable and it raises timeout errors.  You want your code to be able to recover from that when they plug it back in.

Of course you don't want to outrigth ignore the errors, because they may be telling you something important.

If you feed the errors into a shift register, then you should have a state in your program that immediately follows that looks at the error, displays it, or logs it, or something, and then proceeds to do something to try to fix it if possible.

[MarkGreally]

Interesting thoughts. I actually just checked earlier versions and the error code is there, i just wasn't looking for it and didnt feed it into the registers. The application was being used in ignorance. I'm not sure why its giving this error. It could be to do with the fact that I am only using the Rx line of the FTDI cable and maybe labview is looking for the others. It is however working as I want so I wont be ringing the alarm bells just yet.

[James.M]

---

@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.

MarkGreally,

I think this thread solved the issue you were having with "only working after run button press" because we traced it back to a shift register issue. I would suggest marking solutions on the thread related to that and then we can move on to your instrument error. I usually suggest starting a new thread if the new topic is a separate problem. This helps others solve their problems in the future because it's a pain to dig through an unrelated thread.