asbo

(is it kosher to spam LAVA with links to forum posts? If not, my apologies...)

Typically, it's preferred to find the most specialized area of the forum that fits your post and just make one thread there.

But as soon as we put a 10kHZ datalogger to see the feedback and controller output

Hardware or software datalogger? Are you hooking leads up somewhere or is it built into the existing FPGA application?

Use the search box in the corner to search for his name. At his profile, select the Files tab on the left.

The other file listed under his name is FP SubVI Fixer ver 6 LV 2009. Guessing that's it. http://lavag.org/files/file/128-fp-subvi-fixer-ver-6-lv-2009/

Checking back in... Unfortunately, the add button on the Source Files pane is disabled for snapshot'ed folders - per the help, "You can add only auto-populating folders, but you can add multiple files at the same time."

I also tried using a Source Distribution, since an installer can have those added as well. I enabled the "preserve directory structure" setting because my sequence is set up to use relative paths. However, when I do this, LabVIEW preserves the *whole* directory structure, when my Code/etc folders are already 5 directories deep. What a pain.

My next step to try creating a new project and seeing if that resolves the blank file issue. Short of that, I guess I need to pack it up and have NI tell me what's going on.

The icon editor, maybe?

If you're leaving the code in the boolean control's Value Change case, the reason the counting doesn't work is because the event will only fire for a Value Change for the boolean control. You can either use DAQmx Read in a loop to poll the input and detect changes or you can check to see if your hardware supports DAQmx Events.

The only thing I can think of offhand that might be an issue is that eventually there will be 8 or 10 of these spread around the USA.

You don't know anything about TrapWire, do you, Cat?

This is a very good point about the subroutine requirement, rolf, and I'll admit that that particular nuance of CLNs is something I learned after writing those VIs. However, my experience is different regarding GetLastError() in that applications can and will call SetLastError(0). In fact, from MSDN:

Functions executed by the calling thread set this value by calling the SetLastError[/url] function. You should call the GetLastError function immediately when a function's return value indicates that such a call will return useful data. That is because some functions call SetLastError with a zero when they succeed, wiping out the error code set by the most recently failed function.

However, I agree in principle that GetLastError should not be called unless the initial API call indicates an error was generated, as it could lead to mismatched error conditions.

Cat: glad this still ended up being useful for you.

I have never tried out the adapters so I can't comment on them but the red X actually means disconnected I.e. I have seen this device before but can't now so I suspect nothing has worked through the adapters.

I thought this was the case, but want someone else to chime in to be sure.

Have you verified the Ethernet path is good (right kind of cable, etc) with something else?

Use the event structure with a case for the Value Change event of your "VFO - Band Selection". Move the property node for "Dialo frequency input" into that same case to keep all the logic contained (even if you have multiple cases setting the value, just use individual property nodes - little more BD space, but cleaner and easier to read). Also, you may not need to use a signalling value ("Val(Sgnl)") property node for the "Dial frequency input" unless you have other code in the event structure that reacts to value changes on that control.

Ahh, interesting idea, I didn't know about snapshots. I'll give that a try.

I've carried blades onto flights in a carry on before (by accident...), so it's probably just luck of the draw.

Here's a head scratcher for you. I'm building an installer in LV2011 SP1 which will exist to only copy some files to a specific location and set some registry keys. In my project, I have three auto-populating folders to be included in the installer. Immediately after making the folders auto-populating, the build looks fine and dandy:

However, when I go to build the installer, it craps out and gives me an error. Here's what the Build Errors dialog tells me (angle brackets added for whitespace emphasis:

> The following file(s) are not found on the system:

>

>

>

>

> Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

>

> CDK_Build_Invoke.vi.ProxyCaller >> CDK_Build_Invoke.vi >> CDK_Engine_Main.vi >> IB_MSI.lvclass:Build.vi >> IB_MSI.lvclass:Engine_PreBuild.vi >> CDK_Engine_FileExists.vi

>

>

Going back to the build properties, I now have two "blank" files in one of my auto-populating folders! I can select these files just like anything else, but the item label is completely blank.

I don't know what makes this auto-populating folder different than the other two. There are no hidden files of any kind in the folder. The folder is versioned in SVN, but I'm using 1.7+ so the .svn directory is only in the root folder. If I make the folder non-auto-populating and then re-auto-populating, I can repeat this cycle ad nauseam. As a non-auto-populating folder, I can only add files from the Code folder to the build, I would have to build the directory structure by hand, which is exactly the reason auto-populating folders can be used in builds.

I don't know how else to troubleshoot this issue. I've tried re-creating the build from scratch without any luck. Has anyone seen this before or have some ideas about how to figure out what's going on?

I can see that now the utility is written, it's pretty difficult to change it, although it could always be deprecated with a new version written. Failing that, perhaps a boolean, or a 3-way enum - e.g. All (default), Files Match, Directories Match - could be added. Or I guess a polymorphic function is another way to extend/correct it.

I would be on-board with either of those options. I think it's weird and unexpected to get both directories and files matching my pattern; that said, I can't think a time when I wanted to pattern match directories, so there you have it.

Make the change and submit it for inclusion!

Oooh, I read a little too much between the lines of what you said. Interesting; does the original node returns directories and files or just directories?

I would agree that including any subdirectories which do not contain a matching file is a bug.

I think the bug itself is here:

The build array should be conditional iff the size of the "all files" array is > 0.

If the numeric control must be /locked/ to the specific value as well, you should use the Value Change event of the radio buttons to enable/disable the numeric.

UDP is lossy, so what are the chances your infrastructure is dropping the packet somewhere? It may not necessarily be the software's fault. Diagnostically, you can use something like wireshark and netstat to make sure your traffic is going out and that nothing else has the port tied up at the wrong time.

Here's a changelist: http://digital.ni.co...6257A440064199F

I am dealing with a customer who is different than the ones I had before. He likes to take all the block diagrams but refuse to pay once he has got all the code. If there is some kind of date trigger protection, next time he opens the block diagram, he may be prevented from seeing the block diagram. Just a thought!

This sounds like a situation where I would simply strip the block diagrams. There's no way I would continue delivering source code to a customer that had a history of not paying me for it.

shoneill's suggestion makes the more sense, but if you can't do that, build an array of the XControl references, wire that into a for loop, and go to town.

The code is designed on the premise that "everything is working". If the VISA resource control is set to the "correct" value, then the code will run without error (barring communication errors). Opening and closing the serial port on each iteration. How is this a good thing? Yes, checking for the error code will stop the loop, but it does not eliminate the fundamental problem with the code that I pointed out. On the NI forums we see this all the time, and we tell those who do this the same exact thing (all the time): initialize before the loop, close after the loop.

I wasn't talking about init'ing and closing outside of the loop, which is why I didn't quote that part. I think it's unnecessary to implement this as a state machine, which is what I did quote.

If you were to reserve the VI for execution (not sure you can, off-hand), you would be able to see but not copy the BD. That said, I don't think the password protection mechanism fits this use case very well.