torekp

If you put this Xcontrol [...]

Re-posting these VIs, because someone asked about them.  LV 8.5.1.

 

Since I don't have permission to attach them here, here are Dropbox links instead:

 

https://dl.dropboxusercontent.com/u/30346948/Data_rel_path.ctl

https://dl.dropboxusercontent.com/u/30346948/example_relative_path.vi

https://dl.dropboxusercontent.com/u/30346948/Facade_rel_path.vi

https://dl.dropboxusercontent.com/u/30346948/Init_rel_path.vi

https://dl.dropboxusercontent.com/u/30346948/path_absolutely.vi

https://dl.dropboxusercontent.com/u/30346948/relative_path_to_home_etc.vi

https://dl.dropboxusercontent.com/u/30346948/State_rel_path.ctl

https://dl.dropboxusercontent.com/u/30346948/Xctrl_rel_path.xctl

 

Give us more detail? How about a small subset of your data, e.g. 100x100 points in a tab-delimited spreadsheet. Provide X and Y axes, since you imply dX is not constant. And attach your VI.

But beware: if one of your threads closes the task, and then another tries to access it, you can get the old unnamed task error, I think. I'm pretty sure I've done this bellyflop at times.

Thanks folks! I will look into your suggestions ASAP. As to why: it's not my choice. It's pretty much forced on me by an equipment vendor who wrote some highly unreadable Labview code that can only do what I want via Windows messaging. Unless I learn even more C programming than I already seem to be stuck with. They provide a sketch of some C code using Windows messaging, but you have to fill in some blanks.

At http://zone.ni.com/d...a/epd/p/id/4394, NI provides some example code for using Windows Messaging in Labview 2009. But the example generates and intercepts the messages in the same single toplevel VI. Is it possible to converse between two VIs using Windows Messaging? Would I need (or be able) to create a new DLL in order to do that?

Toplevel:

Create Windows Message Queue:

From the Readme file:

**How it works**

A DLL included does all of the dirty work. The VIs in the library are primarily

wrappers around the DLL with the exception of Wait for Windows Message.vi.

When creating the first Windows message queue, the DLL installs a windows Get Message Hook and a CallMsgProc Hook on the LabVIEW process. This allows the DLL to inspect all messages heading for LabVIEW before LabVIEW processes them. The hook function determines whether each individual message is a message in which the queue is interested. If it is, it adds the message to the queue, and sets an occurrence. The Wait on Windows Message.vi is waiting on the same occurrence, and thus it continues its execution, retrieving the message from the queue. A number of utility functions are also provided for working with the queue.

--------

Any advice appreciated, even if it's "abandon all hope". (I'm a very weak C programmer.) I'm attaching the CPP code for the DLL, as a text file.

Windows Messages for LabVIEW.txt

something along the lines of this (Windows 7). Right click Computer -> Properties -> Advanced System Settings -> Advanced Tab -> Environment Variables...

Yup, thanks. Basically the same on XP. Instead of defining a custom variable, though, I just put

cmd /c echo %ComputerName%

in the string, and otherwise identical to your block diagram. Thanks again.

Thanks guys. I don't really need the IP addresses; that was just the only way I knew how to ID the computer.

John, can I do your trick in LV 8.5? I can't seem to find the "Environment" property.

jkuehn, How do I tell Windows to set a custom environment variable? Is there a Windows system file that I edit?

Here's a trick I've used to tell which computer my Labview exe is running on:

Most of the computers at my workplace have two ethernet connections, local and network. All network addresses around here begin with "172" so I use that to distinguish the two.

This works as long as the connection of interest (Local, preferably, since that connection is not so intermittent ) is maintained. Alternatively - on SOME computers but not all - I've found that using the network address works, even when IP number 0 is fed to the IP to String function. That function knows, on some computers, the computer's name (e.g. "Paulsdesktop") even when fed a 0.

But I'm sure somebody out there has a better way to tell which computer you're running on. What is it?

Sorry I didn't see this sooner. When you download the llb, you may also have to create a directory C:\WORK Or maybe not, it might create it for you, I haven't checked. Ignore the double-backslashes, those are just escape characters to please the C program inside some code interface nodes. The actual file is C:\WORK\RBFModel.txt

Related question: does this apply to VI server also? That is, do I need to explicitly open an application reference using "localhost", rather than just opening a VI reference, for fear that the network connection may get disconnected.

Thank you all, you just saved me a lot of experimentation!

The way LV stores flattened data is explained in the LabVIEW help (presumably the flatten primitive has a link to the relevant section).

It doesn't have that link, and what I found on my own wasn't helpful, but a little experimenting showed what's going on. For arrays, you get 4 bytes containing the (big-endian) length of the array, followed by the elements (e.g., 4 bytes per SGL) in standard format (IEEE blah blah).

So I wound up just programming the LabWindows computer to parse the flattened data in the corresponding way. Unfortunately, the communication device (a reflective memory card) giving the Labview data to the other computer transformed the data to little-endian. So some pointer magic was required on the receiving end to reorder the bytes.

