shift register in sequence structure

[shoneill]

Re: stacked sequence structures at all....

And of course let's not forget that NI's leading by example on this......

Shane

[TG]

QUOTE (Cat @ Apr 3 2009, 07:06 PM)

Don't get me wrong -- I love state machines and use them all over the place. I just never made the leap into using it to make more simplified transitions between parts of my code that *always* go step1->2->3->etc.

I'm giving it a whirl right now with my big, messy, 3x4 screens, dies-after-8 hours vi. If I can make it work there, I can do it anywhere.

I think a state machine (any type) handles variation better than a stacked sequence.

If it always goes 123 then of course no problem there, however it is always better to design code with the

intention of being extended. Turns out to be easier to read and re-use too.

BTW Too late for me now, Ive got many megabytes of hideous looking code (with sequence structures) from past projects that when I need to look at them today,

make me cringe now.

Anyone else have skeletons in their closet?

[Neville D]

QUOTE (shoneill @ Apr 3 2009, 12:37 PM)

Re: stacked sequence structures at all....

And of course let's not forget that NI's leading by example on this......

http://lavag.org/old_files/monthly_04_2009/post-3076-1238787410.png' target="_blank">

Shane

Heheh! The NI Vision examples show you how NOT to code in LabVIEW (or how to code in LabVIEW to fail your latest flavour of NI certification CLA and what have you..)

N.

[hooovahh]

QUOTE (jcarmody @ Apr 3 2009, 01:08 PM)

The shirt from Happy Gilmore, I couldn't hurt a fly.

I do not remember that shirt in that movie...it has been a while since I've watched it all the way through, I mean its on TBS about every other day.

That did remind me of this one (the sticker on the right)

As for sequence structures, I only use them for really quick and dirty prototyping and for timing situations. Like I want to know how long it takes for a set of steps to take place so I'll put a stacked structure on it, then take tick count at the beginning and end.

I know there are better ways to do it (like with OpenG tick count if my code has an error in and out) (or using a functional global that runs at the beginning and end)

[Anders Björk]

It was like I expected one it is allowed to use feedback node on stacked sequence....

[Mark Yedinak]

QUOTE (TG @ Apr 3 2009, 02:40 PM)

Anyone else have skeletons in their closet?

Most definitely. There is even some old code that I thought was pretty good back when I wrote it and when I look at it now it makes me cringe.

[Rolf Kalbermatter]

QUOTE (Neville D @ Apr 3 2009, 03:54 PM)

Heheh! The NI Vision examples show you how NOT to code in LabVIEW (or how to code in LabVIEW to fail your latest flavour of NI certification CLA and what have you..)

At least someone cleaned them up in the meantime aligning the nodes wires and added error clusters. The old code when it was acquired by NI definitely was about how NOT to write proper LabVIEW code. It violated just about every style guideline that was ever released about how to code LabVIEW VIs.

I wonder if the original C code behind it was just as messy, but doubt it as it would be almost impossible to make such a big and complex piece of SW work at all then.

Rolf Kalbermatter

[jcarmody]

QUOTE (hooovahh @ Apr 3 2009, 04:01 PM)

I know there are better ways to do it (like with OpenG tick count if my code has an error in and out)

I'd still be as dumb as a stump if I didn't follow the posts on LAVA. Just yesterday I drew a Flat Sequence structure around a Tick Count (ms) function to time something. Thanks hooovah.

[crelf]

QUOTE (jcarmody @ Apr 4 2009, 07:38 AM)

Just yesterday I drew a Flat Sequence structure around a Tick Count (ms) function to time something.

Sounds like you could use a http://forums.lavag.org/-t13407.html&view=findpost&p=59675' target="_blank">sequence container.

[shoneill]

QUOTE (rolfk @ Apr 4 2009, 09:29 AM)

At least someone cleaned them up in the meantime aligning the nodes wires and added error clusters. The old code when it was acquired by NI definitely was about how NOT to write proper LabVIEW code. It violated just about every style guideline that was ever released about how to code LabVIEW VIs.

I wonder if the original C code behind it was just as messy, but doubt it as it would be almost impossible to make such a big and complex piece of SW work at all then.

Rolf Kalbermatter

Curioser and curioser. I always wondered why the code was so, how should I put it, fugly.

Who did NI acquire it from?

Shane.

[ragglefrock]

I personally fancy this technique. It's a static state machine, but the states are scheduled as the strings in an enum, in order. This makes it easy to set up your routines, reorder them, rename them, and so on, without worrying about typos or anything else.

The trick is to use the Variant utility GetNumericInfo (vi.lib\Utility\VariantDataType) to get the enum strings (no property node required), and then use scan from string in the for loop to convert those back into the proper enum values. All automated and safe.

[Yair]

Here's a challenge. You have an application with a long listing of rules, that will probably not change and if they will change, will require some planning anyway.

Do you:

1. Use C, which has no stacked sequences?
   
2. Write a state machine to go sequentially through many states that have be performed every single time?
   
3. Create a subVI for each section of the code (with additional internal subVIs) and string them together using error clusters?
   
4. Write a plugin archiecture and build the various sections as plugins?
   
5. Write a special script language and parser to handle the logic?
   
