Ed Dickens

The Match Pattern was inadvertently removed from the LabVIEW 8 PDA palette.

NI support response can be read here.

The function can be "borrowed" from a Windows VI that is open and still works. Just drag it from the Windows VI to the PDA VI.

Ed

The Request Deallocation seems to deallocate the shift register. When you run the vi again, the shift register is not re-allocated properly. I don't think this has anything to do with the match pattern function.

It seems to be a problem with the combination of a shift register and the Match Pattern function. In this modified version using the Scan String for Tokens function, it seems to work OK.

Download File:post-47-1131995591.vi

I can't figure out what's going here. It' seems to be some sort of memory allocation issue.

The first time I run the attached VI, the Time Stamp converts correctly to a LabVIEW Time Stamp. Subsequent runs without closing the VI result in the Match Pattern function not finding the colon and not converting the time corectly.

If you run it with Highlight Execution on, you'll see the Match Pattern function does not find the first colon and outputs a -1 on the Offset Past Match terminal which stops the loop, as it should after it finds the last colon.

If I close and reopen the VI, it runs correctly the first time, but again incorrectly after that.

We've managed to find two things that will make it run correctly without closing.

If you make either of the array index controls larger, as in able to display a larger number (stretch it to the left) it will again convert correctly once.

What seems to fix it for good is to either remove the "Request Deallocation" function or change it's flag to a False. So this seems to be the root cause of the problem.

We've verified this on two WinXP Pro SP2 PCs running the downloaded version of 8 activated as the Pro version. I saved it back to 7.1 and it works fine there.

I've reported this NI and I'm waiting for a reply.

Ed

Download File:post-47-1130874110.vi

Hi, I want to create a VI that performs matrix multiplication for two input matrices A and B. The matrix A is an n x m matrix and matrix B is an m x p matrix. I want to create the VI without using the AxB.vi in labview. Anyone can help please? :!:

I've created some Matrix operations just using 2D arrays and For loops and a combination of Auto Indexing and manual indexing to get the correct numbers.

I don't have any that do the specific operation you're looking to do, but it's really not that difficult to put one together.

Ed

I'm sorry that "sine wave" should be wire to the "Local variable of the waveform graph" instead of directly to the terminal in the Local Variable version.

In the Property node version, it will not continue running until you selected an option of the right-click popup menu when the program display waveform. However, the Local Variable version will not.

The attached figures show the code differences between this two version:

Overall, you'd be better off using the Local Variable as long as you are only writting the Value to the termial. And still, only do this if you need to. Otherwise always wire directly to the terminal. Also, if you're writing to the terminal from several locations where you must use variables, wire to the terminal in one place, never leave it unwired. Try to pick the one that where it will be written to the most.

Local Variables are a bit more efficient than a Property node, but if you're also writting to another property of the node, you might as well use the Property node for both the Value and any other properties. Local Variable cause a copy of the data to be created in memory. So if you're constantly writting a large array of data to a variable, you're constantly making copies of that array.

A property node makes a copy of the data as well, but it also forces the application to switch to the user interface execution thread and update the front panel. This could be part of the pause you're seeing, but it still doesn't sound likely.

I've never seen this pause happen and I still can't duplicate it on my PC.

Ed

When I use "Right Popup Menu",there are some differences between "Local Variable" and "Property Node".The "Property Node" will cause program "Pause",but "Local Variable" will not.

Are we talking about the node in the bottom loop in the Start Case?

The first question I have to ask is why are you considering using a Property node instead of just wiring directly to the terminal (not a Local Variable) like you have in the Local Variable version. There absolutly no reason to do this.

Not considering that, I've played with both version a bit and I don't see this pause happening with the property node. Could you give some more details on what is happening?

Ed

So hacking gurus... U guys have got some work to do...

I seem to remember that those same ini keys worked in at least one of the beta releases. But could have easily been changed for the last beta and changed again for the shipping release.

So we'll probably have to wait until we get real copies to see if can get the keys from that.

Ed

 

yes, but even if it's padded with 0's, shouldn't "=" still return true? 

5455[/snapback]

 

If it's all zeros out to the precision of the number type, then it should equal.

The problem comes in looking at what's displayed and what it really compared. The front panel display might be showing 1, but what's really contained in the control could be something different depending on what the display properties are set to.

Try this.

