Barrie

You've made some good points and there are a number of mechanisms already in LV (or almost there) that can be used to accomplish them. As for for and while loop labels, I very often use labels, particularly if they are nested. This brings up a pet peeve of mine. If you select the label to be visible on any structure, the label comes up with the less-than-useful information of 'For Loop" or "While Loop" and the label text is NOT highlighted to allow easy typeover, which is inconsistent with every other labelling function in LV. Sure, it's just an extra triple click away, but I already know it's a %*##* while loop! If I select the label as visible, chances are 100% that I want to change it to something more meaningful. I agree on the issue of WHY vs. WHAT but I think both are needed. -What I still feel that intermediate data needs a label, or more accurately, a signal name. Often, a number of wires are bundled together to be output as a cluster from a SubVI or as an input to a SubVI. One can (and should) assign signal names on the indicator cluster but that is after the fact, WRT the diagram. Further, any cluster element created within the VI can not be accessed using the Unbundle by Name function, reducing the diagram's understandability (unless, of course, the element is created using a labelled constant). Luckily, only one instance of the data creation needs to be labelled, when the data is being created in a case structure. Using labels at the data creation point also gives the convenience of automatically creating consistent labelled indicators when "Create Indicator" is selected. Backward inheritance of labels to unlabelled wires would be nice, but it would probably give the LV developers fits. -Why As I mentioned, there are (potentially) a number of ways to accomplish this. The description, or a tip strip can provide interactive information, but binding a visible label to a wire as part of the diagram is also important, so that the various signals can all be seen "at a glance". This is particularly necessary if the diagram is to be printed. I really like the idea of being able to switch descriptions/labels on and off easily. All of this applies to other objects on the BD that don't presently support labels or tip strips, like shift register terminals. You can never have too much documentation. How many times have we written a VI, assuring ourselves that everything will be self explanatory when we look at it a year later, only to find our "very clever" VI to be obscure at the very least? Of course, it's never happened to me, but I have heard about it. As intuitive as graphical programming is, the myth that LabVIEW is self-documenting is just that. Regards, Barrie

Hello all: I just have to vent, and I'm surprised that this topic has never been discussed. Allow me to start. People recommend labelling wires. Various style guides trumpet the importance of labelled wires. You lose points on your CLD exam if you don't label wires. We all agree that labelling wires is a huge step towards world peace and yet very few VIs I've seen (including NI's) actually do it. WHY Because there is NO wire label !!! :headbang: At present a wire label is just a free label placed over the wire, so heaven help you if you have to shift, modify or expand your VI once you have labelled your wires. You have two choices: - Label wires as you develop. This is when you have the clearest idea of what the most informative name would be. Labelling at this point is also a big help in testing/debugging. Then, as your VI develops and changes size, or as you improve the aesthetics you can chase all your free labels that don't line up and put them back where you think they should go. - Finish your VI, (knowing that you will never, ever have to modify it :laugh: ) and then label wires where you have room, if you have room and if you can remember exactly what each wire does. Mousing over with the wiring tool can get you a description, if you enter it. If the wire is connected to a control, you will even get the name of the data but that is usually self-evident anyway. It's the intermediate data that really needs labels, even if you chose not to have the labels visible due to space constraints. There! I'm done now. My medicine is taking effect. Barrie

I haven't found any USART in a PC that supports 9 data bits, but I implemented a serial interface using one of the bits in the parallel port and then doing the framing and synchronization in software. If you need bi-directional communication, then you will need to use two bits and write a transmission driver as well. You can access the parallel port using the Port I/O primitives in the Advanced Palette. A few things to watch out for: -Depending on the PC, the parallel port can be found at one of two base addresses. One is "standard" and the second, less frequent is often used in laptops. -The chipset controlling the port most often emulates the original chip, an 8255. It is programmable so you may need to access various registers at Base+0, Base+1 and so on, to change the modes available. - You will need to give the serial routines a high priority because there will be no hardware buffering. If the routine isn't running, you will miss data. I used a subroutine priority for a small part of the code which just look for state changes and then buffered the data. Sorry I don't have any specifics right at hand but connector pin-outs and register information is easily found on the 'net. It helps if you have some hardware and register-level programming experience, but it's not as tough as it may sound. I was pleasantly surprised when I found out how fast the final product was (~120Kbps), even though it was implemented in S/W, so 4800 Baud should be a piece of cake, particularly on a contemporary machine. This should give you a head start if you chose to take this path. Good luck! Barrie

Ask and ye shall receive. :laugh: http://www.geniusnet.co.uk/pages/english/mouse/m05.htm I've just been researching mice, after going through 3 MS Explorers in 13 mos. Barrie

Hello All: If my memory serves me correctly, the PRNG in either LV3 or LV4 had a seed input, which makes me believe that it was a linear PRNG. Two questions: 1. If this function propagates up to newer versions, does it retain the seed input or does it get coerced to the newer implementation? 2. If it retains the seed input, is there anyone out there who still have versions this old on their machines? 3. If so, could you please make a small VI and move it up to 5.1 or later and post it? It would be greatly appreciated. Cheers! Barrie

