Ed Dickens

A quick search for the receiver on Google lead me to this page. The spec sheet says the output is either NMEA or proprietary binary. So I'm guessing that this is user selectable somewhere and it's currently set to binary. There's also a manual available for download on that page that looks like it defines the binary message format. You'll need that to either use the binary format or see if you can switch it to the NMEA format. Ed

I usually call them, "Those uninitialized shift register data trasfer subVI things". But, Functional Globals is probably easier to remember. Ed

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

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

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

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

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

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

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

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

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.

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. And a followup answer after I gave a few more details. 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

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