ned

QUOTE (vijay_ved @ Jan 7 2009, 06:03 AM) The cRIO provides an FTP server; from your laptop you can simply FTP to your cRIO (ftp://crio.ip.address) and copy the files. You can also use the FTP VIs in the Internet Toolkit to do this programmatically. There's no need for your code to provide a separate transfer mechanism, although you could write one if you wanted using the TCP/IP functions.

NI-CAN offers two "virtual" ports, CAN256 and CAN257, which are internally linked to each other (anything sent over one is received on the other). You can configure one of those ports with frames and the other with channels. Change your existing configuration to receive frames and log them to disk. Whenever you receive a frame, re-send it over one of the virtual port. Use the other virtual channel, configured in channel mode, to read your data just like you do already. This allows you to add an intermediate layer for logging raw CAN data with only minor changes to your existing code. If that isn't enough of an explanation let me know and I'll try to make it clearer. I've used the virtual ports for a similar task - converting between NI-CAN and another CAN vendor's interface. By receiving the raw data on the other vendor's CAN interface and relaying it through the virtual ports I was able to read channel data through NI-CAN even though I wasn't using an NI card. Alternatively you might look into the CAN Frame Conversion Library, although I don't see the code actually linked on that page, just documentation.

QUOTE (Ernest Galbrun @ Dec 18 2008, 04:35 AM) You can't really do anything in Windows faster than 1ms predictably. The NI FPGA products are definitely capable of what you're trying to do, but they're not cheap. I don't think this is exactly what you need but I've seen http://www.omega.com/ppt/pptsc.asp?ref=PCM4&Nav=temp10' rel='nofollow' target="_blank">this module from Omega for converting an analog (4-20mA) signal to a pulsed output for use with a solid-state relay.

QUOTE (X_DOT @ Dec 12 2008, 07:11 AM) You can also use "Scan from String" with the appropriate format specifier to convert a string to a timestamp.

QUOTE (xilverbolt @ Dec 8 2008, 05:27 PM) We know you're a n00b if you use the phrase "Expandable" in reference to a subvi... (I might be wrong - does anyone actually use that style of subVI, or are we all too set in our ways from before that was even an option?) Right click on the icon in the upper right corner of your front panel, choose "Show Connector". Click on any empty (white) terminal, then click on the front panel item to which you'd like to link it. If there are no free terminals, you can add one by right-clicking and choosing Add Terminal.

QUOTE (Callista @ Dec 3 2008, 03:20 PM) It looks like you've made a good start on this assignment and you just need to spend more time learning how to debug LabVIEW code so that you can find your error(s). Try using execution highlighting (the light bulb icon in the toolbar) and probes (right-click on a wire and choose probe) to follow the values on your wires as the program runs. It will also help if you clean up your wires and make sure they don't overlap. Right-click on your tanks and set the digital display to visible so that you can see the actual numeric value that your code is computing. There are a few style issues - there's no need for sequence structures nor property nodes and you could move some of your calculations outside the while loop to reduce redundant computation - but focus first on getting your existing program working.

QUOTE (subasa @ Nov 24 2008, 08:18 AM) I don't think your problem is your skill in C programming, since the code you posted appears to be VisualBasic.

I realized after posting that I can do the two-element case with a matching pair of "Swap Values," taking advantage of the boolean input. I suspect that can be expanded to the general case, but would get messy in a hurry.

I have a cluster containing two identical child clusters. At runtime I want to unbundle one of those child clusters, do some work on it, and bundle it back into the parent cluster. Is it possible to do this in-place? Even with the new memory management structures I can't figure out how one would accomplish this without using a case structure and creating one case for each child cluster. Am I missing some good explanation as to why this isn't possible? This is mostly curiosity, as my child clusters are small enough that creating a copy isn't a problem.

QUOTE (hfettig @ Nov 11 2008, 10:11 AM) Note that this example does not do the network delay compensation that you said you're trying to avoid. It does pretty much the same thing as a request to your PC for the time, except it queries a more precise server much farther away.

QUOTE (ned @ Nov 9 2008, 09:36 AM) In case anyone else takes this approach, I just learned something from experimenting with it a bit more - the user data type does not need to match the actual event data type exactly. The user event data cluster can contain only a subset of the elements in the real event data, in which case LabVIEW will only allow you to access the ones that overlap. In my example above I could leave out "CtlRef" in which case the value change event would no longer have access to the control reference but the rest of the data will still be available.

QUOTE (ned @ Nov 7 2008, 10:18 AM) Oops, my apologies. While there are several DAQmx examples with "PID" in the name that show up in a search, it turns out that none of them actually contain a PID implementation, they all only implement proportional control.

QUOTE (ianalis @ Nov 9 2008, 06:00 AM) A very simple approach is to use the "Value Change (signaling)" property of your front panel control. When the menu selection occurs, wire a value to that property, which will cause the "Value Change" event to occur. An alternative is to create and register for a user event that duplicates a value change event, then handle that in the same case as value change as shown below. In your menu selection case, trigger that user event by using "Generate User Event. http://lavag.org/old_files/monthly_11_2008/post-3989-1226241343.png' target="_blank">

QUOTE (blitzkrieg @ Nov 7 2008, 03:25 AM) Open the Example Finder and search for PID; there are several DAQmx PID examples that don't require the PID toolkit.

Based solely on the content of that error... are you trying to programatically bind a control that did not previously have a network binding? It looks like that error is telling you that you can change the path of an existing network binding, but you can't add a new one. Can you set a dummy path for all your variables, then set the path you actually want within your program?

QUOTE (baseballjunkie @ Nov 4 2008, 07:13 PM) You'll probably find that it's a lot easier to work with text files than with Excel spreadsheets; fortunately you can save your Excel file to text. It's then easy to read that file into LabVIEW (look at the file operations palette for "Read From Spreadsheet File"). As for interpolation, there are two functions in the array palette that will help you here: Interpolate 1D Array and Threshold 1D Array. Start writing some code, and if you need more help, post the code that you've already written first.

QUOTE (jithesh @ Nov 3 2008, 09:16 AM) I haven't used this particular barcode reader, but it appears (according to the manual) that like most barcode readers this one can act as a keyboard or a serial device. No special driver is necessary. You can either use the keyboard emulation and read the barcode directly into a string control, or set it to serial mode and use LabVIEW's VISA commands to read from the serial port.

QUOTE (Michael_Aivaliotis @ Mar 13 2008, 07:06 PM) Maybe this was an intentional change, but is it possible that at some point this will go back to the old system where you didn't have to click "Mark all forums as read" in the "View New Posts" list? Related to this would be having the count of new posts on the front page also reset, so I don't have to click "View New Posts" to see how many new posts there have actually been since my last visit. I don't usually log out so the system now thinks there are several thousand new posts.

It sounds like a good start for you would be to break down the parts of your program into small tasks that are reasonably easily achievable and will allow you to learn LabVIEW in steps. Look at some of the many examples provided with LabVIEW and try to find a book on LabVIEW at your university library. You might start with a simple program that only runs the motor back and forth; or, put off the hardware until later and write a simple LabVIEW program that handles your interface and accepts simulated inputs. Once you have some LabVIEW code written, if you post it here and explain the specific errors that you're seeing, there will probably be someone happy to try to help you out.

QUOTE (km4hr @ Oct 21 2008, 03:19 PM) No - your observations are incorrect. Many (most?) of us use the application builder (which is not part of the Student edition of LabVIEW) to build compiled applications, thus allowing us to distribute applications to users without any of the issues you're having and without requiring users to have LabVIEW installed. The Student edition is designed to allow students to learn LabVIEW inexpensively, but for real projects you want to be using at least the Full development system. QUOTE (km4hr @ Oct 21 2008, 03:19 PM) Nearly every tutorial I've seen shows how to create a Stop button. Usually by breaking out for a "while loop". But I haven't seen any tutorial on how to create a Start/Re-start button. Apparently there's no way to re-start a VI from inside the "program". Normally you would instead design the "Start/Stop" as part of your overall program, so that there's never any need to have LabVIEW stop running the program at all. Instead if your user clicks a "Stop" button it simply stops whatever action the program was executing, but the program itself continues to run so that it can start again when the user clicks the "Start" button.

QUOTE (NeilA @ Oct 20 2008, 01:36 PM) My guess, based on that error, is that you're almost there. In Open VI Reference, if you don't specify a path to the VI, you need to have the VI you want to call already loaded into memory (as per the documentation). Just double-click it in the project explorer so the front panel is open, and then try the web service again. A better long-term solution is to place a Static VI Reference to Queue Item.vi on the block diagram of the the test executive so that you can be certain that anytime the test executive is running, Queue Item.vi will be loaded into memory and available through VI Server.

QUOTE (NeilA @ Oct 20 2008, 11:39 AM) If you use the approach that Nathan suggested you can avoid the Open App Reference. Your problem here might be due to your corporate firewall (although if it's just communication from the local machine to itself I can't see why the firewall would block it). Before assuming it's the firewall, make sure you've allowed access through TCP - right click "My Computer" in the project explorer, select "VI Server: Machine Access", enter "localhost" in "Machine name/address", select "Allow Access" and click add. You can also enter "*" as the machine name to allow access from any computer. Similarly, under "VI Server: Exported VIs" make sure that the VI you want to run through VI server is accessible. A quick explanation here about Application Instances, and the difference between using TCP (as I did it) or ActiveX (as Nathan suggests). Each LabVIEW project executes independently of any other projects that might be running on the same machine - each project has its own instance. There is also a main LabVIEW instance, for VIs that don't belong to a project. Web Method VIs appear to execute in a their own instance as well. Queues and other reference data types are not shared between application instances, which is why your web method can't communicate directly with your main application just by opening a queue with the same name as the one used by your test executive. Instead, you obtain a reference to that specific application instance, and run a VI inside of it, permitting it to share data. By default, Open Application Reference connects you to the main application instance. There are a few ways to get access to a specific application instance. One is the way I did it, by assigning it a unique TCP/IP port and then using Open Application Reference on that port. Another is the way Nathan did it, getting an array of all the available instances and then selecting the one you want. In Nathan's approach you already have the Application reference, so there's no need to open it - you can pass that application reference directly to Open VI Reference.

QUOTE (NeilA @ Oct 17 2008, 01:11 PM) Hi Neil - yup, that's how I have the URL mapping set. If you don't get it working on Monday morning I can post my demo project here when I get into the office (which will probably be near the end of the day for you in UK).

Nathan - thanks, that's very helpful. I see now that I did not completely understand application instances, and so in order to get access to the one I wanted I just assigned it its own VI server port. I didn't realize that each application instance has its own application reference, and that "Open VI reference" connects to the main instance by default. Neil - here's the code that my quick test uses. I, like Nathan, used a call by reference node, which I think is preferable to your Invoke node.

I set up a quick test project to make sure this works, and ran into some difficulties using VI server through ActiveX due to what seemed to be problems with application instances or my inability to determine the correct "full delimited name of the VI". The VI would run properly through VI Server but not in the same application instance as the test executive, so it would create its own new queue rather than using the existing one. Here's what I had to do. Set up VI server through TCP/IP. In the project explorer, right click my computer -> properties and select the VI server options (note that this is a project-specific setting). Enable TCP/IP on some non-standard port (the LabVIEW default is 3363, so try perhaps 13363). Then make sure your local machine is allowed to access the necessary VI. In your web method VI, open your application reference to that port on "localhost" (the local machine) so that it will use TCP/IP, not ActiveX. Finally, open the VI reference by name (the simple VI name is sufficient). This should get you a reference to the VI, in the correct application instance, so that it will get a reference to the correct queue. As you have probably already have figured out, you can add a string output terminal to your web method that contains the error status message; that way if the web method does generate an error you'll be able to see it easily. I found this to be very helpful in debugging a web method.