lecroy

I ended up with something similar as my previous post but when the graph is zoomed out, I now slice the data into subsets then run a min/max on it. I then stitch this min/max data back together and pass it down. Similar to how Labview does it, or a peak detect on a scope. Once the user has zommed in far enough, I switch over to sendind a subset of the data. Where the graphing was in the 250 - 500mS range, using this method, its now in 50mS range. I was trying to get about 10Hz screen updates. I wrote these functions in Labview so I would assume if it were wrote in C it could be further improved on.

I had made sure there were no non-present mapped drives (non found). Then tried it with the network cable pulled. This appears to have no effect on the same times. I wondered if it was not sending the whole project to NI on every save as slow as it is. What ever the problem is, I saw a pretty good hit going to various versions of 8. 9 has made things much worse. Lots of free disk space on PC. Some programs that are very small can take much less time to save than a much larger program. I have one small program that has no graphics and all the arrays are cleared but still takes 10s of seconds to save. The program I am working on now is a huge cluster with several sub panels, graphs, ect. This one will save in 5 seconds or so. Not fast but at least not thinking to get a cup of coffie on every save. It's strange.

I use the old style graphs with antialias turned off to get Labview to run at a fair rate. I scale the X axis and it may not be a linear function. I would like something even faster than this and was trying some different benchmarks to see if there was any way to improve on it. What I am finding is that the graphing is not the worst offender. It's getting the data into the right format to send to the graph that takes most of the time. One way to get around this is I look at how the graph is scaled, then only work on that subset of data. This way when I am zoomed in, at least we get some speed out of it. What I wonder is if there is a better graphing method all together that is smart in how the data is processed internal. So the graph would take the entire data set and compress it down depending on screen resolution, amount of data being displayed, etc.

I have noticed a major increase in the time it takes to save a VI with the new versions of Labview. If I make no changes to the pannel and just select save, times can be in the order of 20 seconds. I am using 2009 with the latest patches. Load times are also very long now. Is there some new wizz bang feature that could be turned on that is making run this slow? Newer PC, 64-bit OS, 8 Gig of RAM.

Been a few days so figured I would see if anyone knew of a trick for this. Looks like bit packing is not something people use. Using the MSVS 2005, optimized for speed, release the time to run this function is now in the 30mS range. Much better than the two and a half seconds I saw using the array decimate function. This is good enough for what I need. The updated benchmarks packer_new.zip

I wasn't really looking for a how to do it as much as if they had a function like this already built in. An interesting side note, I plan to just code this function in C and be done with it. Before I did this, I wrote the function the same way I plan do code it but in labview. For fun, I benchmarked this and it cut the time in half. A couple of quick tweeks got it into the 200mS range. Not bad considering where I started but not good enough to be useful. C still has it's place.

I am using the latest version of Labview 2009 with all of it's wizz bang super functions. What I am attempting to do take an array of 32-bit data and convert it to a different size. The data is packed. So, for example say I have an array of UINT32 numbers and I want to convert them to 18 bits. The first number would be represented by the first UNIT32. The remaining bits are the start of the next number. I tried to flatten the 32-bit data to a 1-bit array and then decimate the 1-bit array to form multiple bit arrays of the target size. I then convert these back to single numbers. It works but is very slow. The quickest conversion we have found was using the replace array subset. I have attached the example. On my PC, this takes about a half second to run, not including the time to create the dataset. I need to get this down into the 10-50mS range. Is there a slick way to do bit packing and unpacking in labview that's fast? DMAunpack4c.vi

There's a typedef labview? It's a new feature for 2009 and was not present in 6.1, 8, 8.2, 8.5 or 8.6. To be honest, my Labview code is sloppy at best (by my standards). I use the tool for rapid prototype work where I need to get things working fast. Coming from the days of using BASIC to write test scripts this tool has saved me countless hours over the years. (even when LabWindows was available, BASIC was still my choice) That said, one of the benifits with Labview is that it allows me to be sloppy. The save program defaults feature is one of those features that allows this. Those of you that initialize everything, more power to you. Surely this is the right way to program and the save defaults should be removed. For the tab menu bug, this is a work around for 2009. Consider that I am not a software programmer by profession. Labview is just another tool in my belt. Anything that NI does to the tool that saves me time is a plus, no matter how sloppy it allows me to program.

Agree!! It's interesting (as mentioned earlier) that when I save the defaults, just loading the VI it will stick. So, for my case the problem appears to be related to building. Strange.

Your entitled to your oppinion as am I. Unfair is paying for all the licenses and then getting this sort of quality. The interface is going down hill fast and for what? Is it making me more productive? No. I call it like I see it.

I do not run the Labview programs on the XP-64 machine. They are only developed on it. I have no scripting programs running. As a matter of fact, I shut down everything when using Labview. Previous versions of Labview Undo work fine on this same PC. This is a new feature for 2009. Something they decided they had a better way to impliment and did not do a good job of testing.

Nope, no MathScript. It must be something else causing it. My Labview designs are normally very basic. If you know of a way to determine which functions would be the offender, let me know. When it was running the build the first time, it did not say what function caused the problem.

