Neville D

QUOTE (jlokanis @ Sep 2 2008, 08:37 AM) Have you tried debugging the built executable? Enable Debugging when building the exe and try it out. It works great. N.

If you have Vision 8.6, there is a new "zoom-to-fit" option for displaying images. I haven't tried it on a Window yet, but it works great on the IMAQ Image Display. Note there is already an update Vision 8.6.1 N.

QUOTE (cmay @ Aug 7 2008, 04:10 PM) I was going to suggest using the mathscript node (that can run a large percentage of m code in the LV environment), but it is unsupported on RT. So your out of luck apart from translating it into LV code. Is it a lot of code? N.

QUOTE (Gan Uesli Starling @ Aug 25 2008, 05:31 AM) The jpegs are fine when you click on them (and also fast). So what exactly are you trying to do? Read the chans on one piece of hardware with two different tasks? I think thats not allowed. Or maybe since the SCXI chans are mux'd into the same USB AI chan, you have to read all of them in the same task. Can you put all of them together and read that? Its been a while since I played with SCXI, but thats what I seem to remember. Try taking a look at the DAQ examples to see if there's something that will work for you. N.

QUOTE (JustinThomas @ Aug 25 2008, 05:57 AM) If it takes 45 min with Windows ftp, it will probably take that long using any other method. Can you use Gig-E with your controller? Have you tried chunking the files into smaller sizes? I'm not sure if this will make a difference, but worth a shot. Just copy over a few large files and see if that changes things. Are you using binary files? (They might be smaller in size). N.

QUOTE (Gan Uesli Starling @ Aug 22 2008, 12:39 PM) Can you upload jpg images? Insert into your text with the "Manage current attachments" tab. Nobody will bother downloading 5MB of picture data. Neville.

QUOTE (jlokanis @ Aug 22 2008, 10:20 AM) Can you post an example. It would be helpful, though I may not be able to use for RT apps where I read ini settings from xml. Thanks, N.

QUOTE (normandinf @ Aug 22 2008, 06:28 AM) http://news.bbc.co.uk/2/hi/asia-pacific/7576240.stm' rel='nofollow' target="_blank">Re-education would be the best option N.

QUOTE (Rashmi @ Aug 22 2008, 03:51 AM) Some more information would be helpful. 1 What are you trying to achieve? 2 What PC hardware do you have? 3 Newer versions of LV have much better performance and better multi-core support (I suggest you upgrade). 4 How are you solving the ODE's? mathscript nodes are useful but painfully slow especially in the older versions. Look at the release notes of the various LV versions, they should give you pointers as to what has been optimized or upgraded in each version (there have been a lot of enhancements in terms of performance). 5 Do you HAVE to solve all 12 ODE's together? Can you split out the solving to multiple cores/PC's & put together the results later? 6 Take a look at this http://www.ni.com/niweek/2008/keynote/mike_santori_mike_cerna.htm' target="_blank">Large Telescope Demo from NI-WEEK 08. What you are trying to achieve is quite challenging given the 1ms solution time. 7 Provide some screen shots or code to show your approach so it can be critiqued for better performance. 8 Why do you need the 1ms solution time? Are you controlling something in real-time? 9 Can you simplify the system model to eliminate some of the 12 degrees of freedom to fewer? Neville.

QUOTE (ASTDan @ Aug 22 2008, 05:54 AM) I agree, it would be good if there was a way to link the location of different available OpenG packages. But whats the harm in having different (maybe competing) libraries? More the better. Neville.

Great defence Aristos! :beer: (Though elegance is sometimes preferable to performance..) Boy, this place is beginning to feel like info-labview! Cheers, N.

Boy that was quick! Vision Dev Module 8.6.1 is already available for download! That means either NI is really on the ball with updates, or VDM 8.6 was really buggy. I found it to be alright though. Here is the VDM 8.6.1 readme Mercifully, the patch is only 27 MB, so System Administrators everywhere can breathe easier (mine was a bit upset when I told him my 7 Gig LV 8.6 Disk 1 download failed). Neville.

