help required

[Rock4]

Hi Folks,

I had started working on a labview project for college at the beginning of the Summer and had received some very good advice and help from previous posts on this forum. Unfortunately I had to put my project on the back burner for a while and was granted a deferral from my college lecturer. Now however the time has arrived and I have got to get this project finished asap. The problem I am having is that having previously designed my front panel I couldn't create a periodic I/O server because I was using such things as local variables and invoke nodes, (My project has to use the Labview DSC Module and its coponents). I now decided to go back to the drawing board and pretty much start from scratch, removing local variables and the invoke node, however this has thrown more problems at me. I guess now im looking for any advice you folks would be willing to offer me as from this point I have roughly 48hrs to get this finished and have no idea where to go from here. I have attached my main VI (Project Process) and a Sub VI I created (Pressure Monitoring). The idea is that as the mixer tank fills and the LED for pump1 is "on" the pressure monitoring dial for pump1 will operate, this in turn will switch "off" when the LED for pump2 switches "on" and as the product tank fills the dial for pump2 will operate and pump1 will switch off. If someone could please point me in the right direction on how to get the sequence I a looking for that would be great. Any help on this will be greatly appreciated.

Regards,

Dave.

[altenbach]

So far you are not using DSC, which seems to be required

Currently, the program is linear and pretty dumb. Why do you need so many independent loops? The code of the two lower loops can probably be combined onto one loop. The upper three loops are sequenced and then stop forever. I don't understand the "start" control. It makes no sense to have it as a control, because it makes no difference once the program runs and should always be true. A diagram constant would make more sense. (or are you running all this in "run continuous" mode??? Don't!).

All you need to rewrite it as a proper state machine. (Here is an old example that seems to be related. Maybe it can give you some ideas)

[Rock4]

Hi altenbach,

Thank you for your response. I could not open the example you sent on to me as I am using Labview 8.5 student edition, apologies for neglecting to mention this in my opening post. You are correct, at the moment I am not using the DSC module, I thought it would be better to design all my VI's first then try and merge them into something that works or at least show what it is im trying to achieve, but as you can see its not going too good at the moment.  Now that you mention it I now also know that what I attached looks ridiculous but I suppose if its possible to tidy it up and get something that works that's what I got to do. Unfortunately I'm trying to do this without the use of state machine architecture as I'm pretty sure that it is way more advanced than what I'm able for right now, (a novice at labview and no knowledge of any other programming whatsoever). I will try and explain a little better than last time what it is im trying to achieve. Initially the first part of the VI was just the two tanks filling, first the mixer then the product filling, trying to simulate a basic water treatment plant. The two lower loops I later added as I am trying to simulate the pressure settings for the pumps 1 + 2, i.e. when the first pump is operating the needle on the first dial fluctuates over the set point and same for the second pump. From here I am hoping to add another tank to simulate the reservoir but I hope to do this later. When I have my three working VI's I then hope to be able to merge them and then set about creating my I/O server, shared  variables, a server VI and client VI. Now the million dollar question can this be accomplished without the use of state machine architecture, your help on this is greatly appreciated.

Regards,

Dave.

[James_W]

---

@Rock4 wrote:

Now the million dollar question can this be accomplished without the use of state machine architecture,

---

Surely the million dollar question is why to try to avoid the state machine if you think it might be better for you. It's far easier to debug than most other architechtures and trying to avoid it will probably cause you more headaches than just having a quick look at it.

Try looking at this little state machine to see if you can understand how it works.

(Add more cases to the enum and change the stop condition) - you can learn a lot about state machines in 5 mins from something like this.

Regards

James

[Rock4]

Hi James,

Thanks for the reply, I understand that state machine architecture is the best way to go, but as you can see by what i already posted i think im a million miles away from understanding or even grasping the basic concept before this project has to be completed. Im really just looking for a basic tank filling and emptying  (if possible) sequence without the use of local variables, as these have set me back right where I started out from. I also need to incorporate a sub vi into my project and then set about using the DSC module for my shared variables etc. Sorry to be a pain but at this stage this project is really wrecking my head, especially considering the amount of errors I have encountered and managed to solve with some great help from this forum, only to run into bigger problems five minutes later.

Regards,

David.

[James_W]

Hi Dave,

Did you look at the code I posted or did you just say to yourself I have a headache and assume you wouldn't understand it? I know that is often my reaction when I am tired and frustrated, so try reading on and see if this helps clarify things for you:

What I posted was the very simplest form of state machine.

State 1

State 2

Exit

It was the same as a flat sequence structure but has more room to expand in the middle and is easier to debug when things go wrong.

Run with highlight execution on (lightbulb and watch the block diagram) I saved it in 8.0 to be sure you could read it.

It could be expanded/ changed to run different states depending on the previous state or a tank level now:

e.g.

 State 1 until Tank 1 is full,   (Tap open, plug close = fill tank)

then run State 2 until Tank 1 is empty (Tap Close, plug open = empty tank)

then State 1 again

(exit when user presses exit whichever state)

Check tank level (this could be the default state)

if below 1/4 full run state - State 1

if 1/4 - 3/4 full run state - State 2

if over 3/4 full run state - State 3

These states can then check for more than one thing if required.

The functions of each State can be turned into a SUBVI once they are created - this is much easier if they don't need to access the front panel Stop button as you shouldn't need refernces and sould be able to just use terminal and wires. Select the required code (click and drag around it to highlight it) then Edit>Create SubVI. You have used a SubVI as required - just use a SubVI for a calculation or to create a function you can reuse like Tap status - controlling the DSC module.

Regards

James

[Rock4]

Hi James,

Thanks a lot for your reply again, I did look at what you posted and think I understood it a little, to be honest your 100% correct when you say that I'm frustrated and showing a bit of a defeatist attitude but I think after reading your reply I will try to grasp state machines and hopefully with a bit of endeavor maybe I'll be able to implement some of your ideas. Pretty much all of what you said is exactly what im trying to achieve. Thanks again for your help on this.

Regards,

Dave

[James_W]

Glad to hear it Dave,

I'm off site in a minute and won't be back until after your deadline but good luck. hope you have an understanding of state machines now. If it helps in any way I have just put your original top level VI top line code into a quick state machine so you can see how I would do that.

If you change the Enum contant to a control or indicator, you can customise it (right click Advance>customise) - saving it as type defined or strict type defined will mean that if you put more copies of the constant on the block diagram and base them on the type def control, they will inherit any additional cases that you add to the enum. This is very useful when building a state machine where you want the cases to do different things depending on the situation as it allows easy updating of the architechture. (I just used the increment function to give you an idea of moving between different states in the machine.)

Good luck. Glad you've adopted a more posative attitude, attitude is 60% of the battle, knowledge is the other 40%, (with the right attitude knowledge comes fast.)

Regards

James

[Rock4]

Hi James,

Thank you very much for your help with this. Having looked at the changes you made to my original VI there certainly is plenty of food for thought there. I think it certainly will help me in some way for this particular project but much more so in the future when I have more time to dedicate to learning this type of code.

Thanks again,

Dave.

[tinnitus]

"with the right attitude knowledge comes fast"

right, but opposite is more comfortable

with good knowledge attitute is more serene