Because there are so many versions of each OS, like Vista and XP ... I am running XP Pro 64-bit, Version 5.2 SP2. Erase two wires, can only get one back. Erase two locals, can only get one back. Move two items, can return both to their original positions. Erase one wire, move one item, can return item to original position but can not get wire back. Did not do a lot of testing on this but it appears related to the erase. Remember when there was no undo?? At least this new version doesn't take me back that far.

That was already covered above. Renamed INI, restarted LV. It created a new INI with defaults. Undo is still only one deep. My guess is it's inside the Labview code. 2009.1 will be out soon.

Another person here is going to install it on another PC. We will see if they have the same problem. Could be NI has something against our company and not just me.

Could be but I doubt it very much. Are you using Version 9.0 (32-bit) for Windows? Under the options, it is set to 10 per VI. The following is my current ini. [LabVIEW] IsFirstLaunch=False menuSetup="default" saveFloaterLocations=True find.viListFlags=4 LastErrorListSize=0,0,379,484 paletteStyle="NamedIcons" RecentFiles.pathList="xxxxxx" SaveChanges_ApplyToAll=True PropPageBounds="1672;292;2168;751" ScaledToFitVisible=False ScaledToFitLocation="84,67,859,1043" enableAutoWire=False autoRouteWires=False ShowConstantFolding=False ShowConstantFoldStructs=False postScriptLevel2=False FancyFPTerms=False NoAdvice070=",FlatSequence" SnapGridShowsOnFrontPanel=False FPFont="0" 13 colorHistoryItemA=00A0F8FF colorHistoryItemB=00E8FF2A colorHistoryItemC=00FF0000 colorHistoryItemD=00730000 colorHistoryItemE=001E4B00 colorHistoryItemF=0064FF00 colorHistoryItemG=00FF0001 colorHistoryItemH=00B3B3B3 colorHistoryItemI=00FF1231 colorHistoryItemJ=00000E42 colorHistoryItemK=006C8292 NewDlgRecentMainTemplates.pathList="" NewDlgBounds="800;600" NewDlgRecentTemplates.pathList="" NewDlgLastSelected="A09C6440-BBD9-4508-9462-C3AAAD503B2A" NewDlgSmall=False NewDlgCollapsed="77E350A8-F9AA-43FF-85E2-454279EBB9A7" LLBMgr_ActivePlugins="" LLBMgr_RecentPath="xxxxxxxx" ProjectExplorer.ClassicPosition=29,1427,429,1757 AutoSaveEnabled=False SnapToPresetsBD=False SnapToPresetsFP=False autoerr=2 LogFileSaved=True LaunchConfigurationPageAfterDropExpressBlock=False autoInsertFeedbackNode=False StructuresAutoSizeByDefault=False ShowRedXOnWire=False transparentBDLabels=False recentUserName="xxxxxxx" RecentFiles.project="xxxxxxxx" ShowPathInProjectWindow=True ProjectExplorer.ProjectItemsColWidth=254 editRecentPaths="xxxxxx" toolPaletteLoc=880,1147,1029,1225 autoToolOn=False maxUndoSteps=10

This was not in the ini file, so I added it. Then restarted Labview. Same thing, only one undo. Does yours work?

You have got to be kidding me. Undo in 2009 only goes one back? I guess this new feature was to make me less sloppy and make less mistakes? What the heck is going on inside NI now days?

Dang, I just want the features that have worked for so many years to stay working. I should not have to do Beta testing for a company to get a quality product. They should be performing regression tests. For a demo, what do you want to see. Just a VI with a menu, then the same after being built? Should be pretty simple for you to do. Just set your tab defult to something different then build it. It will not stick.

I believe the verbiage is tab control. I use the modern ones as they have some features (like color) that the classic did not support. I am not sure if the classic tab menus have a problem or not. Stupid bug and surprized it was released with it. Then again, quality does seem to have taken a back seat to features with Labview. Note to NI's Labview development team: As an end user, could you please see if you can slow the next release down even further and maybe make it crash a little more often. I am still too productive with it. Thanks.

I may have have the case number but to be honest, I don't think its the customers job to keep track of the supplier. It does make for a good excuse. We didn't do anything with it because you didn't check in once a week on the status.....

It was posted on their site and called in. Talked with various support people at NI. Replicated the problem on their end. Ran 10-20 tests for them to try and nail it down. Was then handed off from the techs who answer the phone to the developer's group. I just assumed they would do something with the time I invested to try and help them make a better product. This is going back more than a year.

So, it appears that someone decided that this feature had not been mucked with enough and needed some improvements in the 2009 release. What I see is when I set the defaults, I can reload the VI and they stick as they have in the past, which is a good thing. With the 2009 release they have this new feature where after you build the program and run it, the defaults change to, well, I guess what NI feels they should be. I am sure they are trying to help me. Is there a way to get the defaults to stick when using the builder as they have in all the previous versions of the builder? Just looking at what the real problem is, it appears that they missed the tabbed menu defaults.

That's it. You just saved my digestive track another hole.

I installed the new Labview and thought I had selected everything. Once installed, I tried to build an installation. It asked me to install DVD x because it is missing some files. Now, the strange thing is that it was looking for some RT something file. I have no real time anything in my design. Once built, the EXE was double the size of the older Labview. Impressive.