Louis Manfredi

Hi Clbst47: Yes, you can do it. Application control>Menu>Current Vi's Menubar will allow you to put a reference to the current vi's menubar on the block diagram. On the panel of your Sub-vi, you can insert a control that you can wire up to this reference (Controls>Refnums>Menubar Refnum.) Then you can put whatever menu control stuff you want inside the sub-vi. Can reduce a bunch of clutter on the Main Vi's diagram. Can also save a lot of work by having the sub-vi used by many callers needing similar menu service. I've used it to great benefit for both. Easiest shortcut is to start with the menu stuff on the main vi, select what you want to put in the sub-vi (not including the Refnum constant) and then use create sub-vi. Be careful about trying to do two things at once with a menu-- most cases were this is a bad idea, with unpredictable results. So be sure to always daisy-chain menubar out from one menu operation to the in of the next operation. This might mean that you need a menubar out indicator on your sub-vi. (I think you might be able to save the menubar as Global, but that's a really dangerous idea. Even those of us that like Globals for some purposes cringe at this & I hate to think how the no-globals-ever-no-matter-why guys would feel about it. Good luck, hope this helps.

Hi Nistam: I agree that you should be O.K. -- assuming that LabView does what it should do in terms of releasing all the memory used by the OPC reference when you close it. As far as I know, no reason why you should have to use a shift register for the reference to the serial resources-- obviously things can change on the port itself, but as far as I know the reference to it remains unchanged over its lifetime, so there's no need to make it a shift register. Anyone else disagree? Make sure you haven't inadvertently enabled auto-indexing for the serial port reference (or any thing else) as it tunnels into or out of the loop. (I once had a nasty problem related to an unintended auto-index-- Its amazing how much aggravation a worn out mouse that transmits unintended double-clicks can do. ) At any rate, good luck on the problem.

I don't see why minimal error trapping should cause the error-- though error trapping might find the error or make it easier for you to find it. I wonder whether you are creating a new handle, or reference to some resource (the serial port, the OPC server, or something else) each time inside your loop, and failing to destroy that reference when you are done with it. That sort of error can cause a program to gradually soak up all available memory. If so, if you can, better to create only one reference, and use it over and over. Second choice would be to create an new reference every time, but be sure to close the reference when done with it. Hope this helps, in any case, good luck!

I run my monitor at 1600X1200, but I try to keep my diagrams to 1024X768. Sometimes I let things slip, but rarely beyond 1280x1024, in case I have to do troubleshooting on site with my laptop. I used to let myself scroll to the left and right for initialization, error handling, cleanup and some constants (like format strings, etc.) --enforcing the "no scrolling" rule only for the main running part of the program. Recently however, I've been tending to do things as state machines, so initialization, error handling, and cleanup end up as states on a case selector diagram rather than requiring room on the screen right or left. It took a long while for folks to convince me that sub-vi calls are very efficient, but now I believe, and I really use sub-vi's whenever the diagram begins to get cluttered. (It got a lot easier to keep tidy when the "create sub-vi" feature came along-- Even if I didn't anticipate that something was going to get complicated enough to rate its own sub-vi, its easy to fix.) A C++ buddy never lets his routines go beyond 80 lines of code-- If a routine doesn't fit on a single sheet of printout, its too big & needs to be divided into subroutines. As my short term memory gets shorter, seems like a good plan-- In my LabView routines, if something is out of sight, it is in a sub-vi, with a labelled icon & with labelled controls-- I may not remember exactly how it works, but I know what it takes as input, what it gives as outputs, and the icon gives a clue as to what its supposed to do. Compare this to a bunch of wires running off the left edge of a window, which likely as not have some cryptic hot tip label like "x*y". Best, Louis

Hi Michael: I've struggled with similar problems many times, and with several versions of Windows. Following suggestions are not specifically relevant to XP, (and may not even be helpful with XP) but they have helped me in the past: 1. Uninstall any networking drivers for networks you do not need-- Especially if the physical network associated with the driver is not present! Previous versions of Windows took much longer to service network drivers for missing networks than for those that were actually present. Not sure if this is still true. Also, not sure if it is true for drivers related to USB or Fire wire I/O devices that are not present, but it wouldn't surprise me. 2. Turn off automatic file compression & similar "nice" (but not essential) features of the OS However, it seems like no matter what I do, Windows will occasionally wander off to do some time-consuming and (to my mind) unimportant housekeeping task while I'm trying to do something time-critical and synchronized to the real world. It just isn't a RTOS, its better in this regard than it used to be, but it seems like it will never really replace LVRT (or other RTOS's) for the timing critical stuff. I too am very interested in hearing all the other suggestions you can collect on this topic! Best Regards, Louis

Hi Zeus: One Way: Create a property node for each graph (Right click on connector>create>property node.) Right click>Change the property node to write. Right click>Select property> Select the "History" property. Wire a empty array constant to this property node (Right-click on it>create constant.) Do this for every graph, and put all these in a sequence structure so that they are executed when you first run your program. Best Luck, Louis

Hi Rrojas: Here's the promised link, As I thought, the lookup table method is motivated by efficiency- see section 9 of the following reference: ftp://ftp.rocksoft.com/papers/crc_v3.txt (too make things clear, thats crc-underscore-v3.txt) Hope this helps, & Best Regards, Louis

Hi Michael: Here are some of the easy things you can do to tighten up Serial communications: 1. Turn off the FIFO buffers for your serial port. In Windows XP, one path to this is: Control Panel>System>Hardware tab>Device Manager>Ports>COM1(or COM whatever)>Port Settings>Advanced...>Uncheck the Use FIFO buffers checkbox. (While you are in there, click on the resources tab of COM1 and make a note of the I/O range setting for the port. If you are really desperate, you'll use that data to bypass the operating system and control the port manually, more on that later.) 2. (Now obviously this is something you might NOT want to do for other reasons, use your judgment, and only do things you ar certain you can reverse...) Uninstall all Network adaptors and drivers especially for types of networks which are not connected. Windows spends lots of time, and quite often, checking network connections. I've heard-- though I never checked this out myself-- that it takes more time looking for network connections that don't exist than serving those that do. (Thank you Bill Gates... :ninja: ) 3. Try to minimize background processes. Turn off automatic file compression. Don't run other applications while you are running your program,especially MS Office applications-- They bog thing down by taking huge amounts of memory, and some processing time, even when they are in the background. Virus checking is another background process, but I'm reluctant to suggest you shut that off-- unless you have had a recent scan, and are sure that your machine is isolated from sources of infection while you have it shut off. Make especially sure that any application which might be trying to share your serial port is firmly shut off. 4.Put a Priority on your application with the system scheduler. For XP, one path to the setting is: Right-click on My Computer Icon > Properties>Advanced Tab>Performance settings button> In the Visual Effects tab, click adjust for best performance (If your current settings are "Custom" and you like them, make a note of what is checked first!). Then, in the Performance Options>Advanced tab, select "Programs" button for both processor scheduling and Memory usage. (These settings seem to have far less impact on things than I recall from my old days working on Macintoshes-- there you could really make the OS take a back seat to the job your were trying to get done... As far as I know you can't really do this in Windows. (Again, :ninja: but if someone else knows different, speak up, I want to know how too!) 5. Use the VISA read/write VIs rather than the older Serial vis. (Looks to me like the older serial VIs are gone from the menu in version 7.1.1-- I hadn't noticed when they disappeared -- for a while both were present.) The old serial VIs relied more heavily on the high-overhead operating system while NI did some more efficient programming of their own to implement the VISA routines. If it seems like you have choice, try the VISA routines. Medium difficulty things: 1. Check basic LabView Programming style-- Understand the priorities on any potentially competing VI's which may be running in parallel. Make sure that you have put delays in all your User Interface routines. (If you are updating a digital display, it doesn't need to be done more than once every 200 ms or more-- most of us can't read that fast. For analog displays tachometer dials, etc) updating every 50 Ms or so should be plenty to make needle movement seem smooth (assuming the data displayed is coming to it smoothly. 2. Do a timing budget on your comm channel-- probably not your problem, as you are probably dealing with simple short messages, but good habit to get into. Take the number of bytes in your outbound and inbound messages, add them, multiply them by ten, and divide by baud rate. Add the latency of the device that's sending you the data. Draw a timing diagram. If there's a problem, increase your baud rate if you can, make your messages shorter if you can, look at changing the order you do things for efficiency. For example the straigtforward: Poll for data>Wait for data>Receive data>Process data>display data approach puts things strictly in series. You might want to: Poll for Data Frame n>Process data frame n-1>Display data frame n-1>finish waiting for data>Receive data frame n. This puts some other tasks in parallel with waiting for the data to come back. Difficult approach: You can write directly to the serial port, using the "Out Port" and "In Port" Vi's and the port addresses you got from the COM1 resources tab. You only want to do this if you really have to. Its considered pretty poor style, but I've found occasions where it was the only thing that would work. If this is a class assignment, check with your professor first, he or she probably doesn't want to get into this level of detail. If you really need to do this, back up your system first, you'll be treading in the minefields of register programming. Then look up the data sheet for the 16550 UART, or see chapter 12 of "The Undocumented PC" by Frank van Gilluwe, Addison Wesley, ISBN 0-201-47950-8, or check with me if you can't find the references. Using this approach I have been able to transmit serial messages usually (but not always) within a few hundred microseconds of when I wanted to, and to transmit serial messages on multiple ports almost always within a few dozen microseconds of simultaneously to each other. In any case, best Luck, Louis

Also, be very wary of trusting Windows to do anything near promptly with serial comms. It Might go off and do routine housekeeping, or whatever else it does that takes time, and spend several hundred milliseconds doing pointless stuff before it actually gets around to putting your message out the port, or reading the incoming message from the port. If you think this might be your problem, let me know. I've struggled mightily with this issue :headbang: :headbang: and I can discuss at (much) greater length if you think that this might be your problem. There's fairly easy things that help a fair amount, but it gets pretty tricky to get comm timing on a regular serial port down to the microsecond. Any possibility of doing both jobs on a single machine? Nah, I suppose you would have if you could have. Best Regards, & Good Luck, Louis

Hi Rrojas: As I said in the comment on the front panel, I translated this routine from a C routine written for the equipment I was talking to and ---Mea Culpa--- The rest of the story is that when I made the translation I understood the algorithm only partially, and documented it even less. (The routine was a small part of the project, it works, so I moved on to other issues which were more troublesome.) As I understand it, the lookup table is equivalent to some of the calculations which appear in the classical methods, but takes less time. There was a time when that was an issue, and I suppose if you are running a really fast comm. channel, it might still be an issue. I seem to recall that the reference my colleauge got the routine from described how to change the lookup table to match different types of CRCs. I'll see if I have a copy of the reference anywhere-- might be Monday before I get a chance to look. If I can't find the reference I'm sure the colleauge who wrote the C code has a copy & I've been meaning to get in touch with him anyhow, so I'll check with him if need be. Just goes to show, there's no such thing as a self documenting programming language, is there? Best regards, Lou

Here's yet another CRC routine. Seems to give different outputs from the ones Michael found. But it might be of some use. I extracted it from a more complex set of comm. vi's that include byte stuffing for eight bit data transmission, multiport near-simultaneous message transmission, & a variety of other features unrelated to the question at hand. Best Regards & good luck, Louis Download File:post-1144-1103205210.vi

Hi Rojas: I think I got a CRC routine kicking around somewheres-- give me a day to look for it before you waste the time duplicating the work. Best Regards, Lou

Happy Holidays to all. Attached is sort of silly in a nerdy way... ... or perhaps its nerdy in a silly way. Either way, Happy Holidays! Louis Download File:post-1144-1103125777.vi

Hi Racer: Haven't got a LV bisection solver handy-- But here's some hints on avoiding the case structure & formula nodes-- To avoid the case structure, use Select from the Comparison menu. (Picture attached-- not always an efficient thing to use, if there's lots of calculations leading up to the choice not selected, but in this case were the chosen & non-chosen values are already calculated anyway, a good choice since it is nice and readable.) To most easily avoid the formula node, (and probably best in anyway in the interest of generality) write the function you wish to solve as a Sub-vi to be called by the main vi. If no one else posts a solver from their archives, I might get a chance to sketch one out for you later on. Best Regards, Louis

LV 6.1 should have all the right-clicks you need. One tricky thing with arrays :thumbup: -- if you right click on the array container you get one set of options, if you right click on an array element itself, you get another. (In order to change the variable type, you want to click exactly on an array element, not just on the overall array graphic.) In this case, your use of the array initialize is better anyhow, since that way you can more easily (even at run time if you want) change the number of bins in the array. You should be able to right-click on the legend for the graph, and pick bargraph display. (See the attached picture.) Then, in a nearby area of the popup menu, select Interpolation>None to turn off the lines between the points. Best luck, Lou

Hi Racer: I'm also a devout HP RPN calculator user, have been since my Bowmar Brain decided to quit the night before my first hour exam as an engineering student in 1974. On my 4th HP now, or maybe its my 5th, a 15C--- Given the price of a replacement on eBay, I hope this one lasts till Hell freezes over, or at least till I retire. Nice thing about the 15C is that it does what I want it to without any fuss, so I don't need to belong to any user's groups for it. I have used RPN in LabView too-- needed to give a client a flexible user-programmable tool for doing math on the data his program was collecting, so I wrote an equation parser that reads and executes RPN. (Writing homebrew interpreters ain't for the faint of heart, but if you're going to do it, RPN is the way to go. I think NI has added a parser to LV itself since I wrote that code, a good thing.) Welcome to the LabView world-- very different from RPN, but in a funny way it fits the RPN temperament, so I think you'll end up getting along fine with it. Best Regards, Lou

Hi Alexum: Looks like Todd has answered the questions, but if not or if you have more, let us know! Best Regards, Lou

Hi Alexum: There is a binsort function (From the wiring diagram Functions>Analyze> Mathematics> Probability and Statistics> Hisogram.vi. Unfortunately, depending on your data sample rate and duration of the file, it might be very ineffiecient to display the data in real time as it is collected. A somewhat better approach, that displays real-time, but avoids storing an array of all the samples which continually increases in size, is shown in the attached picture. (I hope the picture is attached, I don't see it in the preview, but I'll get it to you in a later post if its missing.) I know there are more elegant ways to do this, but what I'm showing should be at least reasonably efficient and conceptually simpler for the new user than some of the other approaches. I've left out some details, handling off-scale data, might need to add 1/2 to the scaled data to get bins centered properly, etc. but the sketch should give you a starting point as to how to proceed. I'm working in LV7.1, and don't have 6.1 installed anywhere now, but I think most of the features I'm using are available in 6.1 too. Hope this helps & Best Regards, Lou

You can Highlight the text of one of the legend entries, then click on the "Text settings" button in the menu bar. One of the choices that pops up will be Color > this will let you change the color for the text. Far as I can tell, all the legend entries will have the same color text, and there's no way to do this programatically. Hope this helps, Best Regards, Lou

I've needed to do the same thing. Only way I've found to do it is to save the data that I want to keep-- For example by passing it to a shift register in the for or while loop-- and then bundling this old data with the new data to which I want to make the comparison. Perhaps there's a more elegant solution, but this method is probably more efficient than using a bit map, and I suspect handles things like rescaling of the graph more gracefully too. (To get really complicated-- if you use Max & Min function from the comparison menu to generate two historical traces, on the minimum of each time sample from all past traces , and one the maximum of each from all time, and then play around with the "Fill Baseline" plot properties for these traces, you can get something that looks very much like the display on an old anlog storage scope...) Hope this helps...