m3nth

When you right-click on an indexed array of references coming into a for or do loop, you can't create the corresponding property or method that you would normally be able to create. Right clicking the [] box and selecting Create yields only Constant, Control, Indicator--no Property> or Method>. If that's unclear, create a control. Create a reference to that control. Build it into an array then wire it to a For loop so the index [] box appears. Right click the index box... only items mentioned above.

I had an afterthought on this particular sentence... What exactly does it mean? Or more correctly, what _will_ it mean? - Once scripting is supported, will people be able to ask scripting questions on the NI Forum? (I would think so) - Would they be able to post their scripting code? (I would think so) - Would that violate their licensing and/or nondisclosure agreements? (If the forums are open for that then I would think not) - Would other people be able to download their code? (I would think so... but who knows...) - If other people who don't have a scripting license (or whatever it is you'll have to buy) can download scripting code, will it run correctly? - If it runs correctly and the block diagram wasn't locked, could it be edited? - If it could be edited without a scripting license then that would mean you don't have to have a scripting license to script? How does that work?? - What about previously scripted code in version 7.1... will it be blocked? - What if the world ends tomorrow??? Ok anyway... just a few things that make my head go into a no-wait do-loop

Well well... that's quite the bit of news. I wonder if it will be concurrent with the release of version 8? Thanks for posting! :thumbup:

Why the frownies?... didn't you read the scripting FAQ on this website? NI is well within their rights to remove your post, and any other post they want to remove or censor that doesn't fit with their business model. Which is one of the perks of the LAVA forum... talk about whatever you please here. :gathering:

Before LabVIEW 7.1 I saw an example from NI that looks almost identical to yours... that's a good way to implement.

As the previous post said... what hardware will you be toting along with your software upgrade?

That was indeed a much earlier post on LV2 globals... I re-read that before posting this time though--it does not have the information I'm looking for (unless I missed it the second time skimming through). I now understand LV2 globals and how they function but whenever I have used one I have only needed to use one instance of it. Now the case has arisen where I may want to have two instances of the same global, ie, two different data sets. The painful way to do it would be to make a copy of the LV2 VI and rename it two a second file. As I said though, I'm almost sure I've read a better way to do it... one where the same file can be instantiated or something of the sort, which would not require duplicate changes if the core functionality needed to be updated.

Tab controls have always been problematic for NI... little glitches here and there. They fix more and more of the glitches with each release but there are still some left . At any rate, judging by the fact that I can't reduplicate your problem, if it's a glitch with the tab control it's probably been fixed already... there have been a lot of changes since version 6.0 so the obvious 'fix' is to upgrade to the latest and greatest. If you can't upgrade however, perhaps someone else might be able to help you with a workaround.

Alright I know there's a way to do it. I've seen it posted before and can't find the old posts now for the life of me. I don't want to just copy my LV2 global and then have to make duplicate changes every time I change something internally during the development process. I remember vaguely something about making the LV2 global re-entrant then using a wrapper for each instance--something like that--seems like you would still have to add controls and indicators to each wrapper if the guts changed though. What's the best way to do this? (Or where are the posts if it's been posted previously?)

After talking with a colleague, I have come upon the ideal solution. The DLL will simply have two functions: - The "Start" function will start and run indefinitely once it is started from LabVIEW (designated as re-entrant) - The "Stop" function will simply set a stop flag that is polled by the main routine Since the DLL memory space is shared, the variable set with the "Stop" routine will be the same variable being polled for an early exit. Here's the test code... it works nicely: _declspec(dllexport) void Stop(void); _declspec(dllexport) void Start(void); int StopFlag = 0; unsigned int i = 0; __declspec(dllexport) void Stop(void) { StopFlag = 1; } __declspec(dllexport) void Start(void) { StopFlag = 0; do // do whatever... { i += 1; } while (!StopFlag && i != 0); //timeout after 2^32 iterations if Stop hasn't been called }

The information and links on MSDN were very good although reading them shed further light on which direction I think I should take. Even though you pointed out that the first option (looking at some type of globally available variable) is not always a good solution, the information and event functions available through Windows don't seem to fit what I'm doing well because: - The check to see if the DLL should exit will be a poll-type check that occurs every so often when the DLL loops - Waiting for an event so that the CPU goes to 0% is bad (in my case anyway--I know it's not usually bad but it would be for me to shut down the DLL processing) - Even waiting a minimum time might be doable, but it would be bad if the check was done inside a nested loop--in comparison to a global value comparison that would take a fraction of the time. That said... do you know of any code examples that are similiar in function to the first option described? It seems to me if you were dealing strictly in C++ you could just pass the DLL function a pointer to some data and then change the data when you want the DLL to exit. With LabVIEW though the data that you would be passing the DLL a pointer to would be copied (in my best understanding) and you wouldn't really be able to change it after you passed it to the DLL.

I wanted to add a note to this particular post because somewhere along the way I discovered that even though you can't look for a particular instance of enum, you can manually type in the text and LabVIEW will find that text for the instantiated enum--meaning you can find all text that is identical and then pick the items off the "found" list that are actually enums. While it would still be nice to have selective search capabilities, it works for now doing a text search.

This is as much a Windows/C++ question as it is a LabVIEW question. What code or mechanism can be placed in a DLL so that it can be stopped prematurely if necessary? If anyone has example C++ code that would be great. My ideas are somewhat along the lines of obtaining some sort of handle or reference (to whatever... a boolean variable, notifier, occurence, or some non-LabVIEW lower-level Windows mechanism) then passing that to the DLL and checking it periodically in case the user wants to exit early before the DLL is done. If that's somewhat going in the right direction then I'm either: A) ...Trying to figure out how to check the value of a given variable or session that I pass the DLL a reference to (how to get that coded into the DLL), - or - B) ...Trying to figure out what Windows calls I should look at on MSDN that will give me a signalling mechanism. Besides it actually functioning, the other thing I would prefer is that it doesn't take a lot of time. Therefore I am looking for not just something that works, but an optimal solution in terms of minimum processor delay and minimum CPU instructions executed... preferrably not calling a function that interrupts the DLL by going off and executing half of the Windows kernel

