Michael Aivaliotis

I'm very curious about remote debugging ;-)

Rolf Kalbermatter

Me too. It seems like remote debugging will work similer to RT debugging where you run your VI's in the development environment but target the application.

I would greatly discourage you from taking this course of action in the future. No one learns anything from locked diagrams.

However I would also encourage you to enthusiastically defend and explain you coding style and techniques. I'm glad that Michael took it upon himself to critique your code because in the back of my mind I was thinking similar thoughts.

However I was equally impressed by your response explaining what your thought process was and what your experience has taught you. Normally this kind of insight is not expressed.

I did pickup a few tips on scripting but the discussion on shift registers and handling of terminals in event structures in my opinion is the real gem in this thread. :2cents:

I would agree with mballa. He probably knows me a little better since NIWeek and understands how picky I am when it comes to coding style. I've been fortunate throughout my early career in LabVIEW to have experienced developers around me that I could discuss ideas and techniques with. They would also challenge my design decisions which would force me to evolve my style. That's how I've reached the level I am today.

I always try to push people to explain their thought process when they code a certain way. Often time we just do things "just because". Often time this has evolved due to a few late nights of debugging customer code, only to discover that it was caused by a certain boolean button starting off as pressed. This however is the exception and shouldn't dictate how you program all applications. When we have a clear head, we should go back and evaluate, why that happened.

I'd like to add one thing on the use of bundle\unbundle. Adding a new datatype to the shift register only requires the addition of the datatype to a strict-type cluster and you don't need to wire new wires through all the cases. Of course the tunnel wiring wizard would solve this problem but that is no excuse really. LabVIEW now provides the Navigation Window, but this doesn't mean we should all start creating wiring diagrams that span the width of 10 monitors...

As far as your revised application using bundle\unbundle by name, I would give it an A. The reason I didn't give it an A+ is for 2 reasons. One reason is the use of array of strings. I used to program using array of strings and evolved over time to using standard strings with linefeed delimiter. I just recently had this discussion with a colleague and asked them to try using delimited strings instead of array of strings. He was reluctant at first but after he tried it, he was totally converted to this new method. Delimited strings allow easier editing of your state sequence lists because you can just double-click in the textbox and start typing. You can also quickly select text copy past etc.

Another item of note in your revised code is the use of wiring a TRUE though every output to your conditional terminal of the while loop. Again, it works but it's a lot easier to just use the "stop if true" option on it. This means you only really have to wire a constant out on the frame that terminates the while loop. In your case it would be the "finished" and "default". All other cases can just use the "use default if unwired" option. This means if you add a new case, you can just ignore this terminal. A Minor thing but it's nice not to worry about those pesky little constants.

From your profile it looks like you are local to my area (Livermore) so perhaps we can get together at the next LAVA meeting to discuss these coding techniques some more in person. I think the next meeting should be sometime in November. :thumbup:

And how :question:

Ok, i

Sad to hear that scripting is no longer supported in LV8 But as long as LV8 is backward compatible, we may be able to use LV 7.1 and do scripting somehow ...

I wouldn't cry for too long. I know scripting is still there. NI just changed the ini keys, that's all. I don't recall what they are but I'm sure someone here can give us a hand...

For some reason I never had a need for this before. I usually perform some calculations to decide where to draw next. It would be nice if I could figure out the current location of the pen in a picture control. I hope some of you gurus out there have this already or even better... is it available in LV?

Since the release is now official. Go over to NI's site, gather your ammunition and start discussing your opinions on LabVIEW 8 in our new dedicated LabVIEW 8 forum. I'm sure all of us have opinions on the matter. So let's hear them. Yes, that means all you former beta testers too...

Sometimes on more complicated systems I do bundle lots of shift register elements up into a cluster and pass that around but I have read at least one critique (NI forums) of that style as well (no reason given) and I never have been sure if there was a performance penalty with bundling & unbundling the elements. I must admit it can be easier to follow the logic with bundle/unbundle by name rather than labels sitting on top of wires. As far as real estate, I'd argue that the way I did it takes up more vertical real estate but what you suggest can take up more horizontal real estate so which you chose in that respect depends on what you've got to spend. And, while it is a small thing, it can also be easier to probe individual wires than cluster wires.

I'd love to see a discussion on the pro's & cons of this. It's something I've wondered about!

Well the performance penalty is relative. If you work with a team of developers and others have to dubug and work on your blockade of wires then it suddenly becomes an issue. They throw it back in your face and ask you to redo it. So ya, your performance goes down.

As far as the boolean feeding the case structures inside the event structure, I guess it's just something I have gotten into the habit of doing based on past experience. Over time I've tried doing this many ways and the way I have done it here gives me the highest level of assurance under all normal and off-normal conditions that the action will only be triggered when the button goes DOWN and the button will always be found in an UP state when the user expects it to be up.

Can you explain what an "off-normal" condition is? I still don't follow your argument. Using the mechanical action "latch when released" covers this. I have not (since the event structure came out) seen any condition where I would have to "make sure" the button was going down. I may be missing something here, so please enlighten me. I disagree with any code on a diagram that is superfluous. It just causes the programmer to pause and have to think about what is going on. Slows comprehension of the code. Makes me think, "ok, so why is this like this?"

I'm sure there is a nifty way to do this with scripting, but I haven't learned any of that yet. Below are two VIs that work together to do what you want. I'm sure much more functionality can be added. Follow the instructions on the front panel of Read_String_Array.vi. You will need both VIs.

Pat

Nice little trick. Doesn't use scripting but is still a big time saver. Thanks :thumbup:

Ok, this one is more a personal preference but others might find it usefull. As I get older :thumbdown: I find I need more of these aids to keep my programming speed up to the same level as you young'ins. Change your Windows settings as shown in the first image. You will see a noticable difference in the grab handle colours (they turn red). Helps in other areas as well.

