local variables not sending to board K8055

[acgraham]

http://www.theoriginalqueg.com/forum/learning%20with%20kevin%2003%20-%20implement%20interface%20into...

In my file when i change the "charging state" all the switches for my relays change

perfectly as you would expect.  however, the two "cases" designated for the "rest"

period in my case section dont end up sending the information out to the usb card.  it has something to

do with the while loop in each of these cases (if it isn't there i dont have any

problem).

i dont quite understand why those local variables aren't getting sent all the way to

the usb ouput-but they are getting sent to the buttons and being displayed on my screen.

[Guruthilak]

since you will be in one fixed state i.e 0,1,2or 3 (this is becase your case structure is inside the while loop) what ever value you have assgned to the local variables in that particular state would be sent to the hardware on every iteration of the while loop.

You have to rewrite the code ...may be start using an event structure....I just modified the code a little bit but i ma worried that this code may not run....how ever you can check once

[Ray.R]

---

Guruthilak wrote:

since you will be in one fixed state i.e 0,1,2or 3 (this is becase your case structure is inside the while loop) what ever value you have assgned to the local variables in that particular state would be sent to the hardware on every iteration of the while loop.

---

Yes..  Every loop iteration, it will reset the button to the values within the Stacked Sequence Structure.

In a sense, you also have a kind of a race condition, because there is no way of knowing which will be set first.  The Local Variables within the Stacked Sequence or reading the value that was set by the operator on the Boolean Controls.  I would bet on the last values within the Stacked Sequence Structure... without any guarantee.

You should avoid Local Variables at all cost.  Unless in some certain conditions, it would be okay-ish.  But this is not the case.  You should also avoid the Stacked Sequence Structures.  I hope one day NI will remove them from the palette.  Or place a caution note below them saying "Use at Own Peril and Risk of writing code that is not scalable".

So if you do re-write the code, avoid both Locals and Stacked Sequences.

As Guru mentionned, you could implement an Event Structure.  I would use the Event Structure purely to monitor changes in state (buttons being pressed by an operator). And the button value would be passed to another loop (State Machine) which would set/select the next state.

You could also implement the entire solution using a State Machine. It depends on what you are more comfortable with and which LabVIEWdevelopment package that you have.

Looking at your code, you should get rid of BOTH Statcked Sequence Structures, and you absolutely need to understand the data flow within your code.  LabVIEW executes based on data flow, meaning that as soon as data is available, it can execute any part of the code in parallel as long as the data is present.  So that must be part of your consideration during the edit or rewrite ofthe code.

To learn more about LabVIEW, I suggest you try looking at some of these tutorials.

[acgraham]

im considering rewriting the code but i dont know if the k8055 can be used without a sequence structure.  here is the example file created by ni.  I have also posted the original file as an attachment as per the forum rules.

Message Edited by acgraham on 11-29-2009 01:04 AM

[Ray.R]

Sorry to be the bearer of nasty comments, but here goes:  ( I just realized that I am repeating myself)

1. Your code lacks proper architecture.  I'm not going to bother trying to guess what it is supposed to do.  Well architectured / written code can be read / understood in seconds.

2.  You have a Case Structure with many Local Variables. The Case Structure will run in parallel with everything else in the larger loop.  There is a big lack of data flow within the code. 

3. Get rid of ALL Local Variables.  ALL of them.  They are not needed.  Use Shift Regirsters within the outer While Loop.  The wires are the variables.

4.  If you're going to have a State Machine, then it should be implemented properly.  Not only should it change the state of the booleans, it should also be able to "take care" of whaever should happen when in that state.  Unless it is a preamble for other things to happen.  Since everything runs in parallel, then why have it at all?  That's because it is not garanteed that it will run before whatever has to happen next.  As I said, I'm not going to try to guess what is supposed to go on within the code.  No one can guess..

5.  The code is obviously not finished.  Give meaningful names to the booleans, wire the Waveform Chart, the output of the greater then, etc.

6. SHrink the code to a single screen.  You have plenty of room and there should be more after doing the cleanup.

7.  Get rid of the Stacked Sequence Structure (bottom right).  Dataflow should be accomplished using the error cluster wire, not a stacked sequence.

8.  Again, do not use a Local Variable to change the value of the control that is the selector for the state machine.  The Shift Register is a better and more readable way to implement.  I would suggest using a Type Def Enum Control for the selector.  It will give state names to the Case Structure instead of numbers.

That should be a good start.

Also, please explain what you want the program to do and how you want to software to do it.  It will help us understand what help you will need.  Fixing the above might even fix your problems.

R

 

[acgraham]

I've had a go at the cleanup and got rid of local variables but at the moment the biggest problem that i need to change my perception on is the sequence structure.  sorry if i can't simplify the system more, i've got it as small as i can.

if someone can help me breakup the k8055 example it will help me fix the dataflow, which i know currently reads poorly.

all i need from the k8055 is to check a voltage (analog input) and all my dataflow comes after that.  the end of the flow will be to use the digital outputs to change the state.

my system connects a charger (bedini motor) up to a battery and cycles that battery for charging and discharging cycles.

1.  when the battery is charging it will check the voltage every 10 minutes.  if that voltage is over 14.2 volts it will log the duration for charging and the voltage and then change the state of digital outputs to resting.

2. during the rest period it will wait 60 minutes before logging the resting voltage and then start the discharge cycle.

3.  during the discharge cycle it will check the voltage every 10 minutes.  if that voltage is under 12.2 volts it will log the duration for the discharge cycle and the voltage.  it will then change the state to resting.

4.  at the end of the 60 minute resting period it will log the voltage.

each of these states, durations, and voltages is written to a spreadsheet and the cycle is repeated again until the user presses stop.

Message Edited by acgraham on 11-30-2009 11:26 PM

[acgraham]

i also forgot to add that the voltage is measured by averaging samples over a few seconds.

[Ray.R]

Which LabVIEW version are you using? 

So that if I modify the code I save it back to it's original version..

[acgraham]

thanks, im using 8.5

[acgraham]

alright i fixed it using a case machine.  its considerably neater!  it would be great if you guys could have a look and tell me if you would have coded it any differently...

thanks again for all your help!