Create a new VI and drop a standard numeric control on the front panel. Now type in "1.000001" (that's 5 zeros) and see what happens when you click somewhere else on the panel to enter the number. It's now just displaying a 1 instead of the entire number you typed in. The entire number is still there, it's just not being displayed correctly because the default display properties only show 6 Significant Digits and hide the trailing zeros. (a bad default choice by NI IMO) Now create another control and just enter 1. Compare these two with the equal function. Should they be equal?

Remember, the display properties are not the same as what the diagram wire is carrying. Engineering calculators work the same way. You can set the display to just show 3 decimal places, but the operations work on the entire number, not just what is displayed.

Ed

Hey all,

i set up a program to read in from an excel file(using tab-delimited), and it seems to read into the arrays just fine. However, i need to look through the first column(of two) and pick out two values. I altered the read in vi for pick out the column, and it seems to be when i go through it after the vi runs. The problem with the vi occurs when it is comparing the values in the column array to the entered numbers. I have set probes to check the numbers being sent(and while it says that they are the same) the "=" doesnt recognize them as being the same. Attached is an example of what im trying to do. 

any help would be much appreciated, as this is driving me crazy.

thanks,

jesse

5438[/snapback]

Comparing fractional numbers doesn't always return what we think it should. The decimal presision you are seeing in the probe is not the entire number, it's just it's set to display.

Try creating a couple indicators on the front panel and set their properties to show 10 decimal places (or more if needed) and see if they really are equal.

Ed

"Working on code like this is like trying to overhaul a car engine that has been welded together"

You're not going to charge royalties for using that line are you? :thumbup:

I refactored an application about a year ago that was originally written in LabVIEW 4 and had been slowly added to over it's 7 year life. Needless to say it was a monster. It's only good point was that there were decent comments on the diagram.

It scrolled up/down about 5 screens and left/right about 3 on a 1280x1024 monitor. Not a single control or indicator was wired to anything. All data was passed through either local or global variables. There was almost 250 local variables and about a dozen globals with several controls on each. There were nested sequence structurs, a couple 5 structures deep.

I'll see if I still have the original and post a screen shot.

Ed

Assuming nobody has changed the default system temporary directory location, you could use the "Temporary Directory" path function, then use the "Build Path" with a relative path of "..\..\Application Data".

Example is attached.

If you want to go a different path, I believe you can also dig it out of the registry.

Ed

Download File:post-47-1121271914.vi

With the Auto Tool turned on, press and hold 'Shift+Ctrl'. This brings up the Scroll Window tool (the open hand). Now you can click and drag (anywhere on a blank area) the window contents around on the either the front panel or block diagram.

Of course none of us should ever need this short cut because none of our diagrams ever get larger than a single screen.

Ed

Here's one that may be a bug, or may be just something to watch out for.

When updating properties of a table, it takes longer to process those update depending on what part of the table is showing on the front panel.

Looking at the attached example, it just populates a table with 1023 rows and 25 columns, sets the row headers, then changes the background color of one of the columns. Setting either the foreground or background color causes the problem. Setting a different property does (like Cell Size) not seem to cause any problems.

Before setting the color, I turn on "Defer Panel Updates", then set the color and turn off the deferring. Doing this alone cause the color change to take about 7 seconds on my machine if you have the end of the table displayed (scroll all the down). Also note that if you are displaying the middle of the table it takes about 3.5 seconds to update. It seems somewhat proportional to the displayed position. It also has the same effect if you scroll horizontally.

If you have the start of the table displayed, it takes about 300ms.

If in addition to deferring the panel updates, I set the Index value to 0,0 it takes the 300ms.

It has this same problem all the way back to version 6.

The zip file has 4 versions of the file for LabVIEW 7.1, 7, 6.1 and 6.

Ed

Download File:post-47-1114100834.zip

I still think it's a bug and NI support agrees.

If this were intended behavior, then shouldn

I've submitted this to NI along with Michaels workaround with the property node. Interestingly, reading the value from a local variable shows the same problem as reading it from the button.

I'll post any replies from NI.

Ed

UPDATE:

A quick response from NI on this one.

Ed,

This is definitely not expected behavior.  I have filed a report to R&D about this issue.  I'm sure they will look into changing the functionality for later versions of LabVIEW.

Thanks Didier, I will pass that along.

One thing I'd like to find out is are others seeing the block at the 0,0 coordinate as I've shown in the images in the original posting?

So, if you do have this happen, scroll the panel to the 0,0 point and see if that block is there and report it here.

Thanks

Ed

I may have found what is another bug with the way the Event Structure handles new vs. old data inside the structure.

I configured an Event case to fire on both the "Mouse Up" and "Mouse Down" events of a boolean with the mechanical action set to "Switch Until Released". I did this to toggle the state of a digital line as long as the user holds the button down.

The problem is that sometimes the value of the button in the block diagram is not what it is on teh front panel. The attached VI shows this behavior in a very simple mannor.

The button is wired directly to the LED indicator inside the Mouse Up/Mouse Down event case. So you would think that the LED would follow what the button is doing. Most of the time it does, but not always. If you turn on execution highlighting, you can see a False being generated from the button ternimal when it should be a True. How fast or slow you click it makes no difference. I've tried every combination of locking the front panel between the two events and it makes no difference. I've tried putting The LED outside the Event structure and that makes no difference.

I get the same problem in 7.0, and I do have the 7.1.1 update installed.

Using "Value Change" seems to work correctly, so that's the way I'm going for now.

Am I seeing things or is this just wrong?

Ed

Download File:post-47-1109701834.vi

Here's NIs official response to the report. Pretty much as I expected, but thought it would be worth at least reporting it to them.

To answer your question:

I agree, this is very odd behavior!  I have never encountered or heard of this behavior before.  Is it VI-specific or LabVIEW-specific?  To clarify, does it happen on certain VIs and not on others, or is this a problem that is persistent with any VI in LabVIEW?  I'll assume that it is a LabVIEW environment issue unless you specify otherwise.  What I would suggest to you is:

1)  First, try to Repair LabVIEW.  You can achieve this by going to Add/Remove Programs->National Instruments Software->Change.  Select LabVIEW