QUOTE (tmunsell @ Aug 21 2008, 02:24 PM) Maybe you can download what you need from ni.com? Or get others to download & install required components separately from ni.com, while you send them a simpler build without the addtional components. Or get a local NI rep to drive you the CD's you need. I know, its a pain, whenever I visit a customer-site, I carry along all 15-20 CD's and DVD's of the last two versions of LV + toolkits, just in case. Neville.

QUOTE (lycangeek @ Aug 21 2008, 08:50 AM) True.. beats Austin in summer anyday! Neville.

QUOTE (Aristos Queue @ Aug 21 2008, 11:36 AM) Heheh... like the http://forums.lavag.org/3-button-dialog-improvement-t2160.html' target="_blank">3-button dialog VI.. Neville.

QUOTE (ASTDan @ Aug 21 2008, 11:15 AM) Hmm.. maybe change pt style/line style to fit the remaining? Anything more than 5 plots is basically unreadable and a waste of time. Maybe try splitting them out to individual or stacked plots? Or else modify Dave's VI with an offset of some sort to get another set of 24 colors. Off-topic, there's a lot of good stuff in there, and the "read anything write anything" VI's in this library are supposed to be a lot faster than the NI config read-write VI's. I haven't tried them. Neville.

I'm not sure. But you can just build the executable without needing to build the installer every time. Once the code is installed, all you need to do is replace the executable. If building just the exe it won't keep bugging you about the DVD's. Neville.

QUOTE (busher @ Aug 21 2008, 10:22 AM) short answer is No. The VI's in the exe anyway don't have diagrams and front panels anyway, so even if you had 7.1 it wouldn't work. Neville.

If you download the OpenG package from MooreGoodIdeas, there is a VI in there: MGI Non Repeating Plot Color.vi that selects reasonable colors for a white background plot when called. Neville. Edit: And since it took me ages to find it in the palletes when I first installed it, here is where its buried at: Functions>7.x functions>MGI all VI's>Array>MGI Plots

QUOTE (Norm Kirchner @ Aug 20 2008, 12:05 PM) I'm not sure why its not working for you but, this always works for me.. http://lavag.org/old_files/monthly_08_2008/post-2680-1219259757.jpg' target="_blank"> Neville.

QUOTE (Val Brown @ Aug 19 2008, 11:06 AM) I'd forgotten it. I just googled LV ini keys and found it from http://labview.brianrenken.com/INI/' rel='nofollow' target="_blank">Brian Renken's page. N.

QUOTE (Val Brown @ Aug 19 2008, 08:21 AM) LVdebugKeys=True

QUOTE (guruthilak@yahoo.com @ Aug 18 2008, 11:49 PM) Since the error message pts to the Table Control, delete and replace it (and the associated wire branches on the diagram too, for good measure) and it should be fixed. There is an ini key that you can add to LabVIEW.ini to enable a bit more info for these sorts of messages to help identify which object is causing the error and whether its a BD or a front panel issue. Neville.

QUOTE (Norm Kirchner @ Aug 18 2008, 06:47 PM) For code used by our customers, I always incorporate a VI at the end that silently writes the error, date, time, and the error message to a file in an automatic folder C:\Errors. Since I work with Vision, I also save the offending image with an error#-date-time file name. For some reason Vision VI's are not very good at displaying their call-chain, so I usually add a chain showing which Vi, and state in the state-machine the error occurred. I also add the ability to log individual states in every state-machine to debug problems but I have never needed to use this at a customer install. Neville

QUOTE (Götz Becker @ Aug 14 2008, 12:44 PM) There are very few functions that are RT-only. Even these usually have a non-RT equivalent, so there is not much to try out. QUOTE (Götz Becker @ Aug 14 2008, 12:44 PM) or communication to a host app. You could always write code that is supposed to run on RT and then run it on Windows (or other). RT is a subset of Windows capabilities. The only areas where this wouldn't work out perfectly is if you want to check out speed. Execution time on RT may be more "deterministic" or the Symmetric Multiprocessing might work out better on that platform. Another area is if there are bugs on one platform that are not on the other. As to whether you can do what you want with VMware etc, I don't think so. Easiest bet is to buy a LV-RT runtime licence, get a cheap PC that conforms to the requirements for LV-RT, load it on and treat that as your RT target. But like I said, your better off testing functionality in a non-Rt platform. Neville.