Attached is an update to the Select-A-Case VI that I had posted a few days ago.

(I also eliminated the unused shift registers too Norman)

Nice tool!

Some nitpicks on style though. Have you considered the use of bundling all the shift register elements into one cluster and only requiring a single wire to cross through your cases? Those wires take up a lot of real estate and it can be messy to debug.

Another thing. Why do you take the buttons and feed the value into a case structure inside the event frame? This is unnecessary coding. Obviously the button value is true otherwise you wouldn't be in that event case. If you are worried about button staying down then set the mechanical action to "switch when released" Which they should all be set to anyway. I'm not following the purpose of the cases in every event frame.

Trying to find someone that has the following already:

Take an array of strings and generate a "string type" case structure that has a case for every element in the array.

I also ment to ask if I can make more than one submission?

(first-try-in-case-I-don't-have-time-later submission, possibly followed by a refinement)?java script:emoticon(':clock:', 'smid_13')

smilie

Would all submissions count or only the last one? (can one person get first and second prize?)java script:emoticon(' ', 'smid_22')

smilie

I'll list the winner and probably the next several runner ups. You can submit as many as you want until the deadline and I'll pick the best.

Is is ok to use vi's from OpenG or vi's derived from one of them them?

(if the code is included in the llb you submit).

Of course, no problem.

Looks like Brian's been busy. It's great to see LabVIEW VI Scripting used in a real product. I guess LAVA Members should be getting their complimentary unlocked, password free, unlimited use version soon?

Class Browser for LabVIEW

Michael:

My version of LabVIEW 7.1.1 has several PICTURE FUNCTIONS that (according to the LabVIEW help documentation) are "NOT INCLUDED IN BASE PACKAGE".

I am not avoiding use of these picture functions in my coding efforts. I hope these are not the "IMAQ TOOLS and VIEWERS" you prefer us to avoid.

This is alright. The picture functions you mention are fine.

try this.

Your definition of a block as related to the array information does not jive. In any case, regardless, what you probably want is to use the array subset function. You can feed in the start index and length of the the elements you want. This should handle what you want.

Thanks PJM.

However, the system tab color seems special in the sliver theme. The color is not uniform, slightly darker in the bottom (see my previous post) so there is no single color one can use to put a label over the decoration. The solution to use a normal 2D tab colored with object/panel color seems to work well but for the sake of uniformity I'll have to change all tabs in my application.

Yes, you are correct. I've been throught this exact dilemma before. There is no object (decoration) that mimics the WinXP themes stuff. This is a real wish, to tie-in somehow to the winXP skinning.

I agree with PJM, attach an example please.

I don't see this posted, if it is, oh well. Make your coercion dots stand out by making them bright red:

More annoying singing people...

I don't know what this is but.. I gotta get me some of that!

I vowed then never again to criticize code like that in public unless the person who wrote it was there and had told us to pull no punches. Good grief, I'd hate to have to critique the first couple of VIs/project that I did.

I agree and do not critize code, and believe me I see lots of LabVIEW code. I say any code that works is beautiful.

I do take the gloves off when the client is in the difficult situation of think a 'few minor tweeks' are all that is needed to add: User log-in, data basing, etc.

My answer to customer's requests for feature additions to existing badly written code: No problem, anything can be done (it really can). It will only cost you x dollars. If they disagree, all the better, I need my weekends for personal time, not for digging through some interns "learning" project. I just hope if you are the programmer who ends up doing the fix that you are honest with the customer about the amount of work required. Let's not whore ourselves out to the lowest bidder.

Bottom line, as long as I have breath in me I will educate and preach proper programming standards, regardless of the audience response. Hopefully, if enough of us blow in the right direction, we can start a wind of change in the world of badly written LabVIEW code.

I discovered another serious bug in NI Motion (previously Flex Motion) driver.

Regards,

PJM

So, the moral of the story is... Provide a test harness to test all VI's before release.

A much simpler preventative measure would be to position the inputs and outputs at the same alignment. This way you don't have to think too much about wiring mistakes. Having them swapped like that is asking for problems.

Another thing in this example is the coercion dots. Correct connection removes coercion. The coercion in this case would raise a flag to the programmer. This is why I change the colour of my coercion dots to bright red instead of the dull grey.

I was curious what others are doing about directing the user's focus toward the VI (or VIs) that have execution focus and away from VI's that have lost execution focus because one of their subvi's has it?

I have a user who has difficulty keeping this straight and I would like to try to smooth things out in this area. The LabVIEW system is somewhat complex with as many as three top-level VI's running at one time controlling various pieces of hardware and the user switches back & forth between them by either clicking the window or pulling it up off the WinXP task bar. This part of it works fairly well and is how the user wants it to work.

Where the trouble comes in is when one of the top-level VI's has a subVI window open that has execution focus. At this point, if the user expands the upper-level window off the taskbar (to where it was automatically minimized when the subVI window opened) he will find that it is no longer responsive because it is waiting for the open subVI to complete.... snip

Are there other, better ideas out there?

Well, why put the burden of figuring out which panel is active on the operator? It's the developer's job to make this obvious right?

One solution is to hide the panel that does not have the focus. Programming this is easy but the problem is that the operator will be confused when different panels become visible or invisible. The reason behind this behavior is not immeadiatly apparent to them.

Another solution is to leave everything as it is and just flash the titlebar of the VI which has the focus. This can be done using the windows API utilities that are available on NI's site and other places (i wish I had the link handy). I believe this will even flash the bar if it is minimized.

Convert your flat sequence architecture to a state machine. See the FAQ for more information:

What is a state machine?