LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sequence execution

>Well what happens when you have...

 

Then maybe they're evil.

 

Though, you could put the same sequence into two cases of a case structure, and rearrange one of them.

 

But I think you are right that a state machine would be better. And if you later need to add more and more sequence orders, maybe a state machine is the only practical option.

0 Kudos
Message 21 of 33
(1,962 Views)

hello ,

 

you can use time comparison  not to waste time when you want to quit

 

@+

 

Tinnitus

 

CLAD / Labview 2011, Win Xp
------------------------------------------------------
Mission d'une semaine- à plusieurs mois laissez moi un MP...
RP et Midi-pyrénées .Km+++ si possibilité de télétravail

Kudos always accepted / Les petits clicks jaunes sont toujours appréciés
Don't forget to valid a good answer / pensez à valider une réponse correcte
0 Kudos
Message 22 of 33
(1,948 Views)

If you think that using error clusters to establish sequential execution is in some way wrong, it's clear that you have no idea what true value of error data is. It is not a programming trick and is clever for far more than a day - in my case its been proving its usefulness for better than 7300 days. Propagating error data doesn't lay traps, it disarms them.

 

Mike...

Message Edited by mikeporter on 12-22-2008 11:12 PM

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 23 of 33
(1,929 Views)
Hello,

It is always preferable to use State Machines than Flat Sequence Structures. As said on an earlier post, Flat Sequence are not easy to update and maintain, to change one or two frames we might have to rebuilt the whole structure. On the other hand State Machines allow us to add or remove states easily without having to change any of our code.

Flat Sequence are not a good way of programming, they are an easy solution but might cause more problems when trying to maintain any VI. Nevertheless, there are times were a Flat Sequence is the only way to go.

Basically, the message is: Use Flat Sequence Structures as less as possible, they are not a fancy solution,might get the job done for a while, but if you are planning to grow your VI that will not be an easy job with Flat Sequences.
Salvador Mikel
National Instruments
Ingeniería de Aplicaciones
www.ni.com/soporte
0 Kudos
Message 24 of 33
(1,900 Views)

 


James R wrote:

If you are up for a small learning curve download the state machine design pattern from the openG toolkit and learn that model.  you can then use what they term macros to script a sequence of states


 

I think you're referring to the JKI State Machine, that can be downloaded using VI Package Manager.

 

Cheers,

 

-Jim

 

 

0 Kudos
Message 25 of 33
(1,890 Views)

>...you have no idea what true value of error data is ... in my case ... better than 7300 days ... Certified Professional Instructor Certified LabVIEW Architect LabVIEW Champion

 

You win. I've had 5 days of LabVIEW instruction and am still trying to finish my first LabVIEW project. But, perhaps you could enlighten me?

 

My idea of the true value of error data involves managing errors, which at least includes debugging code, responding to unforseen situations, handling those situations if possible or alerting the user if not, and perhaps keeping records to better understand the requirements of the program. Is this not correct?

 

LabVIEW has several explicit tools for doing these things, which generally have the word "Error" in their name and are grouped together in one palette.

 

LabVIEW also has explicit structures for controlling sequencing, which have the word "Sequence" in their name and are grouped together in the Structures palette.

 

I stil think that using error handling tools to control sequencing is a trick. In fact, during my 5 day career of NI training, the instructor introduced this topic by saying "I'm going to show you a trick...". It may be a popular trick, taught by NI, and even suggested in Blume's absolutely excellent Style book, but I see no way around it being a trick.

 

What I dislike about this trick is that it does not convey programming intent. It'd be pretty reasonable to just string the error wires along through a small, casual project, so that every Error Out terminal eventually finds its way to an indicator or an error handler or a logfile or a dialog or something. That may be good enough. Everything that could go wrong is treatable somehow. But when things get more complicated and you want to trap errors, and spot errors inside loops, and maybe catch warnings too, and automatically recover or record them, it'd be reasonable to build some throw-and-catch mechanism, with a queue. Maybe you're passing references to the queue into anything you expect to participate in error management. Maybe later you put the reference into a global, so you don't have to do error wiring to every nook and cranny. Each of these seem like reasonable ways to approach error management, in their various contexts. That moving between these approaches should change execution order, perhaps breaking the software, for reasons that don't involve error management, is bad.

 

