Initialize indicators at start?

[Joe_McC]

This probably has a simple answer, but I just can't see it....

I have built a VI to control a motor driver.  There are various modes of operation  are triggered by selecting buttons on the front panel. The VI checks the state of each button & executes code which depends on what button was pressed. When the code completes, the VI checks all buttons again.

When I press the start button, I want the motor to run to the home position, then start running in the opposite direction until a set number of steps have been done. There are some indicators which I update during this second phase such as position and limit indicators. This part of the task is carried out in a 2 frame sequence structure. The first frame runs the motor home, the second runs the motor in the opposite direction to the set number of steps. This frame has the CW/CCW limit indicators as well as the #steps traveled. These indicators are updated with each step. Each frame uses a sub vi to step the motor in a given direction and indicate if a clockwise or anticlockwise limit was reached. This works well, though its not necessarily the best way to do it. The problem I have is that after a run, the indicators are left with the value they had after the previous run. So the # steps taken is still displayed, if a limit was activated, the limit light is on etc. 

That is actually desirable in the app, but I'd like to clear these when I press the start button to run again. The thing is that they will not update until the program reaches frame 2, i.e. after the motor has traveled all the way to its home position. Obviously this is not too good from an end used point of view. I tried pulling them out of the sequence frames, but still can't see how to drive them from 2 separate sources. It would be enough if I could just clear them when I hit the start button. I'm probably just looking at this from the wrong perspective.....

Any help appreciated,

Joe 

[elset191]

Use local variables to set the default  before any other code executes

[Mark_Yedinak]

First, you should consider replacing the sequence frames with a state machine. You may also benefit from using a producer/consumer architecture. You can use a loop with an event structure that can catch the button presses or data changes of your controls. This can send messages to the state machine using queues. The state machine can contain all of your various actions which you have already placed in subVIs. One of your states can be an initialization state where you can do whatever processing that is required to place your system in it's initial state. LabVIEW is a data flow language and therefore you should try to use that as opposed to using sequence frames to turn it into a sequential language.

[CoastalMaineBird]

can't see how to drive them from 2 separate sources.

This is what local variables are for:

1. Create a LOCAL VARIABLE for one of your indicators. 
2. Set that local variable to WRITE.
3. Feed it a value of 0 at the point where you're reacting to the START button.

Repeat for your other indicators.

They will go to zero when you START, and then to the final value when done.

[Mark_Yedinak]

I must admit that I am somewhat surpised by all the advice to use local variables and maintain the current architecture of sequence frames. Yes they wil solve the immediate problem that he is having but based on the description of the code it is not very flexible or extendable.

[elset191]

---

Mark Yedinak wrote:
I must admit that I am somewhat surpised by all the advice to use local variables and maintain the current architecture of sequence frames. Yes they wil solve the immediate problem that he is having but based on the description of the code it is not very flexible or extendable.

---

I suggested locals because it's an easy direct fix.  I assumed the poster wouldn't want to rework his entire app.  I do feel your suggestion is a better one (I use state machines heavily), but it would take a significant amount of work to change, I assume.  

[smercurio_fc]

---

Mark Yedinak wrote:
I must admit that I am somewhat surpised by all the advice to use local variables and maintain the current architecture of sequence frames. Yes they wil solve the immediate problem that he is having but based on the description of the code it is not very flexible or extendable.

---

I absolutely agree with you. Your recommendation of a state machine or a producer/consumer architecture is by far the best approach to this problem.

[CoastalMaineBird]

 I am somewhat surpised by all the advice to use local variables and maintain the current architecture of sequence frames.

He didn't ask if there was a better architecture; he asked how to set an indicator from two places. 

Having posted exactly one message in a history of about one week, he appears to be beginning with LabVIEW.

I don't see the value in telling him to re-engineer the whole architecture when there's a simple barrier to overcome. 

[billko]

---

Mark Yedinak wrote:
I must admit that I am somewhat surpised by all the advice to use local variables and maintain the current architecture of sequence frames. Yes they wil solve the immediate problem that he is having but based on the description of the code it is not very flexible or extendable.

---

Mark:

Technically, you are right on the money.  In the real world though, you work with what you have.  What probably should've been said was, "here's how to fix your problem..." and then "here's how I would do it in the future."  🙂

Bill

[Mark_Yedinak]

---

billko wrote:

Mark:

Technically, you are right on the money.  In the real world though, you work with what you have.  What probably should've been said was, "here's how to fix your problem..." and then "here's how I would do it in the future."  🙂

Bill

---

Yes, this would have been a better way to answer the question. The one thing that I always tried to do with folks who are new to LabVIEW is to steer them in the right direction. I think it is better to expose new people to the benefits of data flow programming instead of perpetuating trying to make a LabVIEW application look like a sequential program. It is always easier to teach the right approach in the beginning than to break bad haits once established.

In addition, if this application is in the early stages of development now is the time to rework the code. I am sure that everyone knows that when you work on a project and bang something out and say "I will come back and do it right in the future" you never get back to it. It is best to lay a solid foundation in the beginning rather than trying to change things further down the road.