7.1 and click Repair.  Check to see if this solves the issue.  If not,

2)  Try a Uninstall/Reinstall of LabVIEW.  This usually solves any issues not taken care of by Repairing LabVIEW.

Hopefully one of these methods will take care of the behavior that you are seeing.  It sounds like maybe a part of LabVIEW has become corrupt, and when this occurs it is nearly impossible to try and "debug" the situation.

Hopefully this will get you up and running, Ed!  Please let me know if these two methods take care of the behavior or not.  Take care and good luck!!!

Well, if nothing else, it's good to know that we can restart LabVIEW to "fix" the problem.  I polled a bunch of people here in the office to see if anybody had heard of or experienced this behavior before and the results were negative.  I see the two references that you linked below, but its near impossible to troubleshoot non-reproducible behavior.  I'm interested to see if a complete uninstall/reinstall of LabVIEW will eliminate this behavior.  Usually situations like this are fixed by a clean install, so I feel pretty confident that this will take care of it!

The two references he mentions are two links to two other reports of this same problem. One from the NI forums and one from Info-LabVIEW.

NI Forum reference

Info-LabVIEW reference

Ed

I've updated this Event structure a bit.

It's now saved as a VI Template with front panel and block diagram images for the template browser.

I've also added an "Exit" event to handle all the shutdown code.

I keep the two sub-vis in my user.lib directory.

This is built in LabVIEW 7.0, but works just as good in 7.1

Ed

Download File:post-47-1109606765.zip

I've had this problem come up on me several times while developing my applications in both 7.0 and 7.1.

The resize handles disappear from all resizable objects on both the front panel and block diagram. Sometimes dropping a new function (like Scan from String) onto the diagram and deleting it will bring them back, but not always.

I've recently noticed that whenever this happens, there is what appears to be a grab handle at the 0,0 coordinate on the front panel of any open VI. I

Hi ALL!

Now my develop environment is LabVIEW 6i and it's corresponding driver. Now I got LabVIEW 7.1. I want to install it in my Windows2000. But system prompt to me that I should unistall my older driver before new higher version driver. But all of my project finished in LabVIEW 6i, and the test environment of our product Line is also LabVIEW 6i. If I upgrade the driver, the Load of maintenance of my projects is huge.

How can I install my LabVIEW 7.1 and it's driver while no affecting my LabVIEW 6i System (LabVIEW 6i and it's driver)?

Forgive my poor English!

Thanks very much!

3453[/snapback]

You shouldn't need to worry about it. The LabVIEW 7.1 drivers will detect that LabVIEW 6.0 is installed and it will install compatable drivers in place of the ones you must uninstall.

Ed

OK, this is a bit late, but I think it's worth while.

Ed

Download File:post-47-1104333247.mp3

I guess I hadn't thought about how NI would implement it.

A co-worker and I were talking about this and how we might be able to do ourselves just parsing the HTML and possibley using the picture control. A smiple HTML only web page might be doable, but with the varied compliance to the HTML standards, not to mention PHP, CGI, ASP, Java, Javascript, etc... and Microsofts version of HTML that Frontpage generates, there's just too many variables to make it fesible in our opinion.

You'd think they could license an HTML engine for each platform and come up with a new control that can display everything.

Sounds simple enough

I think LabVIEW should have a Web Browser Control. This would allow us to embed any web code directly on a front panel and keep the application compatible across platforms.

(read that as No ActiveX needed)

If there's a way to do this already, please let me know.

Ed