The fact that LabVIEW does provide structures specifically for controlling sequencing makes this unnecessary. The fact that some of the VIs that are most useful in sequencing, such as some Timing VIs like Wait, don't even have error terminals, actually makes this awkward. It'd be great at this point to see Wait vi's with little single frame Flat Sequences around them to tunnel the error wires through, just so we could make this work.

 

Wiring errors conveys, or should convey, programmer intent to do something with errors. Sequencing things with a Sequence structure conveys programmer intent to control sequence. The fact that there is usually a good reason to wire errors from place to place when you don't need to control sequence can disguise the sequencing intent - that is, where the programmer has run error wires around, there's no reason to look for sequencing issues, because dealing with errors is reason enough.

 

OK, many people do use error wires for sequencing. As programming tricks go, this one is pretty widely advertised and taught. If programmers add a comment saying "Error wire controls sequencing here", programming intent is clear enough. Given all of this, any programmer looking at the error wires in a VI should realize they may be doing sequence control. Probably most people here accept that error wires are often for sequencing and disagree with my view.

 

Nonetheless, controlling sequence with error wires still looks like a programming trick that obscures the programming intent and entangles the otherwise separate topics of error management and controlling execution sequence. How are they not?

0 Kudos
Message 26 of 33
(1,868 Views)

I think you have missed the point entirely about the error clusters. Since you admit that handling errors is important, why would skipt that in favor of a sequence structure. By using the error clusters, you accomplish both. That is what makes the sequence structure redundant. Even if you do not add any error handing of your own, there is built-in error handing that is important. For one, if a function is passed an error, in most cases, that function does not execute, it just passes the error on. It does not make any sense to perform an operation if an error exists. You want to get to the error handler as quickly as possible. By placing a case statement around you code and wiring the error cluster up to the case selector, you can do the same thing.

 

p.s. I don't think of the wait and wait until next multiple as sequencing functions at all They are typically used to time a loop and nothing would be wired to them (error or not). If you want to place a delay between functions, then simply use the Delay function. That does have error in/out connections.
Message 27 of 33
(1,844 Views)

>I think you have missed the point entirely about the error clusters. Since you admit that handling errors is important, why would skipt that in favor of a sequence structure. By using the error clusters, you accomplish both. That is what makes the sequence structure redundant.

 

Oh. OK, I think you are right. I did miss entirely the point that wiring the errors is practically necessary and makes the sequence structure redundant. Guess I was paying primary attention to sequencing first and didn't notice that when I get around to wiring the errors I'll be forcing the sequence anyway.

 

Dennis, Mike, and others, you're right. Thanks for teaching me something!

Message 28 of 33
(1,834 Views)

The point to remember is that all data is important - even (or perhaps, especially) error data. The point I like to make in class is that error data is very important. Assuming you did the system design properly, at run time, the error data it is largely what tells you that its ok to trust the other data that your system is returning. That being so, you need to be as careful about propagating and preserving it as any other data.

 

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 29 of 33
(1,796 Views)

>all data is important - even (or perhaps, especially) error data

 

Yes, this is how I got off track:

1) Yeah, yeah, I'll get the errors wired later

2) Sequence is important

3) I could use a Flat Sequence, or bend the errors to fit the job.

4) What was I going to do later...?

 

If I realized what everybody was telling me:

1) I need various things wired, including errors of course.

2) I have to make sure I wire them in order of execution if that order matters. This is easy if I also order them left-to-right on the diagram.

3) Now their order is correctly established, maybe by several things, maybe only by the error wires, but correctly established in any case.

4) Flat Sequence not needed (which they rarely are).

 

 

>you need to be as careful about propagating and preserving it as any other data

 

This suddenly became clear last night as I read somewhere that you usually want to redirect program flow to get to the error handling quickly if there's an error. The error wires aren't just sewer lines. The goal isn't just to make sure they all dump someplace suitable. You actually make some of the biggest changes in program logic depending on their state. Arguably they are the single most important category of wires that will get tested to decide program flow.

 

Thanks again.

Message 30 of 33
(1,787 Views)