LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview program code error; please help

hi
i have written a labview program for one of our company project using state machine

the program has  cases

Case 1: Init
Case 2: Init Heat
Case 3: Init Denature
Case 4: Denature
Case 5: Cool from denature to anneal
Case 6: Anneal
Case 7: Heat from Anneal to Ext
Case 8: Ext
Case 9: Completion

**At case 8, it will either go to Case 4 or case 9 depending on no of times case 3 to case 8 has ran


Problem with program:
The first cycle has no problem but when it is going the 2nd cycle onwards, its seems that the cases are not being executed though there
is increase in the counter for no of cycles run

** the program was intially included with channel initialisation etc + voltage output to power card but it is simplify to debug (i.e. change the input to "control (user input) and exclude voltage output change temperature range etc however i could not
detect the error..............

please help
thks
Download All
0 Kudos
Message 1 of 10
(2,926 Views)
I'm not sure I understand what the problem is. They way you have it wired cases 3-8 will execute twice, since you have the counter compared to the value 2. Are you saying that it's not executing twice if it's set to 2?

Code comments: In you Open File you need to specify the pattern as "*.txt", not ".txt". Also, please make your diagrams smaller. Are you working on a 30" monitor? Also, the forumal node seems to have the same formula. Probably should mae this into a subVI.
0 Kudos
Message 2 of 10
(2,912 Views)
hI
THOUGH IT SEEMS TO EXCUTE TWICE
THE SECOND TIME IT EXCUTE SHOWS STRANGE RESULTS
IF U CAN, TRY RUNNING THE PROGRAM
U CAN INPUT 0.61 INTO THE "INPUT VARIABLE" N U WILL SEE WHAT I MEAN.................
ALL TIMING CHANGED TO ZERO ON THE SECOND CYCLE AND IT SEEMS THAT EACH CASE WILL SKIP PAST VERY QUICKLY

CAN'T UNDERSTAND THE REASON, THE PROGRAM SEEMS TO WORK PROPERLY WHEN I CHOOSE THE ICON "LIGHT BULB" TO SEE IT
RUN SLOWER TO UNDERSTAND THE LOGIC BUT WHEN RUN AT NORMAL SPEED , THE PROBLEM RETURNS........
Download All
0 Kudos
Message 3 of 10
(2,899 Views)
Please stop screaming at me, and turn off your Caps Lock. Smiley Wink

Unfortunately, I can't run your program since it uses the PID Control Toolkit, which I do not have, and it's not something you can distribute since you need to buy it. Have you tried running your program with highlighting on, so you can see what's being generated from the PID VIs? Maybe your problem is in the way you're using the VIs?
0 Kudos
Message 4 of 10
(2,885 Views)
I cannot run your VI, because I don't have the PID subVIs. Are they from a toolkit? What determines the loop rate of the inner loops?
 
Looking at the code, it seems overly complicated because there is a lot of duplicate code. It seems most of the cases are nearly identical except for setpoint, etc. This calls for code re-use. You need exactly one instance of each code construct, that way you can also get rid of all these local variables.
 
Of course then there is completely unecessary code that only complicates the diagram. Have a look at the following fragment that occurs several times in your code:
 

Can you simplify this? Look again!. (You can safely replace it with a simple wire without any loss in functionality! :D)

Message Edited by altenbach on 12-20-2006 09:20 AM

0 Kudos
Message 5 of 10
(2,885 Views)
Opps sorrie abt the cap lock
not my intention

anyway regarding code re use as mention to make it more efficient
can you please teach how to do that?
0 Kudos
Message 6 of 10
(2,875 Views)
I would strongly recommend cracking open that LabVIEW book and reading up on subVIs. You should also go through the LabVIEW tutorials and the examples that ship with LabVIEW. You can also try the tutorials on the community sites.
0 Kudos
Message 7 of 10
(2,869 Views)

I am not sure what "strange" results are.  Because I have no idea what it is supposed to do all I can tell you is that the first run takes awhile and the second run is extremely fast.  I can get both runs to take about the same amount of time by reinitializing the PID loops.

I am not a PID expert so that may be way off, but like I said, what is "strange."  To reinitialize the loops I would wire into them an =0, so that when each step starts you re-start the loops.

I also noticed that you are calling some PID VIs, but not using the outputs at all.  Is that on purpose, I am not sure what good a control loop does you if you don't use the results?

0 Kudos
Message 8 of 10
(2,863 Views)

Hi youngster,

You said that turning the "light bulb" aka "execution highligting" on made your code work.

This is an (almost) sure indicator of a race condition. Execution highlighting slows down the execution in the vi or vis it is enabled in and may (not for sure, just may) alter the order in which code (that is not otherwise constrained by the wiring) will execute.

You should make sure that if a particular piece of code, sub vi, etc depends on getting the results from 'earlier' there should be some means to enforce that ordering, such as being connected by a wire, or enclosing both the read and the write in another structure such as a loop, and connecting the structures by a wire. The error in / error out terminals on many NI-supplied vi's are useful in this regard.

An easy way to get a race condition error is by use of local or global variables. If you (say) write to a local variable in one part of a vi and read from its control in another part of the vi, and there is no means to specifically control the order in which the read and write take place, there is a possibility of reading the control before the write has taken place (or perhaps after - you just don't know)

The system I'm on doesn't have the right revision of LabVIEW loaded for me to see your code, so these are just general comments, and not specific to the code you have wired.

Rod,

 

Message 9 of 10
(2,860 Views)
Hi Evan and Rod
thks for the great suggestions

yap Evan, u r rite to say.
it make no sense as i not making use of the PID output
eventually i will "connect" it to a power card but rite now got to solve this running problem first


the "strange results" is exactly what u mentioned, one cycle run faster than the other and all timings change to zero on the second run which i
think each case did not have time to executed, i will try out both things suggested seems logical to do what both u all suggested

Great to receive help when i need it most
Hope it be good news soon.................

thks again
will get back
0 Kudos
Message 10 of 10
(2,834 Views)