My title pretty much sums it up. I need to flatten my data to a byte array to pass it to another computer. (Via reflective memory cards, if that matters, which it really doesn't.) The other computer has CVI LabWindows. Unfortunately there is no equivalent function, so far as I know, in LabWindows, exactly like Unflatten From String in Labview. If I'm wrong about that, I'd be glad to hear it.

So the next best thing is to find a pair of ways to flatten and unflatten that are both reasonably fast. If anyone knows the secret formula for Labview's flattened data (for data types string, 1D array of i32s, and 2D array of SGL) that would help a lot. Including big-endian or little-endian conversion of i32s, and where the mantissa from SGL winds up.

Back in the day, before LAVA migrated, there was a Tips and Tricks thread. It was pinned, making it easy to find. I believe it was in LabVIEW - General.

Is there still such a thing? I couldn't find one. Do we need one? Is there a useful one on the NI website that we should contribute to, instead?

I just discovered an interesting (by which I mean aggravating) aspect of the picture functions that I'd like to warn people about. (They're very slow, and seem to update the picture in real time even if you do the operations behind the scenes of your GUI in undisplayed subVIs. Things go much faster if you manipulate the flattened image then draw the picture when done.) But where to post this tidbit?

What is it? What does it do and what is it for?

It predicts class membership based on associated variables. In my job, we want to classify scrap metal bits based on color (red green and blue), for example. Say we want to separate brass versus copper from a mixed pile. The Support Vector Machine is a "supervised" classifier meaning that we start with sets of known members of each class. Use those to "train" the classifier and create a model. The model defines a hyperplane in Red-Green-Blue space with brass on one side and copper on the other. (Technically, it could be more than one hyperplane, but for me, in practice, just one.)

Suppor Vector Machine wiki. Kernel Discriminant Analysis is a closely related concept.

I'm attaching another version below. This one limits the parameter search in C and gamma to make it go faster, although my work there could stand some improvement. It also, in some sub-sections, assumes that you only have three dimensions (red green and blue) to your data. If you want to use this on data with more than three dimensions, it shouldn't be hard to find the limiting subVIs and modify or delete them.

Color_SVM_3d Folder.zip

Here is a Labview program that I found very useful. I made minor modifications to make it more useful to me. Its core is LIBSVM by Chih-Jeh Lin and Kiwoong Kim.

Since writing these, I developed some further advancements but I haven't wrapped those in a neat package yet. Let me know if you're interested.

Labview4LIBSVM Folder.zip

Francis has the best solution for ranges that are perfectly equal, and Shaun has a good one for ranges that are arbitrary (e.g., 1 to 6, 7 to 20, 21 to 22, ...). But for arbitrary ranges - a look-up table - I use the array thresholding function. Input the upper boundaries as the array input, and your test value as the scalar input. Round the fractional index down, and that gives you your category number (0-based - you can then add one if you like 1-based notation).

When I read the title of the thread, I wondered if the "biggest scam" was the global warming hypothesis or the elevation of Phil Jones's misconduct to "-gate" levels.

I'm still wondering.

I think the software might be particularly useful for (detailed, complex) arguments. Or tricky diagnostic procedures. I'll probably come back to it at some point for those purposes.

What mind maps are. I've played around with FreeMind a little, and have a hard time seeing how this will be worth the effort. Am I missing something? Wrong software? Forget software, do it by hand? Just a few more hours to get past the bump in the learning curve and see how wonderful this stuff is?

But the executable on Spec already has to be running to "hear the call", does it not?

I should clarify: I was hoping - this will sound crazy, I know - that I could have no executable at all, running on the Spec computer, and then start my executable remotely. The Microsoft utility psexec lets me do that! , so I may well use that. Or I may just stick with what I've got now - a small LV exe on the Spec computer, which periodically reads a certain file on the Spec computer. When the Control computer writes the word "start" into that file, the Spec.exe uses LV server to start Spec_Main.vi (as executable), the actual do-the-work program, which is an "always include" in the build.

When using VI Server over entwork, connect to the App.Instance of the other PC. I don't remember the details, but I think it was just as easy to start the LV runtime...

Felix

I'm getting error 7. Relevant parts of my .exe's INI file:

server.tcp.servic="My Computer/VI Server"

server.tcp.enabled=True

server.tcp.acl="+localhost" [note, I also tried server.tcp.access = this]

server.tcp.port=3362

server.vi.callsEnabled=True

server.vi.propertiesEnabled=True

Block diagram of caller:

Note, I'm just testing locally for now, just to see if I can open and run a .exe The path is definitely correct; I put a "current VI path" constant on my EXE's block diagram and added an indicator.

Labview 8.5

VI server works with an exe so.... what is the issue?

But the executable on Spec already has to be running to "hear the call", does it not?

Look at the SysInternals tools (now a part of Microsoft), specifically PsExec.

That sounds interesting, I'll have a look.

Thanks everyone!

Since you say this calculation is enormously expensive, I'd advise you NOT to make a sub VI inside a loop. At least, if your sub VI would also have its own loop(s). Instead, leave the two nested loops inside the same VI, perhaps by moving the outer loop to also be inside the sub VI. I once had speed issues with a VI, and called NI for help, and they advised me to move my outer loop inside the sub VI. I did, and that helped greatly.

I've got 2 computers that need to work together. The Control computer accepts user commands and displays a few indications of how the job is running. The Spec computer does the serious number crunching, and usually gets no user input at all. To keep it simple, pretend the executables are named Control.exe and Spec.exe. I would like Control.exe to start Spec.exe, but I don't know how. Once they are both running they will communicate with no problem (via reflective memory cards and optical fibers) - I've got that covered.

Right now, I've got an actual Labview VI, Spec.vi, on the Spec computer. Labview stays open on the Spec computer, and Control.exe uses VI server to open Spec.vi and run it, and that works fine. BUT - I'd rather have an executable, and not run the Labview development environment - I figure that's leaner and meaner, somehow.

One thing that occurs to me is to have a two-part Spec.exe. One very non-resource-intensive part would run all the time, and when Control.exe demands it (still using VI server?) that part would open up the main part and run that.

Better ideas welcome. I'm not very TCP-IP / .NET / etc savvy, so if you're going there, dumb it down a bit please.