Hmmmmm... Looking at the methods and properties in German, does this mean you need a 1600 x 1200 monitor to wire a VI of any size? :laugh: Barrie

Oh yeah! I want one! I found it curious that the link said that NI had developed it, but the implementation/application was contracted to Iowa State. NI wasn't kidding when they coined the phrase "LabVIEW Everwhere"

Good eye Michael! And a picture just big enough to make everyone VERY curious. Barrie

Hello Sarah: The NIReports VIs are a limited (but very useful) implementation of HTML. Text has a font and a colour, tables have a whole different series of "tags" or attributes that can be applied. If you look at "append table" subVI, there is no input for fonts or colours. WYSIWYG. (What you see is what you get). If you wish to further modify the table, then you need to expand the capabilites of the table function. It's not as scary as it sounds. Of the many objects in HTML, most of them have many tags that allow you to change things as you like, just like methods and properties in LV, but with even more variations, and they are all text, bounded by <tag>. A lot of NI reports just assembles and concatenates HTML strings based on the inout values. HTML is found in more and more places. Learning about it is worthwhile. I would recommend that you invest in a book on HTML 4.0. The 'net is also a good source (as always). If you just want to modify a table, this site is a pretty good starting point for advanced functions, although I am sure there are many others. http://www.mountaindragon.com/html/tables2.htm. Gut Gluck! Barrie

Hi Sarah: I substituted "append text" with "append table" in "Easy Text Report" and wired the table data to the front panel & connector. Note that "append table" is polymorphic (text or numeric). "Print/Save" and "Report Type" can be a bit confusing. "Standard Report" always prints. HTML always saves. Your saved file is HTML, but it should have a lot more to it. Are you sure you have everything wired right? To view it formatted, just open it with your browser. (Firefox right??!!! :-) ) I've attached my test VI. When I start to play with a new feature, I always start with either a high level VI or an example. That lets me concentrate on the feature with all of the surrounding code already written. Often the exisitng code needs very little modification to become part of my code. Cheers, Barrie Download File:post-658-1116355254.vi

And a belated "Danke" Sarah. After an extended hiatus learning about things chemical, I'm back, (sort of). Geez! and I thought we computer types had a lot of acronyms! Barrie l

Hi Sarah: The refnum you refer to is probably the report refnum, created when you make a new report. For simplicity, you could use the "Easy Print VI Panel or Documentation" and just print the front panel and, presumably, your table. Otherwise, it gets a bit more complicated. It would go something like this: Create report Append table to report Print report A good starting point would be to use "Easy Text Report" and substitute "Append Text" with "Append Table" because the actual print function is not exposed on the palette and you have to dig for it. Note that when you append a table to a report, you have to pull the row and column headers using the property node and wire them to the Append VI. Cheers! Barrie

Hello All: I guess this is somewhat of a curiosity, kind of a poll. I have always tried to keep my diagrams to one screen, so I can view and debug without scrolling. As screens get bigger, with higher resolution, this of course has led to "diagram creep". Often this is a good thing, as method and property nodes tend to be hungry for real estate. The down side is that not everyone has a large screen, particulary on laptops, so even if it is hi res, it can be hard to read. Small diagrams promote more modular code, which I think is a good thing. Does anyone have any rules or guidelines, particularly in a multi-developer environment? Few companies can justify upgrading everyone to the latest and greatest. I look forward to your thoughts. Cheers! Barrie

Hello All: While re-org'ing my hard drive I found this little VI I wrote a while ago. I hope I'm not the only one that can't keep these properties straight in my head. Cheers! Barrie Download File:post-658-1107721251.vi

From what I've found, you're pretty much on your own. Some time ago, I was under the mistaken impression that CRC meant just one algorithm but I have learned that it is very much dependent on what you are interfacing to and what algorithm the manufacturer has chosen for "his" CRC. Various methods can generate CRC values of 16 bits or 32 bits, some operate bitwise, using a shift register, while others operate bytewise. An then of course, there is the polynomial, as you mentioned. I suspect the decision is based on CPU intensity and programming/math skills. I think that you would be better of to just write it, rather than trying to modify an existing VI, unless some kind soul has exactly what you need. Also, sadly, expect to write another VI when you encounter this need from another machine. Cheers! Barrie

I'm going to go out on a limb (from your username) and say "Feliz cumplea

