jpdrolet

I think that the attached VI is still a better implementation, getting the name as the port is known in the OS using the Interface Description property. The property node reports strings like "ASRL19 (COM17 - EdgePort [i40300200-0] Serial Port - 1)" (from a USB serial device) where one can scan for the real port name COM17 instead of COM19. It also lists the ports shared by other computers using VISA Server. Edit: I disconnected typedefs and included Convert to VISA Rsrc.vi Download File:post-447-1148580610.vi Download File:post-447-1148580635.vi

That VI works. You should have posted the VI with the formula node that doesn't work. Please help us to help you.

On the Write File node wire the input "Write Header" to True

:laugh: :laugh: :laugh: In the mean time you could read LabVIEW help on arrays, For Loops, auto-indexing and related examples. You want to learn LabVIEW don't you? Or use your math skills to factor these summations into a squared double summation?

That is confusing, you use the label n for both the number of elements AND summation index. Also the result will be a scalar, not a 1D array. What steps did you try to compute that summation?

Now I just add a Run VI method as the last node and I hit the Run Arro(&(*&!@HJ(*&47_)(* --- DISCONNECTED

Instances of a typedef are not perfect clones of the typedef. The instance can have a different label, description and default values. Default values is a data related, not type related and in the majority of cases, it is a very good thing (if not mandatory) that default values are not updated with the typedef. If I recall correctly, there is a trick you can use to force the default values to propagate: change the numeric to a string, apply changes, change back the string to a numeric, change the default value, apply changes. Then the default values are propagated with the type change. I'm not 100% sure it works but have no time to test it now.

There is and it is called a Variant. Re-read previous answers more carefully.

But they actually are relative. If they were absolute, you wouldn't be able to move a project directory without breaking all links to subVIs. How did you come to the conclusion they were absolute? Edit: unless there is a major change of behavior in LV8...

LabVIEW knows where vi.lib, user.lib and instr.lib are located but the executable does not. It expects these folders to be in its own application folder. A VI that opens fine in LabVIEW will be broken in your application when subVIs are located in these special folders. They are special in the sense that the path of subVIs located there are stored as symbolic path ( e.g. <userlib>\path\to\sub.vi ) so subVIs are found wherever these libs are located in a particular installation. Other subVIs paths are stored in the caller as relative paths so any changes in relative paths to subVIs will also break the VI. When the VI is opened in an application, all subVIs must be at the symbolic/relative path they are expected or the VI is broken. That's why saving for application distribution solves the path problems, saving the whole hierarchy at the same place and relinking VIs to the new location. Since the process might duplicate subVIs (both in application and plugin llb) now when the application opens the plugin VI where the subVIs be loaded from? First the memory is looked for a VI with the same name. If not found there the internal LLB of the apllication is searched for a VI with the same name. If found there the actual path of the subVIs is ignored and the internal VI has the precedence to be opened. If not found in the internal LLB, the subVIs is looked at the stored relative/symbolic path. Finally, when the subVI is not found, the search paths specified in the search path list (in the options) are searched (the seaurch path can be stored in the app ini file) Indeed in my first post I didn't mean that the plugin VI to be distributed with the application and its installer but just dropped in a folder where the application will look for plugins.

I use the plug-in architecture with executables and it works as expected. It is important that the whole hierachy of the VI be accessible and that the executable installer has correctly installed the required resources (serial, math lib, etc.) I usually do that by Save with option>Application distribution. It saves a lot a VIs that may already be in the app.exe but it is harmless. If you can give more details on how you proceed maybe we might find the source of the problem...

See this FAQ

Look at this NI Forum thread. There is a tool to save a picture of the diagram and copy its path to the clipboard, ready to paste in the File Attachment field. Check also for the hack needed to make it work in LV8. :thumbup: In the VI you could expand Replace Array Subset to two inputs instead of using two nodes.

I think that this shuffling is biased. There is a random number generation between 0 and N-1 but because of rounding the elements 0 and N-1 have half the probability to be picked than other numbers. It should be a random number between 0 and N then floored to integer. The index N won't be picked because the random number function is always lower than 1.0 Edit: it is based on the picture posted, I can't see Guillaume Leassard's VI since it is in 8.0

Well if I measure the Cosmic Background Radiation and shuflle that with the particle count/s of a radioactive substance and XOR with alfa's posts, I'll get data with no discernable pattern for sure... :laugh:

When the value of a tab control is changed using the page labels display, the value change event is not fired. It occurs in 7.0 and 7.1

Strangely the effect is much less pronounced when the subject drinks light beer... The "walking black hole" is only observed by the drinker after he reaches "extinction". The subject has no recollection of the events past the event horizon that occurs on extinction. Observer from outside can only see a collapsed inert mass.

Beer's Law is already taken! However it is about absorption of light , not beer.

In your VI you read only 10 bytes/s. My bet is that the uC sends data at much higher rate and fills the input buffer that the VI continues to read even when the uC is disconnected. When you swap to HT the serial port is reinitialized and the input buffer flushed. As for the framing problem, indeed it is the solution that the uC sends data only after a command or that to use some HW handshaking.

I don't know about 8.0 but in previous versions you indeed can have different SCC settings per project, provided you set a different default(home) directory for each project. The file scccfg.ini is stored in the default directory which defaults to LabVIEW directory. Having distinct project default directories is conveniently done using a labview.ini file per project and start LabVIEW for a given project using a shortcut with the -pref switch setting the ini file. Personally I use custom file extensions to LabVIEW pref files ( *.lv7ini, *.lv71ini) so I can start a project with the right pref file and LabVIEW version with a double-click on the pref file.

Sounds like you still have the blue eagle tatooed on your chest, Rolf... :laugh: or for sure the yellow adder.

Which 3D are we talking about here? 3D picture controls or graphs allow to display a and rotate objects as 3D objects projections but it is not 3D stereo vision where you need some way to send two different images one to each eye. In the former case we see a flat image and the brain figures depth from perspectives and relative sizes. You see the same thing even with poor eyesight on one eye. In the latter case the brain receives two images and then it can figure depth with its hardwired ability to integrate these two images into a 3D representation.

It might be a DNS lookup issue. Try to set DNSLookupEnabled= FALSE in the LabVIEW.ini file

This is a quoted message

It is easy to travel thru time, here is a quote of a message I'll write later: Note to self: Do not forget to post the above message to prevent a time paradox and the destruction of the Universe.