E-List

[tst]

---

@chilly charly wrote:

Arrays and Strings in Loops This Concatenate Strings function is inside a For Loop. Every time characters are appended to the string, LabVIEW must reallocate the memory buffer and copy the entire string to a new location. This can cause execution time to become slower with each loop iteration."

May be I missed something but I do not see another way of appending chars to an array of string !

---

I assume they mean you should use Replace Substring, as you would do with an array.

---

I don't see what kind of control/analyze the VI analyser could do on icons. The few attempts made here about the icon not being surrounded by a full size frame are again inappropriate, since the icons were deliberately made smaller !

---

I don't know which comments were made, but if you're only getting a notification that the icons are small, that would seem to be OK, because you could have instances where that wasn't done on purpose.

[RayFarmer]

CC,

Naughty,  fancy not wiring in the error clusters 

Must be confident it will not error and/or others haven't got the automatic error handler disabled in the options.

Ray.

[RayFarmer]

CC,

"1/ I don't believe I have that much wires running under controls or structures, just because I take a great care of that. There are very few of them, and that was even deliberate, to simplify large diagram when some functions have no go-through connectors"

I think you are on a no win situation with this one, because some of your Icon don't use all of the iron area, you will still fall foul of this test as it seems to test for the whole icon area. Even though you have wires that seem to be in the open they are not. eg U32 Changed_ogtk.vi.

Ray

[chilly_charly]

Well, well... After Ben's post I knew that a few jealous would pop in and make a fuss of it ! 😄





Ray, I agree with you, the VI analyser requires clearly some carefull tuning to be really usefull.





Tst, the concatenate function was used as in the attached simplified vi. Don't see how I could have done better !.. I prefer to think it's a bug (quite Ray, I didn't say "mug"...) of the VI Analyzer. 😉

Message Edité par chilly charly le 09-29-2005 01:43 PM

[RayFarmer]

tst,

I think they mean, "if you know the size, declare the whole array outside the loop, then change the contents inside the loop".

Ray

[JeanPierre]

The comment would be appropriate if the string was fed to a SR instead of an autoindexing tunnel. In that case the optimisation is to build an array of strings and concatenate the array outside the loop.

[Ben]

Part 1 of 2 (?)

Hi CC et al,

"
I apologize. I should never have asked for your comments. As an "annoying thing", you are much worse than a bataillon of crazy frogs ! 

"

Thank you CC! Who would have ever thought that a cute little teddy bear with a twinkle in its eye could rival a crazy frog.

It appears that I am not alone in the opinion the VI ANALyzer is to LV as the Spelling and Grammar checker is to MS Word. It is capable of pointing out minor issues that may go over-looked. It still needs an intelligence to decide "What is Good" and "What is Bad". Think what Tom Sawyer, Moby Dick and W. Shakespear would have been like if they used a spelling and grammar checker!

The Pro wrote:
" wonder if NI uses this tool to grade LabVIEW certified developer exams?"
I lost points on my frist taking of the CLD Exam because I used the wrong text color and the "arrows" were distracting. If this not happen before the VI Analyzer was invented, I would have to agree. This makes me propose that if the VI Analyzer was grading math papers back in the 1880-1890 era it would have failed a kid that could not because of a multiplication error and would have ignored the scriblings in the corner that ended in "E=MC2". Come to think it, he did fail. No wonder he has been quoted as saying "Great spirits have always encountered violent oposition from mediocre minds"

Ray and CC,

This may be a good time for us to set the standards! And if we walk that path be forwarned that I believe there should be more than one standard.
1) GUI and top level - these VI must let you dive through the muck and find the nugget underneath. ListVIEW could handle some more comments and some graphic icons. Move controls to the events that service them and I am done splitting hairs.

2) Number crunching - My #1 excuse for a large diagram is speed of execution. Large number crunching VI's should a distict set of standards. If you really what to get the benefit of parallel processing and hyper-threading you have to put together code that LV can spot as distict code segments. If we use sub-VI 15 times on a diagram because the code is the same in each place, without going to "re-entrant" we have forced all of the 15 snipets of code to run in series. Number crunchers are more more "number centric" than other code. Often I do not even use error clusters in number-crunching VI's. In these types of VI's I attempt to make the biggest buffer the center of program flow to emphesize the delicate balancing act of "large data set" vs "Performance". This makes it easier for me when checking buffer allocations for the data that really makes a difference.

3) One time only - This is start-up stuff and order matters more than speed. Here more often than not there is a delicate ballet of setting-up and starting a set of sub-systems that depend on each other. Here the error cluster becomes a focal point for both order and the interdependancies.

End of part 1

Ben

[Ben]

part 2 of 2

I feel for you CC!

You have freely offered your time and talent to serve the LV comunity and a bear starts up a tread to tear you apart!

It is not easy opening up your work for others to comment. I hope we end up serving you more than we have hurt.

Let me share a story.

"Back in the Day..." when Greg McKaskle was still a public character he wanted to devlop a new presentation to help people learn how to devlop good code. He came up with the original version of the "The Good the Bad, and the Ugly". He then asked for volunteers to submit code that they were not happy with to be used as fodder. My contribution called the "Disk Pie Utility" was part of that show. Before it was over I thought I had been raped!

So to help share the agony let me put forth an idea that I am happy with that I think may benefit others.

When using property nodes in sub-VI to handle GUI updates, you end up with a lot of error cluster to deal with. It is tempting to just deal with this code in the same way you would have if the work was being done on the diagram of the GUI and just ignore the error clusters. Ignoring them is not always the best idea. Unlike ding it in the GUI there is the possiblity the reference are not valid because thet were nver wired up or the data type changed in the GUI. The attached screen shot shows one of theVI I use to update a part of one of my GUI's.

Let me point out that there are no comments in this code! Shame on me. Back to the point!

Mike Porter's "Error Fork Stacker.VI" and my "Up_Stacker.VI" make it possible to account for every error cluster with only a minimal impact on the code structure. I include thes here now in an attempt to help push the LV style envelope.

Feel free to pick apart my diagram! It is not "StarWare"!

Ben

Message Edited by Ben on 09-29-2005 08:13 AM

Message Edited by Ben on 09-29-2005 08:13 AM

[Ben]

Of all the bugs in LV this

http://forums.ni.com/ni/board/message?board.id=170&message.id=105455&jump=true

 has got be one of the most iritating!

Please note that I am actting on the same WF Chart as illustrated by the red circles. The second should act on 7-12!

Ben

Message Edited by Ben on 09-29-2005 08:21 AM

[tst]

Some nitpicking:

Think what Tom Sawyer, Moby Dick and W. Shakespear would have been like if they used a spelling and grammar checker!

Tom Sawyer and Moby Dick were both characters in books by Samuel Clemens (a.k.a Mark Twain), who also appeared on an episode of star trek, and by Herman Melville, respectively.

If I remember correctly, both characters could not write (especially the whale), so I don't think a spell checker would have helped them. Shakespeare should have an e at the end.

It is tempting to just deal with this code in the same way you would have if the work was being done on the diagram of the GUI and just ignore the error clusters.

That is a dangerous choice. Some properties can have errors even in the same VI (for example, selecting a non-existent active plot). You should be careful where you do that.

And while I'm nitpicking, the element in your cluster is missing a P (unless you want to measure the temerature).