amw253

I have a suite of compiled DLLs. One of them is essentially the "Load Data" function where you pass it arrays of values; the second is a "Compute" function, which uses the values you gave it earlier. However, the "Load Data" function isn't stashing away the data, but simply storing the array pointers for the "Compute" function. I need to arrange for LabVIEW to keep the data - untouched - and in the same place, between the calls to the "Load Data" and "Compute" DLLs. I've tried using shift variables and global variables, but they appear to both cause LabVIEW to copy the array data and pass the pointer to the copy on to "Load Data", and then throw it away. So now when "Compute" is called, the saved pointer is to memory that may have been reallocated. *Crunch*. Time to restart LabVIEW. I could do this in "C" with a "static" declaration (using memory from the data and/or heap, not the stack), but I'm still new to LabVIEW. I checked the existing threads and didn't see this question asked. Could somebody please advise? Thanks, Andrew

A followup question ... I have a subVI returning a typedef value (a ring of listed unsigned shorts), and I would like to feed that result into a case statement. However, instead of giving me options for each possible value of the typedef, I get the standard list of ("0, default", "1"). How do I specify the type of the case selector? The "?" is wired directly to the output of the subVI ... :question: Andrew

I've read of the manuals that came with the LabVIEW 7.1 Developers Suite (what, no "yawn" smiley?). I'd like to define constants across all my modules, like the old-fashioned "#include" feature in a C pre-processor. I've seen examples of what I want ".ctl" files - but somewhere along the line I've missed the chapter, section, etc. that explains all this. Could somebody please tell me where it is? Thanks!

I'm converting an existing application suite to LabVIEW - it needs to talk to existing systems so I cannot redesign from scratch. Essentially I'm writing a bunch of "small" modules that establish TCP/IP sessions to each other, as required. If two of these modules are simultaneously running under one LabVIEW runtime, this uses up two TCP connections under the one Windows application. I'm finding that I'm quickly running out of connections within the LabVIEW runtime - at about 20, it seems. I thought the limit was 1024, or some such large number. Please, what have I overlooked? Thanks in advance.

I greatly appreciate the comments received. I wasn't aware that LabVIEW was MAC-Endian - fortunately the command structure is such that it can automatically determine the endian-ness of the remote incoming data structure and translate to the local architecture (not quite like XDR, as there isn't a "network standard", just a recognition of how the other side is different). This comes from the program's history of communicating between multiple PCs (MSDOS) and SparcStations. While coding away in LabVIEW, I did notice that the alignment rules are "unusual". For example: struct example { };has a sizeof(struct example) = 8 in most "C" implementations, but a "Flatten to String" and TCP Write generate only six bytes of output. So I've had to clean up those poorly aligned structures and stick a padding short between VariableA and VariableB. I have a couple of new questions I'll post in more appropriate places (feel free to help out some more!), but I wanted to express my gratitude for getting me "unstuck". Thank you!

NI provide a nice example of a "Simple TCP/IP Messaging Protocol" library at http://zone.ni.com/devzone/conceptd.nsf/webmain/ 0986799C984500F886256F170079411E. Essentially it uses XML tags to transfer Metadata information prior to message data, and then references Metadata elements for each data transfer. The LabVIEW client at the other end of the TCP socket references the data descriptor back into the appropriate data structure. However, this solution requires LabVIEW at both ends of the socket, and data is transfered via strings (bandwidth and CPU are not of concern). In my situation I have an existing network application that is expecting a documented "C" structure, often with binary data. The C code would be highly confused if it started receiving XML strings instead. I'm looking for a mechanism to have LabVIEW read and write such fixed size data structures: }; followed by an array of "Nvalues" floating point numbers. I do not have the opportunity to re-write the C application, but need to make the LabVIEW client talk to the existing "fixed size" binary protocol. I know I'll need to munge the byte ordering too, but there are existing subVIs for that. Ideas or pointers, please! Thanks, Andrew

I find myself revisiting a suite of C programs I originally wrote over a decade ago :!: with a view to converting them to LabVIEW. The suite uses impromptu TCP/IP-based data flows between functions, allowing for components to be tested and added in parallel, including remote monitoring and control. I've spent some signficant time looking into the capabilities of LabVIEW and have come to believe that an overall redesign isn't required, mostly just a re-implementation (the exception is the X11 graphics - most of which will quickly collapse into a standard LabVIEW front panel). Now the hard stuff... I know how many lines of C code there are in the common libraries and individual modules, and I'm familiar with the workings of the original program. I'd appreciate some insight on the following: :question: Is there a known ratio of C complexity to LabVIEW complexity? Perhaps C lines of code to LabVIEW "Nodes"? :question: Is there a typical "productivity" rate for LabVIEW programming - excluding design time? :question: What other metrics should I look at to determine an estimate of time required? I'd like to assume that the LabVIEW coding will be of the same standard as the original C coding, and coding includes testing, debugging, documentation, etc.. Thanks in advance, Andrew