Thank you for those kind words. What you did, by implementing that zombie, was to ensure that all possible outcomes were covered; something that we all should do, but realistically, it is very difficult, if not impossible to programatically account for all scenarios. One other issue about back doors or eggs that I missed, is that it can start a thought process in management of "Well, if he can do that what else can he ........" This, by itself, can create an environment of confidence in competence, or of mistrust. Regardless of the discipline, establishing rapport and trust is very important. (A little knowledge transfer doesn't hurt either ) Regards Barrie

This has been submitted to NI as a bug report. DeanDownload File:post-5-1097694319.vi 2298[/snapback] VERY strange ! The inside indicator, a probe and execution highlighting all show the constant 60 as being passed correctly. If the inside and outside constants are reversed, the problem does not occur. If the outside constant is changed to an array, enabling auto indexing, the problem goes away. No similar bug exists in the while loop. I'm amazed that this bug has only surfaced now. Barrie Download File:post-658-1097697369.vi

Personally, I don't think there is a big problem with easter eggs, providing they are relatively small. There is so much disk space and memory available for peanuts that I wouldn't be bothered if any developer I supervised conjured up an easter egg. People sign their names on all types of work and I think it is healthy. It signifies pride, and promotes a team spirit and a sense of ownership. It's also fun. Never forget fun. :laugh: As for back doors, which can consist of something as simple as an embedded password, I think it is a matter of practicality. I wrote an application that was VERY security sensitive, but had relatively unsophisticated users. If admin passwords were forgotten or wiped out, the system would emulate a brick if there wasn't a way to get in and wake it up. Presently I am managing another system that is also security sensitive, where the operators have limited access (intentionally). It is a portable system that is used internationally. If something screws up, I have two choices; I can use my back door over the phone, or I can jump on a plane and fly to Australia, China or India with a box of CD's for a couple of hours work, and lose 2 days of system productivity and 4 days (minimum) of my productivity. Management types will solemnly nod their heads when we talk about security, but when things go badly and the UberGeek is on holidays, the story (and priorities) change(s). For anyone who is paranoid, it all comes down to trust. There are 4 possibilites: 1. The developer(s) will not implement back doors. 2. The developer(s) will implement backdoors and notify management, for ethical reasons. 3. The developer(s) will implement back doors for practical reasons and not notify managers, for practical reasons. 4. The developer(s) will implement backdoors and not notify management for non-ethical reasons. If it is a big personal ethical dilemma, state your intentions, and justifications to the customer and come to an agreement on the approach (AND potential consequences) in writing. Regardless of any policies, there is little, if any, real control over back doors, if the developer is competent. There is even less control over back doors if the developer is competent and malicious. Generally, I think that there is far more risk from good old fashioned bugs due to insufficient testing, Murphy's Law, poor system architecture and poor developer selection than there is from back doors. Further, none the above scenarios compare to many, many small minded people out there that are KNOWN to want to do your system harm, if you are 'net connected. It's a question of balance and evaluation of risks and benefits. Just don't worry so much about terrorists that you forget to buckle your seat belt. I apologize for any rambling in advance, but it is a non-trivial question that I have struggled with in the past. Barrie

I back this idea 100 %. Error bars are an essential part of analysis, if you are serious about methodical and rigorous procedures. All too often, data that a computer produces to six sig. figs. (or more ) is somehow viewed as sacred and we forget that the sensor has a linearity of .1% and the A/D has a resolution of 1 in 4096. Barrie

Didier said: "I bring up this topic because I just installed LV7.1 on my computer and all the nice vi's referenced in http://forums.lavausergroup.org/index.php?showtopic=208 are now password protected! thumbdown.gif NI could really make the scripting tools avaliable for everyone, since (I checked) they are there since at least LV 5.1. If they kept hidden, because of fail-safe reasons, I think they are now quite good tested. Didier" I don't think it is an issue of code stability, but one of intellectual property and "letting the cat out of the bag". i.e It is a strategic decision, not a technical one. Sub-VI's are usually locked when the underlying diagram contains some kind of proprietary information. Previously this was often done by confining something clever in a .dll or a CIN, but as more of LabVIEW is written in G, locking it with a password is the best way to go. I would be surprised if we didn't see some form of scripting available in LV 8, but it will probably only be offered as part of the higher end developer suites or as an add-on. ($$) There is no free lunch . Some have suggested that some VIs are locked to protect us from ourselves but I rather doubt it, because there are some very complex and/or low-level VIs that are not locked, where one could find oneself in a heap of trouble, if you started messing with them. I have no inside knowledge nor a crystal ball, just my $.02. Cheers ! Barrie

You can follow my reply in LabVIEW>Programming Discussions>LabVIEW Scripting Cheers! Barrie

I don't know if I can help you if you must use assembler, but I think there is an easier way and you can do it in LabVIEW. I have written a number of serial and parallel port drivers at quite a low level but the VI's you need to do it are not exposed. There are two libraries, sersup.llb and serial.llb located in ...LabVIEW 7.1\vi.lib\instr These are legacy libraries that have been replaced by the VISA Serial functions. You can also read and write to the USART directly by using Port I/O functions located in the Advanced palette, but this means you need an understanding of the base port address of the USART and documentation for the registers and their address relative to the base address. I believe the PC chipsets still emulate the 8251 USART, but this information is readily available on the web. If you can tell me more about what you are trying to do, I might be able to help you further. Cheers, Barrie

OK, OK ! I Get it. Sheesh! Tough crowd. :laugh:

Heck! I haven't even got XP to run the way I want yet. One of the things I have to get around to. The thing is, everyone test their pages on IE. A lot of people are recommending Opera. ???? Feel free to jump in everyone! (like you guys need an invitation :gathering: ) After all, this is the lounge.