6. Write a framework which will handle the common parts and then build all the logic in configuration files and simply iterate over them?
   
7. Use a stacked sequence which clearly shows the order of the code (remember, fixed order) and allows reasonably easy debugging for specific points in the code?
   

[crelf]

QUOTE (Yair @ Apr 5 2009, 01:00 PM)

Here's a challenge. You have an application with a long listing of rules, that will probably not change and if they will change, will require some planning anyway.

Do you:

h. Use a flat sequence structure that is arranged so that the BD only needs to be scrolled in one direction (left/right) which clearly shows the order of the code (remember, fixed order) and allows reasonably easy debugging for specific points in the code?

Anyone got more options? We could set up a survey question on this thread...

[Yair]

QUOTE (crelf @ Apr 5 2009, 08:18 PM)

h. Use a flat sequence structure that is arranged so that the BD only needs to be scrolled in one direction (left/right)

Your code has 10 frames (like I said, a long list of rules). Welcome to the 12,000 pixels long VI.

[crelf]

i. Use TestStand.

[Yair]

QUOTE (crelf @ Apr 5 2009, 08:36 PM)

i. Use TestStand.

Maybe. Never used it, so I can't tell. The application needs to have a custom UI and run 24/7, as well as run custom code in parallel loops and communicate with various kinds of hardware.

[crelf]

QUOTE (Yair @ Apr 5 2009, 01:58 PM)

The application needs to have a custom UI and run 24/7, as well as run custom code in parallel loops and communicate with various kinds of hardware.

OK - is this a real application, or an academic exercise? I'd assumed the latter

[Yair]

QUOTE (crelf @ Apr 5 2009, 09:12 PM)

OK - is this a real application, or an academic exercise? I'd assumed the latter

It's actually several very real applications, all sharing some similar design requirements.

And yes, I do believe that in those cases the SSS was the right call even though there were other alternatives. The point is that even if a tool calls out to be abused, it doesn't make it automatically evil. It certainly is a valid argument for getting rid of it, but it doesn't mean that it's entirely useless.

[crelf]

QUOTE (Yair @ Apr 5 2009, 02:17 PM)

The point is that even if a tool calls out to be abused, it doesn't make it automatically evil.

I totally agree.

[Mark Yedinak]

QUOTE (Yair @ Apr 5 2009, 01:17 PM)

The point is that even if a tool calls out to be abused, it doesn't make it automatically evil.

I would agree that it shouldn't be considered evil. However if experience has shown that it is not optimal and open to abuse why not use the other methods which reduce the problems associated with the "abusive" tool. With respect to the stacked sequence structure I would still argue that a state machine would be preferred since it is easily changed if the need arises. After twenty plus years of software development there is one thing I have learned for sure and that it that virtually everything is subject to change at some point regardless of how much we believe it won't. I would rather prepare for the possibility of change rather than write that something that is rigid and very difficult to change.

[Michael Aivaliotis]

QUOTE (Mark Yedinak @ Apr 6 2009, 09:24 AM)

...After twenty plus years of software development there is one thing I have learned for sure and that it that virtually everything is subject to change at some point regardless of how much we believe it won't. I would rather prepare for the possibility of change rather than write that something that is rigid and very difficult to change.

Amen Brother!

[Yair]

QUOTE (Mark Yedinak @ Apr 6 2009, 07:24 PM)

why not use the other methods which reduce the problems associated with the "abusive" tool.

Because it's easier to write and easier to read. You're not talking about "states", just a lot of code. And if I really wanted to change the order, it's much easier to do by using the rearranging dialog that the SSS has. This won't be dynamic, but I really don't need it to be. And yes, things can change, but ultimately you have to draw a line and say "here I'm actually going to do some work instead of building a framework". The location of that line obviously depends on the specific project.

P.S. Some of the other options I mentioned are also perfectly valid solutions. I just happened to choose that as one which is suited.

P.P.S. Having SRs on the SSS would have made life somewhat easier, so I can understand why Stephen and co. don't want to do this.

[Michael Aivaliotis]

QUOTE (Yair @ Apr 6 2009, 09:42 AM)

"here I'm actually going to do some work instead of building a framework".

That's why you use templates.

[Yair]

QUOTE (Michael Aivaliotis @ Apr 6 2009, 08:21 PM)

That's why you use templates.

But you still have to write the code behind the template which will fit your specific use case (assuming you don't already have a suitable template) and then customize it once you start with the actual code. There is little point in doing this work if its benefits don't overweigh its disadvantages, right?

I'm not saying state machines are bad. I'm just saying that there are cases where SSS are legitimate.

[shoneill]

QUOTE (Mark Yedinak @ Apr 6 2009, 05:24 PM)

I would agree that it shouldn't be considered evil. However if experience has shown that it is not optimal and open to abuse why not use the other methods which reduce the problems associated with the "abusive" tool. With respect to the stacked sequence structure I would still argue that a state machine would be preferred since it is easily changed if the need arises. After twenty plus years of software development there is one thing I have learned for sure and that it that virtually everything is subject to change at some point regardless of how much we believe it won't. I would rather prepare for the possibility of change rather than write that something that is rigid and very difficult to change.

Would it be possible to write a Stacked Sequence Structure to State Machine converter using scripting?

Shane.