jdunham

QUOTE (Minh Pham @ Nov 3 2008, 07:19 PM) I don't think it's safe to assume that the base file name doesn't have any numbers in it, so I think you need a more sophisticated regexp than [0-9]+ If you use \s[0-9]+(?=\.vi$) then it will find the number right before the extension, including the leading space. This only works with the Match Regular Expression function, not the older and simpler Match Pattern function. However, I gotta ask what you are trying to do? Cloning VIs is way easier than making your own copies of templates. Thats how we spawn off multiple processes and multiple instances of a pop-up GUI. You can search LAVA for more details (that's how I learned about them).

QUOTE (Minh Pham @ Nov 2 2008, 04:15 PM) I think the OP meant that his computer doesn't have any serial ports. RS232 to USB should work fine, but a PCI card will be fine too. Often your motherboard will have the RS232 header on it, so you just need the extender cable to the back of your chassis, which you could find at a surplus store. Either way, you should be able to get an RS232 port for US$20-25 (unless you buy it from NI).

QUOTE (bodacious @ Oct 29 2008, 01:14 PM) Ok, that makes some sense. I presume you are ready for the fact that the mesh networking will consume a lot of the bandwidth of your radios, and you are accounting for that in your traffic analysis. To answer more of your questions, more information about the design considerations is needed. If your network is reliable and you don't need a hard guarantee of delivery, then you should just use UDP for broadcasts. If those are not true, can you make one of the nodes a master node? Then you send all updates to it, and it can deliver the broadcasts in an efficient manner to each subscribed node. Is your network dynamic, that is will nodes connect and disconnect at unpredictable times?

QUOTE (Kyle Hughes @ Oct 29 2008, 02:22 PM) Is your team already using CVS? If not, then it's hard to imagine why not use SVN instead.

QUOTE (bodacious @ Oct 29 2008, 10:36 AM) At the risk of being a jerk, I will point out that you are designing a mesh network (whether or not you get mesh radios), and that mesh networks are hard, and a lot of people are doing PhDs and starting companies about them. If you are really going to reinvent all of this and since you have some pretty basic questions, I think you have a lot of struggle ahead. I don't want to say you couldn't do it, but I hope you are reading a lot of the literature, and looking for other forums where people have more relevant expertise (nothing personal intended to you or Dan).

QUOTE (Thang Nguyen @ Oct 28 2008, 10:58 AM) I'm a big fan of notifiers. To me they seem easier than dynamic events, but if you already need the event structure it's probably a good solution. I don't really like to mix the GUI code with the process messaging code.

QUOTE (BrokenArrow @ Oct 28 2008, 10:30 AM) VISA Close works just fine for me, but other VISA calls will auto-open the port. Therefore you have to make sure that after closing, you don't call any other VISA functions on the port, even in other loops. I just tried it again. Write some characters to COM1, and I can't open my terminal (PuTTY). Run VISA close, and then it opens OK. Can you post some sample code?

QUOTE (Thang Nguyen @ Oct 28 2008, 09:43 AM) You shouldn't need to wait for timeout. Main VI A should open the queue and drop your values in. Dynamic VI B should open the queue and start listening, and there should always be something in the queue. You can use a zero timeout and throw an error if the queue was empty, because your queue should always have the parameters waiting in it. We start all of our cloned dynamic VIs this way. The Dynamic VI should force-destroy the queue, because if you let the Main VI Close the queue, then it may clean up the data before the dynamic VI can receive it.

QUOTE (TobyD @ Oct 27 2008, 08:44 AM) On my Vista computer, visaconf.ini is located in C:\ProgramData\National Instruments\NIvisa. I don't know the best way to replicate settings between computers, but it seems likely that your app will need elevated privilege if you want to write a program to modify the file.

QUOTE (Aristos Queue @ Oct 25 2008, 07:12 PM) AQ's solution is certainly faster and better, but he sort of pulls a rabbit out of a hat, luckily finding another function available which does the rearrangement internally. If the OP is curious about how to work with large data sets, and how to get decent performance, then this version shows how him or her how the original code could have been written to run in a reasonable amount of time. Jason http://lavag.org/old_files/monthly_10_2008/post-1764-1225093225.png' target="_blank">

