didierj

Also a good resouce are the two articles: Rules To Wire By - Part I and - Part II from the LTR publications Volume 7, Number 1 & 2. LabVIEW Technical Resource. Didier

First, put all the formula part into one formula node, it accepts several lines. Second, while your value "a" is 0 you will always get NaN, since the in second and third formula you divide by (2*a). Division by 0 is by mathematic rules undefined and therefore results to NaN. Download File:post-253-1134023630.vi

VISA is not confusing. Rather it makes all your communications (serial, gpib,...) equal in design. From LV7 on there is no other possibility to make serial read/write than with VISA. Go to Help\Find Examples... in your LV menu. There you will find tons of handy code-examples on how to proceed with the various tools of LV. Take the example for serial read, modify it so it to your app, and if it still doesn't work post it here, so we can check what's still wrong. This way you get most feedback, since it shows you tried and are not waiting that others to the job for you. Also a good resource of help is The LabVIEW FAQ of this site and the LV-help (even after 8 years of LV-programming it can be handy to me). Didier EDIT: Too slow in tiping...

Speed of USB to serial converter shouldn't be an issue. USB1 works at few Mbaud and USB2 works at up to 400Mbaud. Serial ports works below 1Mbaud. Many RS-422/485 sytem work at 19,2kbaud or 115kbaud. I use USB to RS-422/485 converters quite often without problem. They are cheap (much cheaper than built-in PCI cards) and can be hooked to any computer (also some desktop and barebones without PCI-Slots). As Irene stated, the included drivers build additional com-ports that can be used by your app the same way as it would with COM1 or COM2, even when the USB-RS converter is connected to an USB-Hub. The only thing you have not to forget is to look up which port is installed by the driver. This varies from computer to computer.

Michael, I don't think this solves badwolf's problem entirely. I also had this issue few times. What would be nice is the dialog box, that shows just the directory tree. Not the usual file dialog-box with the additional "Select Folder" button. For some customer (especially when they are not "technocrates") the actual dialog is confusing, since in windoze-world it means selecting/entering a file not a directory. The folder dialog-box can be opened via Acitve-X, unfortunately I don't remember where it resides.

...the ultimate way to beat your neighbours with the christmas light! ...maybe overworked? ...electricity bill still too small? ...or a serious inferiority complex!

LV 7.3 ........uh?.......did I miss something? I know LV 7.1, 7.1.1, 7.1.1f2 and then LV 8.0

1st. I hardly ever use the navigation window. Michael remembered me that it exists. 2nd. As an update to my first post of february: The last few programs I made used lot of FP-events. So I extended the loop to my monitor size (1280x1024), having some few initialization and finalization (e.g. OpenGoop class create/destroy) left and right of the main loop. Therefore this stuff resides off screen. It's not ieal, but it maximizes space for the algorithms. If I reduce the the loop the way that the class create/destroy are visible I end up having used 2 times 32x32 pixels + border and loosing the whole diagram part above and below of the classes create/destroy (means 2 times 992x32 pixels).