To "continuously integrate" in the digital world always means to monitor at discrete integrals--that's part of having the data digitized. The smaller those discrete integrals, the better the accuracy of your integration. You will always be integrating a set of data points ("an entire waveform"), but in my understanding, the length of your acquisition in the current setup is excessive in comparison to the time you would like to pass before cutting your source off. What is the maximum amount of time the voltage cutoff can lag the actual charge accumulation event? From what you've stated, your present configuration fails this criteria. What I would look at if I were you: The Time Domain Math Express VI (Block Diagram > Express > Arithmetic & Comparison > Time Domain Math) has an option to perform a waveform integration on a signal. The guts of the integral are just to add one number after another after another until everything in the data set is added to a single value (which is then multiplied by the dt value for correct time units). It can also perform a "continuous" integration by "remembering" where it left off--ie, it saves the last value when it has completed processing the data set. Then when it gets called the next time, that number is the starting value. Using an integral should work for you but what you would want to do I imagine is keep your acquisition times very low so you are monitoring at intervals that make it seem more "continuous" instead of "discrete". Something else to consider (don't know what hardware you're using) is that the NI scope cards such as the 512x family offer on-board measurement capabilities, one of which is integration (which means it gets performed in hardware and you just read back the number).

I third that nomination. If you want to go homebrew, use the OpenG routines to get a list of all the files in the directories and llbs then run a checksum comparison on all of them. I do this type of thing all the time in other regards of directory/subdirectory comparisons... it's the very crude but effective version of what B.C. does.

I just found this post from awhile ago, looks cool... http://forums.lavausergroup.org/index.php?...16&hl=labview+8 Does anyone have any idea when version 8 will be released based on previous release dates? Does NI usually issue new releases every 12 months? 16 months? 18 months? Any guesstimates when it will hit the shelves? Maybe we should have a wager with a prize for the person who guesses closest

Hi jess and happy birthday today You didn't give much instruction as to where exactly the error occurs. Looking at your files, I'm guessing that "mouse controls5(jp).vi" is your main program... There are a few options if all you need to do is cancel the error notification popup. If the error occurs early on in your acquisition and needs to be ignored, I would recommend using the General Error Handler.vi and giving it an exception code 10401 with the option to "cancel error on match". In fact, what I would probably do if I were you would be to add the "no dialog" to the General Error Handler.vi that is currently at the end of your acquisition chain. I would then add the "cancel error on match" and the "10401" code so that all error 10401's are cancelled. This would make sure that 1) No errors result in a poup dialog and 2) Error 10401, which you have already deemed irrelevant, is never displayed. The last thing I would make sure to do however would be to make an error indicator on the front panel, connected to the Error Out of the General Error Handler.vi. This will make sure the user is aware of any other errors besides 10401 while ensuring that there are no unforseen popups from the general error handler that can't be closed remotely.

This has already been covered and will not work since he wants to poll the dos window. Please read the entire thread before posting hastily.

Like what options? The options that are normally accessed via the Execution section of the VI's options? Why are moding enums inadequate for this task? Your suggestion does not seem clear to me. I would agree on editing the icon though... perhaps right clicking and being able to pull up the properties for that subVI... I would definitely second that :thumbup: I have wanted to do that many a time and have to double click into the subVI, then pull up the options or double click the icon.

In your LabVIEW directory \ manuals, there is a file called lvexcode.pdf--Using External Code in LabVIEW. Give it a good read, try the examples, and then come back with specific questions if you have any. You can also navigate to the pdf through the LabVIEW bookshelf under the Help menu.

You don't mention which graph or chart control you're using, so I tried them all. The following controls do not display for me "100:00:00" when I enter "100" onto either the start or end "xx:xx:xx" labels. They instead go back to their original label displayed. Waveform chart Waveform graph XY graph Intensity chart Intensity graph So right off, I can't duplicate the behavior you're describing, but entering a number into one of the labels it must be formatted correctly to make it work... i.e., the user must enter a number of the form XX:XX:XX instead of an integer (the crux of what you're saying probably, and not what you want). To answer your question in short, I think the answer is no. A very easy workaround though (which of course may not be optimal for you) is wiring an integer control to the property node for the graph or chart's XScale.Maximum property. If the user enters the number of seconds and that value is passed to the XScale.Maximum property, it will be automatically converted as desired and displayed in xx:xx:xx format for your chart.

I use this all the time for commenting out code that I don't want compiled... I use it in a VI that I drop onto the block diagram from the BD palette (which merges it)... see post here: http://forums.lavausergroup.org/index.php?showtopic=356&hl= As mentioned, the only caveat is that it is not a released feature for LabVIEW (probably because it doesn't work quite as expected sometimes). The unexpected behavior to watch out for is when you have broken code in a subVI where the subVI is inside the disabled structure. The broken subVI will break your app with no errors showing up when you go to run your app (doh!). Otherwise, as long as the code is broken and in the disabled structure, but not inside a subVI in the disabled structure, it works great.

Point taken, but I think that's a pretty narrowminded assumption about the way NI will implement the activation of their software. I say, wait and see... it probably won't be so bad.

That's kinda cool... good idea. I have had that problem before and use a slightly different workaround. Why did you password your code?