Neville D

QUOTE(BrokenArrow @ Jul 17 2007, 05:51 AM) LV 5.1.1 probably isn't supposed to run on XP. Don't know about 2000 Pro; I would go with 2000 Pro for such and old application, just to make sure everything works. Otherwise just re-build using a later version of LV (7.1.1 is pretty rock-solid, 8.2.1 isn't bad) and use XP. Neville.

QUOTE(jlau @ Jul 11 2007, 08:13 AM) TCP communication should work regardless of platform. Have you tried running the code on the desktop? The TCP primitives themselves should handle any platform specific details invisible to you. Like others mentioned there are a few functions (usually from the RT pallet) that won't work on the desktop platform (and vice versa for any ActiveX calls etc. for RT platform), but the large majority, I would say 99% of the code should work fine on the desktop. -------------------edit------------------------- Looking at your earlier screen shot, looks like you have some RT FIFO VI's; these won't work on the desktop, but you could probably replace those with Q VI's (use a case structure wherever you have the FIFO VI's and replace with equivalent Q VI's) and the code should run. Neville.

QUOTE(jlau @ Jul 10 2007, 08:31 AM) Hi Jean, there is no means to simulate an RT device, but your RT code should run even on your desktop PC (so long as you have equivalent hardware). What sort of application is it? DAQ? Vision? Neville.

QUOTE(mateo @ Jun 26 2007, 09:52 AM) What do you mean by "great amount"? Is it affecting performance? How large of a JPEG file are you trying to encode? The buffer in Encode may be re-usable for future calls. I wouldn't worry about it unless it is drastically affecting performance. Neville.

QUOTE(dwisti @ Jul 6 2007, 06:11 AM) True, but a single element Q will be computationally more efficient with less overhead thanthe shared variable architecture. Neville.

QUOTE(orko @ May 24 2007, 10:34 AM) I found that mass-compiling the \National Instruments\Advanced Signal Processing Toolkit sped up my launch times to near light speed! Strange, since this folder has VI's in 7.0 without diagrams, and mass compiling should not change them. Neville.

QUOTE(Gary Rubin @ May 31 2007, 05:45 AM) Check out OpenG's "Conditional Auto-indexing Tunnel" (quite a mouthful of a name) under the array tools. It does exactly that. Jim Kring posted a blog article on it recently as well. Neville.

QUOTE(EJW @ Apr 25 2007, 12:56 PM) I think you are correct. Property nodes won't create copies, BUT they are even slower than Locals, probably due to the thread switch to the UI thread among other things. In terms of speed: Wire is fastest, followed by local, followed by property node. In terms of initialization, it may NOT matter for a few (even a few hundred) variables what you use to initialize, and property nodes will even help you keep the block diagram neat, burying the nodes in a sub-VI and reusing it for resetting properties of similar variables. I guess that was the idea in having the value property. Neville.

QUOTE(ooth @ May 10 2007, 05:59 PM) Hmm... I haven't seen that. I have an RT utility application using the internet toolkit to download and upload files, reboot targets backup their drives etc. It was written in 7.0 and migrated (and modified) all the way to 8.2.1. It has an event structure that detects either the stop button pressed, or the close window event and then gracefully exits (fast). Do you have some open references and such lying around at the end that are being closed by LV before exit? I would look at the shutdown sequence in the code. Maybe look at the toplevel VI settings, and play with those. Neville. QUOTE(jhoskins @ May 10 2007, 03:11 PM) This is really annoying. I got a complaint from one of my fellow engineers on the floor. His complaint was that when he closed my program it took the program a long time to not be visible in the taskbar (not really a big deal to me). I mean the FP goes away but the taskbar indicator stays up for as long as 30 sec or more. I tried it on my developement machine and sure enough it does the same thing. So I decided to put in the quit LV function, same result. Then I decided to downgrade the program to LV 8.0. I did that and built it into an EXE and it worked perfectly. As soon as I closed the front panel it was removed from the task bar within a second or two. So I then built (using 8.2.1) a really really small app (while loop, random #, Indicator) and built that into an EXE. I ran it and it had the same results. Has anyone seen this type of behavior using LV 8.2.1. I have attached that original problem VI. I took a look at your app. On panel close, the DAQ task isn't wired, which means the Clear task is going to error out. Try with that fixed. Neville.

QUOTE(John Rouse @ May 8 2007, 10:46 AM) John, For a complete explanation see http://openmeas.blogspot.com/2007/02/la-mort-du-serpdrv.html' target="_blank">Brian Powell's blog Serial support isn't being removed; just the ancient serpdrv with its potentially buggy architecture WILL be removed in a future version. It's only a matter of time. All the issues that people have with the VISA serial implementation (licencing, size) have long since been solved. Time to move on. Neville.

QUOTE(young grasshopper @ May 7 2007, 09:07 AM) I think hardware or softwared timed AO should work fine. Take a look at the DAQmx examples; you should see one that matches your needs. N.

QUOTE(young grasshopper @ May 7 2007, 08:03 AM) Your question isn't very clear.. do you want simultanous analog input and analog output? Or is the AO calculated off-line? The frequencies seem fairly low (80Hz?) so you should be able to get away with software-timed analog output. This will allow you to change the frequency. You should be able to use hardware time Analog Input. I'm not sure if you can do hardware timed AI and AO simultanously while changing the frequency of the AO; most probably not. DAQ cards usual have only one on-board FIFO, which limits you to only one of the above. Using a more expensive DAQ card (for example M-Series as opposed to the cheaper E-Series) will allow you more DMA channels for simultanous AI/AO (but still won't allow changing the AO frequency on the fly). Speak to your local NI rep or call NI for more in-depth info. Neville.

QUOTE(Pablo Bleyer @ May 4 2007, 02:57 PM) I meant the VI's that you have written might be corrupted, not the vi.lib VI's. Your comment about "LV recovered the VI backup" brings to mind a similar problem I had a while back. The so-called "recovered" VI from backup was the one that was corrupted in my case. It caused all sorts of strange crashes, till I replaced it with a same VI written from scratch. If you remember which of these "recovered" VI's you used, I would advise just re-writing them or else obtain a copy from some old backup and modify. I'm pretty sure thats your problem. Neville.

QUOTE(Pablo Bleyer @ May 4 2007, 01:05 PM) Maybe some VI in your project got corrupted after the upgrade process? Is it really related to the size of your data file (doesn't crash with smaller files)? Go back to a previous backup of the VI or project and try to mass-compile/re-compile the project. See if it re-occurs. Nevile.

QUOTE(Thang Nguyen @ May 4 2007, 07:43 AM) If you do a test "for 3 days" do you have to see every single pt of data you have got? You need to think about the resolution of your monitor wrt to the number of points you are trying to view. Or maybe resample your data points so that the dt is the same for all plots and then just use a chart. There is an express VI to resample data. Extract out the necessary VI's from it for your use. Or else, some form of intelligent data decimation is required. There is an article on the NI site on data decimation for display. Neville.

QUOTE(Louis Manfredi @ Apr 26 2007, 06:07 AM) Maybe they are justifying the ridiculous shipping charges that they now charge which is a percentage (10% ?) of the purchase price. i.e. if you bought SOFTWARE worth a few thousand dollars, you get charged hundreds of dollars to SHIP a few CD's!! Maybe this justifies the expensive looking cardboard carton as well. Neville.

QUOTE(eaolson @ Apr 24 2007, 03:01 PM) Hmm.. I seem to be able to write the data and read it, while the image buffer is maintained. But saving the image doesn't seem to save the meta data as well. Silly me!! There is a SEPARATE VI "IMAQ Read image and vision info".. the regular "IMAQ Read Image" won't work.. Neville.

Hi all, Is there a way to embed some additional text information to a png image file? I want to be able to save some image crop information to the image to avoid having to maintain an additional file. There seem to be some VI's "IMAQ Write Custom Data" and "IMAQ Read Custom Data", but they don't seem to be able to save the information to the png file. Anybody know what those specific VI's are for? Thanks, Neville

QUOTE(kate @ Apr 24 2007, 03:21 AM) Do you have the IMAQ Vision toolkit? It is an add-on NI product. I would recommend you get it if you don't already have it; (it is expensive though and needs separate paid, run-time licence as well for executables). There are functions to convert Image buffer to 2d array as well as functions to cast an image to another type. These are optimized for speed when dealing with large image buffers. Neville.

QUOTE(ControlEngineer @ Apr 17 2007, 10:11 PM) AAAhhh..!!! You should have stated this earlier. I suspect you will be able to control AT MOST 2 motors with a single DAQ card. The reason is that each card has only 1 FIFO and if you are dynamically going to be changing the frequency and or the Output value using hardware timed IO, you will be able to do it for at most one output channel. I think you will need to use counters for the pwm and not the digital outputs. You are limited to two counters and may even need both for one pwm. Sorry I haven't used DAQmx in a while, but its going to be difficult to control a whole bunch of pwms with a single DAQ card. Just build a little "Analog Voltage in->PWM out" circuit and control via the analog output. Neville.

QUOTE(ControlEngineer @ Apr 17 2007, 02:27 PM) Whats the problem with using an analog output? Neville.

QUOTE(Sally @ Apr 13 2007, 03:23 AM) I think what your after is a chart with the ability to have variable time input (x) values as well. Currently, there is no such plot available in LabVIEW. You will have to build your own based on a graph with history data stored in shift registers. I think there is an example of that in LabVIEW.. just search. Note that performance is not that great (for intensive applications) with a graph since all the points are re-drawn for every update. Neville

QUOTE(ecarrig @ Apr 13 2007, 09:37 AM) If its under warranty, you could probably get it repaired by NI.. Check that you are using an ESD strap when installing the unit into the chassis. I have used them in the past and never had problems measuring quite high voltages (around 60V) as well as much smaller values simultanously. Neville.

QUOTE(Mike Ashe @ Apr 4 2007, 10:41 AM) Hi Mike, Have you taken a look at http://www.kshif.com/calcexpress/' target="_blank">CalcExpress by Konstantin Shifershteyn? Its not free, but when I tried the demo version a while back it beat the pants off the NI parser. It also has a lot of additional functionality that you may not need, but what the heck. Neville.

QUOTE(Tomi Maila @ Apr 4 2007, 06:59 AM) Try the combo box control. It allows separate display and value strings. I think it came out with LV 7.0 Neville.