Visa read only working after run button press

[MarkGreally]

Hi Folks.

I have a weird problem here. When I run the vi and press the start button the serial port is read and the rest of the program runs fine. When it is finished and redo it there is no serial data. I must abort  and re-run, then when I press the start button the serial data is there. Is the end of the program somehow putting the serial port to an unknown state??

Thanks,

Mark.

[JÞB · Accepted solution]

You are most likely getting an error from one of your devices.  and, since you don't initiallize the shift register with the cluster of IO Sessions and Errors the SR will retain the error while the vi is in memory unless you Abort the execution (at which point the Shift Register will contain the default).  Find the error

[Bob_Schor · Accepted solution]

Some questions and comments:

• What do you mean by "When it is finished and redo"?  Does this mean the program exits and stops running, then you restart it?  Are you working with an Executable or are you running in Development Mode?
• What do you mean by "I must abort" -- what, specifically, are you doing to "abort"?  Are you stopping and restarting LabVIEW, logging off and logging back on, rebooting the PC?
• I notice that you close the two VISA ports when the program exits, but don't do anything to the Instrument port (the last one) -- shouldn't this be closed?
• It is extremely difficult to figure out what you are trying to do -- my monitor is 1280 x 1024, and your Block Diagram is 3 x 2 "screens" (and I don't have a 6-screen setup).
• Suggest "encapsulating" code in sub-VIs.  For example, reading the .ini file can all be done in a sub-VI, with the results output in a single Cluster.
• Try to avoid Local Variables!!!  They make your code harder to understand, harder to debug, harder to maintain.
• Try to use the Error Line "consistently".  It deserves its own Shift Register.
• You do not need a Sequence Structure in the Init case (you almost never need a Sequence Structure) -- simply put everything on the Error Line and it should work fine.

If you follow (some of) these suggestions, you may well end up with a dozen (or, even better from a maintenance point of view with a moderately-complex Project, hundreds) of VIs.  LabVIEW Project (and a sensible use of Folders) is your friend here -- my preference is to keep Types and Sub-VIs in their own physical folders, and to have Project Virtual Folders be identical to my Physical Folders.  But how do you show us stuff if you have a dozen VIs?  Simple, put what you want to show (even the entire Project) in a folder, compress the folder, and attach the .ZIP file!  Makes life easier for us (and prevents, or "lessens the probability of") rants from curmudgeons such as I.

Bob Schor 

[MarkGreally]

I changed the the state in the last state to go to "init" instead of "wait for start" as init is the first state on start up. It has solved my problem but I didnt think I would have to initialise everything again. It happens so fast so I dont really mind.

When it is finished and redo. This means that when the program went through all its states I would re run it by pressing the "start" button which does serial read and so on.

Its in development mode. By abort I mean just pressing the abort button.

I did indeed forget to close the instrument port. This will be done.

Jeff: how does not initiallizing the shift register with the cluster of IO Sessions cause errors to go to memory?

Thanks,

Mark.

[James.M · Accepted solution]

---

@MarkGreally wrote:

Jeff: how does not initiallizing the shift register with the cluster of IO Sessions cause errors to go to memory?

---

The shift register needs an initial value to give the inside of the loop. When you first run the program, that initial value is the default value. After you've run the VI once, that shift register now has the last value still in memory and uses that as its new initial value. So wiring something in to the shift register from outside replaces whatever initial value the shift register might have in memory with a value that you specifically want.

I'm glad you went and cleaned up the code a bit with the cluster. It's even better if you name your cluster elements and use Bundle By Name and Unbundle By Name. Then you can only pull one or two values at a time that you care about instead of unbundling and bundling them all. The naming also makes it easier to make sure you're pulling the right values.

Listen to Bob Schor's suggestions to make your code even better.

[MarkGreally]

Do I nescerrarily need initial values in the registers. The program seems to run ok without. What implications is this likely to have??

[JÞB]

---

@MarkGreally wrote:

Do I nescerrarily need initial values in the registers. The program seems to run ok without. What implications is this likely to have??

---

No it does not seem to run OK without initializing the Shift Register.  Hence your first post!  Untill you run the vi with all of the Error In clusters with default (No Error) values a lot of the subvi.s will simply not execute and return the error in.  

You still need to find the Error and what function is reporting the error.

[MarkGreally]

Does this mean I have to give the error an initial value? This is a bit confusing. What sort of value should I give it.

Then is it best to view the error at each stage to see where its coming from??

[RavensFan]

Yes.  Right click your shift register and pick Create Constant.  Be sure all of the errors are showing as "no error".

[MarkGreally]

Because the program runs fine from initial start up I am not sure what default values to give them. Is there any guidelines to this??