The problem is that you are using Build Array inside the loop. This requires LabVIEW to reallocate memory on every iteration (I think they try some optimization, but there is only so much they can do.) Instead of using shift registers which start empty and hold an ever-growing array, you should initialize with a full array containing all zero values, and then use Replace Array Subset, which is an in-place operation, to drop the correct values at each location. Not only is build array slow, but it gets slower as the array grows. On my computer the original VI ran too slowly to measure. After about 15 minutes It had done more than half of the rows, but was getting slower. The rewritten version ran in 47ms.

QUOTE (Phil Duncan @ Oct 23 2008, 08:37 AM) Setting up 16 different tasks will not work, as there is only one circuit for the analog trigger. As others have said, you can acquire continuously and perform the "triggering" in software. Our product (a gunshot detection system) has been doing this with NI-DAQ since 1995 and it works fine. You should have no problem with 20kS/s. I would recommend that you learn about the property nodes of DAQmx Read. The Read system is very flexible and powerful, and rather than writing a circular buffer, allows you to use the built-in circular buffer that is DAQmx. You keep reading all of your channels to detect the trigger condition, and when you have found it, call DAQmx Read with the desired range of samples, and you will get all the data in one coherent chunk. You can also do things like having maybe a 30ms window to look for trigger conditions, but grab that window size every 1msec, so that you don't have to worry about extra code to handle events which straddle the boundary of two successive reads.

I think VISA Serial defaults to a text-oriented mode, where EOL chars are sent automatically at the end of each write. You should be using more VISA properties to make sure all those features are turned off.

QUOTE (jgcode @ Oct 16 2008, 05:28 PM) I don't think so, though I was hoping for someone who knows more than me to be chiming in by now. It helps to think about the requirements on LabVIEW. When you fork a wire, LabVIEW can only continue sharing the data between the wires if it knows no changes to either side will violate the integrity of data on the the other side of the fork. If you fork a wire and send one tine into a subvi, then that subVI might modify the array, so the caller is going to have to make a copy to protect the other tine(s) on the calling diagram. If you wire the array into the subvi and back out, then you can avoid the fork and the caller won't have to make copies to protect the data. Also, if one side of the fork doesn't change the data, like it just gets the array size, then there should be no extra buffer allocation. Even if you send the other tine into some mysterious subvi, the compiler is smart enough to take the size first before it allows the subvi call to have its way with the data. Use the Show Buffer Allocations tool to get the actual situation for a particular diagram. I think the inplaceness structure is just a hint, since you can't force the compiler to violate dataflow. This would all make sense with pictures and circles and arrows, and I just don't have the time or knowledge to do that right.

If you care about memory usage, you need to make sure the subset array wire is a true subarray, and you need to scrutinize the buffer allocations nearby on the original array wire. AFAIK, the only way to know about subarrays is to look at the wire's context help. Make sure you read this thread about sub-arrays Even if the min-max is performed on a subarray, you need to check the array going into everything. If you run jgcode's fine VI, I think the caller will often have to make a copy of the entire source array, which you can detect by viewing the buffer allocations. If you took that VI and wired the array in and passed it back out, and did not fork the wire in the caller, you can probably avoid any array copies. Notice I am hedging here because it's hard to find clear documentation on this complex subject.

QUOTE (d_nikolaos @ Oct 13 2008, 07:51 AM) Everything is possible, but what kind of inputs and outputs are you looking for? Check out "Concatenate String", "Format Into String", the String/Number Conversion palette, and possibly the Data Manipulation palette. It would also help if you post some code (or a block diagram screen capture) of what you are trying to do.

QUOTE (Jo-Jo @ Oct 10 2008, 01:25 PM) The other replies are right about ways to keep a VI's reference open, but it sounds like you want to keep the caller's reference open. I read your post a few times, but I still don't quite get it. Let's say you have a loader VI which kicks off the real app panel with VI Server. Why do you want to keep a ref to the caller, anyway? My first thought is that you should keep a list of all the spawned panels themselves, so that your manager can check whether those are still open or valid. But maybe I'm misconstruing what you really need. What good is a ref to a VI which is closed and stopped? To put it another way, if you have to make a special effort to defeat the LabVIEW garbage collection, maybe your design is not quite right. How are you using different "application instances"? Are you running separate built EXEs? You can't share a global between application instances, whether in EXEs or LV source code. A VI ref is dependent on the application instance, so how do you deliver the correct app instance to your top level VIs now? Even if you open the VI ref by name, you have to supply the app instance. Maybe it's just Friday afternoon and I am wiped out, so ignore my babbling if you have solved it already.

