Michael Aivaliotis

Just want to see if others have noticed recent decisions by Microsoft and Apple. Apple to Use Intel Microprocessors Beginning in 2006 WWDC 2005, SAN FRANCISCO

Well, if you consider that the dimensions as stated are 1.5" square, it's very small. I like it.

Was looking through the LabVIEW BETA program site and came across an interesting item. It's listed as Cubix Pilot. I googled "Cubix National Instruments" and came up with this link: http://seniord.ee.iastate.edu/projects/current/may2005.html

So I guess this thread is now irrelevant? National Instruments Acquires Measurement Computing

Try here: http://forums.lavausergroup.org/index.php?showtopic=240

Also take a look at this post: http://forums.lavausergroup.org/index.php?showtopic=76

Sarah, a 1D array can be displayed in both horizontal or vertical. You just need to stretch the array with your mouse down instead of across. Unless you are referring to a 2D array? Then you must use the "Transpose 2D Array" function.

I use Installshield Express so I don't have to go and fiddle with each component code. All I have to do is tell Installshield Express that this is a shared library so it is handled automatically. Then when it is uninstalled then the refcounting is handled as you said.

This was posted to the NI forums and I'm copying it here for commentary. It seems that all issues brought up by the community have been addressed. This includes the non-compete language which I personally didn't expect to be changed. I'd like to here feedback on this from the LAVA Forum members.

Actually, this is my favorite little piece of code. It was impossible to cover everything in a 1 hour presentation so I left this code out but I should add it in. Here it is: Download File:post-2-1114377201.zip

Why bother checking if it exists? Also, you should just install all the required files yourself instead of calling the NI msi file. I've been doing this for years and have never had problems with my apps not working. By doing this, you let the run-time files become part of your application setup. In order to see what needs to be installed from the run-time, just install the run-time on a virgin machine and take a look at the attached image.

Hmm, do you mean USB memory stick? Doesn't it just show up as a hard drive?

Jack, could you post an example VI for this?

Use as many as you feel comfortable with. There is no limit or right or wrong. One thing I would comment on is how you implement and document them. If you are using 2 loops in parallel then it's ok to have both of them on the same diagram outside of a sub-vi. This is good especially if the communication is mostly done between the 2 loops. As things grow in complexity however you will find that displaying and debugging code with 4 or more loops (on the same diagram) gets complicated. I would suggest you download and review some of the code in a presentation I gave a while back. http://lavausergroup.org/niweek2004/meetin...niweek_2004.zip

Try removing the multiplication code and see if the results change. I have doubts that the scaling would be the problem.

I'm just throwing this out there to see if anyone else has had this problem. I have a M series DAQ card connected to an SCXI chassis that has a thermocouple module in it. The issue I'm seeing is that after a power failure, when the labview application starts talking to the card again it gives back an empty array of data from the DAQmx vi's (with no errors). The solution is to re-create the DAQmx channel configuration. If the system is shut-down and re-started gracefully then all is fine.

I would think that the memory usage would be the same since both approaches use a shift register. The only thing I see is a bit of overhead during the conversion process from variant to datatype. Also you have the issue of a call to a VI which takes up very little cpu time but a VI call nonetheless. If this VI will be called from a single caller all the time then I don't see the point. I would prefer to use a shift register in the caller. Like I said before, this would be a good a pproach if this VI is called from multiple callers.

Well, one quick thing I can come up with is the following (see image). This will speed up your longest loop. to detect the button press faster. You can do this to the other loops as well but you should use the tic count timer instead of the seconds since function. This will give you finer resolution. There is probably a slicker approach but this is the best I can do quickly.

Well, the approach really depends on what you are trying to do with the data. For example, is the data usually written to all at once all the time? If so then you might want to always write the data in one shot as one cluster. The only time I would write individual values would be if the writing will happen in multiple places in my code.

Well, all looks good as far as I can see. Now that all processes are in parallel, the queue messaging architecture makes more sense. This way, if one process is waiting for a message, it doesn't hold up the others. Good job! :thumbup:

Ok, here it is is. I built a LV6.1 example that shows how to have a server that sends data to whomever requests it. This one shows 2 clients and is done with parallel loops for simplicity. Of course these can be put into Sub-VI's. The datatype used is string but you can use anything really. I know some people use variants. Enjoy. Download File:post-2-1112239412.vi

Yes. All you need to do is separate the VI's into separate parallel loops. This will allow the "slow" VI's to run at any speed they wish and the other VI's won't be affected. It should be straight forward but if you need any help let me know and I can post the modified code.

Nope, no problem here. never seen this. Do you have sticky keys enabled in windows? This is in the disability aids section.

I can't answer all your questions since I've only been using DAQmx for a short while. This is what I've learned so far: You should configure all your individual channels as global channels first. Each global channel should be configured for each input sensor. Also, you should configure each digital IO line as a global channel. The global channel configuration defines the scaling and other parameters. Once this is done you then go and configure the required Tasks. Tasks define how you collect the data. You can create a single task that contains many global channels. In the task configuration you will define the aquisition speed and triggering etc. In you LabVIEW program you will use DAQmx task ID's not global channel id's. Hope this helps.

The code you submitted does not have many nested sub-vi's. I've developed applications with thousands of VI's and they run very quickly, efficiently and everything is synchronized. Your code is very lightweight so the lag you are seeing must be comming from somewhere else. The solution to your problem is to simply to create subvi to handle the port writing and place that wherever you need it. I built a quick VI to do this for you and I modified your original code to include this VI. Basically just place the VI down wherever you need to modify one item. The VI remembers the previous states of all the items so you don't need to worry about synchronization. One thing I noticed is the multitude of File IO. Is this really necessary? File IO is a big bottleneck. Download File:post-2-1111825775.llb