As a variant of yen's solution would be to: 1. Open your app, open the different "old" instrument-vi's and rename them according to the vi-names of the new driver. while renaming each call to the instument-vi's is relinked to the new vi, so you have to touch every instrument-vi only once not as many times as it is called. 2. Then save the whole (main-vi and all sub-vi's). 3. Move (not copy) the old instrument driver to a save place (not in "National Instruments" or your app folder-tree). 4. Put the new instrument driver into the "National Instruments\instr.lib" folder. 5. Reload your app. There might be a message-window, telling you this and that vi was loaded from a different location. Check if it's correkt. 6. Save your app. :thumbup: 7. Now it's save to copy your original (without the created vi's in step 1) "old" instrument-driver back to "instr.lib". Take care that you do not miss any vi (might include typedefs, templates,...) otherwise you end up with mixed instrument-calls and broken sub-vi calls . It might be a good thing to first copy the old and new instrument-vi's to a save place, in case something goes wrong or you missed something.

- Go through the FAQ on this site: The LabVIEW FAQ - Go through the examples in your LabVIEW under "Help>>Find Examples..." - Ask your NI sales rep for the LV Basic course book if you can't and won't afford the course itself. - Search through this site for references to further books (eg. under the topics "Programming Discussion>General" or "General LabVIEW Discussion" Didier

... a bit overworked recently? Mate, you might need some holiday... there is a topic discussing such cases: You've spent too much time...

I haven't seen exactly this error and the knowledge base on ni.com doesn't seem either (only a short check), but there are drawbacks, when running LV with restricted userrights. I'm fighting with simmilar problems when debugging code in production. Try following workarounds: - check that the user has WRITE access to the whole "National Instruments" directory tree - if it's ok for your adminstrator try to change the userrights from "user" to "advanced user" - check that all hardware driver (NI-DAQ, VISA,...) have the appropriate rights, esp. VISA is a bit a pain in versions before LV7 (VISA version <3.x). - check with earlier Windows versions (win2k, XP without SP2) if this happens also. It could give you some ideas where the problem stands (user policy).

If you use "Current VI's Path" then take in account that the returned path in an exectuable is of this way: <installation dir>\<executable>.exe\<vi-name>.vi So in the dev-env you use one "strip path" to get the directory, but in the executable you'll need TWO "strip path"...

As a "quick and dirty" solution to the problem, go to the event configurator. On the bottom of the window you'll find a checkbox "Lock front panel... this event completes". Unmark it. Otherwise LV won't process FP-action until your program leaves the structure. Didier

Really useful for earthquake simulation... or if you need some reason (the headache that rises when looking 5 minutes at this vi) to go home... :laugh: Somehow it reminds me of "Moorhuhn"- a small program where one could shoot down chickens. On (I think) version 2 one could shoot onto the graves: Your computer gave out an awful shriek, the chicken begun to vibrate (because they get scared) and you got double points! :laugh:

Have a look at LTR. It is quarterly publication full of examples and guides from other programmers all around the world. Epecially I'd like to mention "Volume 7, Number 1" and "Volume 7, Number 2": "Rules to Wire By". A set of 44 rules of what one should and should not do in LV. Didier

These are variables valable for your instance of LV not valid for the whole Win2k-system. Use them at whish in path variables inside LV. At least <vilib> is found in the palette File IO/File Constants/VI Library for using in a diagram. <topvi> = directory where the top-level vi resides (If I remember correct the vi you loaded first in the dev environment, or the top level-vi in an compiled app) <vilib> = C:\...\LabView 7\vi.lib directory <userlib> = C:\...\LabView 7\user.lib directory <instrlib> = C:\...\LabView 7\instr.lib directory

Not only medical and military! Thanks to mydoom, lovesan, sober (..and how all the others are named :thumbdown: ) also industry prohibit connection to the internet. In our company my computer belongs to a handful of them that can reach the outer world. On the computers in production (where I usually debug my LV programs), i'm logged in as simple user and can't reach internet. I hope NI is also going to offer a phone registration. May I express my thought: if you have the right connection (e.g. us military) and with signing enough papers/declarations, NI might also offer a activation-free version??? Didier

:thumbup: What a nice response. Congratulation to each of you who helped! As many of us suspected, the activation won't disappear, but at least seems to leave us some "free air" to work. Software activation is soooo popular that we will see more and more software be tied to it :thumbdown: . Since I haven't any other sw product from NI that needs activation, could someone explain me what it involves? Is it something like winXP? Didier

:thumbup: Nice tool, could it find its way into openG?

Thanks, it helped. I wasn't aware that I had to provide also a title to start-command, since the pdf-file I use has spaces and have to add " before/after the name. Thus <start> interpreted my input just as window-title, missed the command and returned with a "memory-full error".

Hi, The Task I'd like to perform seems quite easy, but I didn't manage to do resolve it at whish: - providing just the path and filename of the pdf-file to system exec.vi, hoping that Win calls acrobat, doesn't work. - providing the path and filename together with a "call" opens an unwanted command-line window, but works. Does anyone has any idea how to open a pdf-file with the standard-application that is installed on the computer (in other word: let Win resolve the app that is linked to ".pdf")? It should work on Win98 to WinXP, the pdf-viewer might (but must not) be acrobat reader, where the pdf-viewer is installed is unknown, if it is acrobat in which version it comes is unknown (so activeX is also not an option). Additional command-line windows are unwanted. LV version 6.1. Didier

As you have a computer that has plenty of memory, and if you use this computer just for this (and similar) application, don't bother about the virtual memory and just disable it. Windows and Linux still work smoothly without virtual memory. The only thing you have to take care of, if your os get's to the memory limit, your app that want's to allocate further memory might crash. Didier

I think Randall thought of something like this: ...most simple as possible... :headbang:

Usually, on an standard "office network", it souldn't be a problem accessing the network directly, since such networks usually are oversized in capacity. But If you have a lot of traffic on a network segment, and you have to go through this segment to write to file. E.g. Either when your fieldpoint system uses the whole network-card (on your computer) bandwith and you access the data server through the same card; or when the data server has high traffic, because many other data-collectors stream to this server. You could also get some problems when you decide to write the report at, let's say, 2 a.m. and your administrator starts the server backup at 2 a.m. (or 1:30 a.m.). Then you try to reach a rather busy server or a blocked disk (since backup software sometime require unique access to the disk while backing up), depending on the backup configuration. Writing the report locally and then copying the file with the "system exec"-vi (setting "wait until completion" to false) is probably the simplest workaround. Didier