QUOTE (Mark Yedinak @ Oct 9 2008, 08:53 AM) Thanks, I should have stated more clearly that I was talking about serial ports. For TCP, our app uses the native calls which work fine for full duplex communications. I supposed we could have used VISA for that too, but your post makes me glad we didn't.

QUOTE (skof @ Oct 8 2008, 10:02 PM) Well NI can tell me until they are blue in the face that VISA is awesome, but I will keep my opinions to myself. Yes, it seems like asynchronous should help. No, in fact it doesn't. Putting the calls in separate LabVIEW execution systems (threads) doesn't help either. But, yes, you can get what you want. The trick is (courtesy of NI's Dan Mondrik, who at least tries to atone for NI's sins by helping us)... You have to open separate VISA references to your serial port, one for the write thread and one for the read thread. That's the only non-stupid way to keep them from blocking each other while timing out (the stupid way is to poll each side in a really fast loop with a short timeout). http://lavag.org/old_files/monthly_10_2008/post-1764-1223532516.png' target="_blank"> I did suggest to Dan that this useful nugget be put on the NI Developers' Zone, but a quick search turns up nothing. Let me know if it works for you.

QUOTE (jlokanis @ Oct 8 2008, 10:56 AM) Well it's pretty easy to write in LabVIEW without regular expressions But make sure that you don't want to support scientific notation or NaN, and what about a + or - only at the beginning. You should also use trim whitespace.vi rather than testing for whitespace chars if you don't want to allow whitespace in the middle. If you really want to do it right, a regular expression may be better. check out http://www.regular-expressions.info/floatingpoint.html

QUOTE (jgcode @ Oct 7 2008, 02:52 PM) The transparency is also called virtualization, because you are allowed to write to a virtual C:\Program Files\ which is not the real thing. When you install a program, the installer runs under admin privs, and I think at that time you can declare that your app's virtualized folders have lesser privilege. I'm too lazy to look up whether this is the exact truth, but that's what I remember from a bunch of previous googling.

QUOTE (bmoyer @ Oct 7 2008, 05:12 AM) We use our serial ports only in binary mode, so it is definitely just a settings problem related to the termination character There are serial settings for this, and also a "message" setting. I'm not sure which one overrides another, but we turn them all off and it works great http://lavag.org/old_files/monthly_10_2008/post-1764-1223401468.png' target="_blank">

QUOTE (jgcode @ Oct 5 2008, 11:18 PM) Well, we learned the hard way, and to be honest, we're still doing it the wrong way until next our next version which has to support Vista. QUOTE (jgcode @ Oct 5 2008, 11:18 PM) Thinking out aloud however, if the installer installs the data files (whether in Program Files or elsewhere) wouldn't the installer know to remove them aswell on an uninstall? Or is there a built-in proxy in the installer that does not allow such behaviour? Well what has worked for us is that the configuration INI file is not installed by the installer (actually we do install one to fix the fonts, and that has to be in the program files folder, and it never changes). For the real INI file with our application settings, the one which will go in the user directory, the software checks for it on every startup and creates it if not found (you may want to prompt the user to set the settings at that point too). I suppose your uninstaller ought to remove that file, which would be the polite thing to do, but I haven't tried that.

Our project has lots of typedefs and interconnected functionality. We (4 developers) use SVN and we don't use locking, but we sure don't look forward to merging. We have some conventions and some custom tools which help with the merging, but it makes me annoyed that they needed to exist. Sometime soon, I am going to try locking to see whether it improves our workflow.

QUOTE (jgcode @ Oct 4 2008, 05:42 PM) I also wanted to point out that there is a big benefit to getting your config data out of c:\Program Files\.... If you want to deliver an upgrade to your program, you can let the installer blow away everything in that folder without losing any user settings or configuration state.