Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by WMassey

  1. CAR# 378165 LabVIEW Version 11.0.1f2 In a VI for a FPGA target, if an error cluster is wired to one input of an OR gate that has a Boolean wired to the other input, then in the "generate intermediate files" process that precedes the Xilinx bitfile generation, "stage 1 of 7" (analyzing VI hierarchy) will very repeatably crash while processing the VI. See attached PDF.
  2. It turned out that the problem was a slightly misformed URL. GET does indeed return the requested file in the "body" string if no path is attached to GET and it drops it into the file if a valid path is provided. Thank you again Shaun!
  3. I had tried feeding the URL (URI?) for the target CSV file to GET.VI and all I got in response was a "you are being redirected" in the "body" return string (or else the designated file if I passed a file name to GET). If GET truely is the correct way to do this then I guess I need to revisit my methods of producing the request... Thanks.
  4. In this topic I was helped to understand how to use the HTTP Client VIs to connect to a HTTPS server. I have manged to use those Client VIs to gather sufficient (dynamic) information from the server to form the dynamic download links for a series of CSV data files that the server can provide. The HTTP Client VIs seem to me to be able to only return web page header and body information. I have not found a way to use them to grab a file specified by a URL. Is there a way to do this with them? The HTTP Client VIs make use of "Client Handle" RefNums to identify the open connection. Are there other VIs available in the VI library that can also use these same Client Handles and which can transfer a file? Thanks!
  5. Thanks for the suggestion and link. If I cannot get LabVIEW bent to my will then I'll consider it. Thank you! That did seem to help! I had tried using it (ConfigSSL.vi) at one time with this test code but had no luck and got scared away from it by all the inputs to the VI that I did not know how to use. After your suggestion I tried it again. My first try again yielded the error #42 but then I saw that the VI had a default-True boolean input telling it to check/use all those other inputs. I set the "verify server" input to false and the error went away and, based on the redirection and cookie I'm seeing, it appears like the login worked! Thank you!
  6. I recently looked this up and saw at the time that it was built-in functionality. This link says "All CompactRIO, FieldPoint and Compact FieldPoint controllers have built-in network monitors. If you enable the network watchdog and the controller loses communication with all hosts or clients over the network, controller sets the output channels to predefined values corresponding to the watchdog state." There are also these if you you want to do it yourself: Uni-Directional Network Watchdog Reference Example Fail-Safe Control Reference Design for CompactRIO
  7. I am trying to use the HTTP Client VIs to implement a version of the C# code found HERE. Unfortunately there are no NI examples of how the client VIs are to be used and my various attempts to string them together only seem to result in "Error 42" (LabVIEW: Generic Error) from the POST vi, rather than returning the headers and body text. I have also tried using DOTNET calls and was at least able to get the login page returned but could not seem to trigger the login. I switched to the HTTP Client VIs because they offered an alternate hope and I could at least see where to attach a cookie file with them (though a cookie file may not be the same as reserving space for a session cookie). Any guidance would be appreciated!
  8. QUOTE(CTITech @ Feb 21 2008, 11:15 AM) I suspect you do need to put a bit more effort into learning this on your own before saying you need help. The library ships with examples and Example #1 shows a situation where the "Write Strings" vi is used to write strings to a spreadsheet. The strings to be written by way of this vi do have to be in an array to make the connection to the vi, but you do know that arrays can have only one element don't you? You just might be forced to pass your string through the build-array function before connecting up to the vi.
  9. QUOTE(CTITech @ Feb 20 2008, 10:22 AM) It's right there in post #4 of the other discussion thread to which I referred you. It was "http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3EF0056A4E034080020E74861&p_node=print' target="_blank">Excel Toolkit (GOOP)" just like here and the link works.
  10. QUOTE(CTITech @ Feb 20 2008, 04:38 AM) Well you can download and use the library (it's free) . But if your rules at work don't allow for that sort of thing, you can build the functionality from the ground up. That's what Martin Vernhout of Philips Research did when he put the library together in the first place. But you'll need a good understanding of the internals of Excel and how to access them through Method & Property nodes with ActiveX. This is an example of his subVI to write an array of text values to a specified set of locations on a selected worksheet: http://lavag.org/old_files/monthly_02_2008/post-2800-1203521435.png' target="_blank"> In it you can see the Worksheet method and the Range property node used to transfer the string arrays to the Excel process. I've attached the help files associated with the library for your consideration. So far, the only thing about the library I've found so far that I don't care for is that the lowest-level "excel objectRepository" vi has a locked block diagram, but that doesn't keep it from being perfectly usable and a great help to have. Besides using the library to read and write native .XLS files, I've used it as a learning tool and have expanded on it to the point where I can even create graphs on the Excel worksheets with it. I, for one, am grateful Martin chose to share this with the rest of us. Try it, you'll like it!
  11. All you want to do works easily enough if you have the Excel toolkit mentioned in this discussion: check here
  12. I had also asked Neville directly if he still had this tool and he replied that it was "lost in the mists of time." After some digging I found that the property is available through this path (LV v7.1.1 with scripting enabled): I'll try, when time allows, to get it built into a tool.
  13. QUOTE(tcplomp @ Oct 28 2007, 10:29 AM) Thanks but VI analyzer is not an option at the moment.
  14. Did anyone ever build a "find coercion dots" tool? I found an old email that hinted that Neville Dholoo & David Edwards were working on one but I never did find anything beyond that.
  15. Can you access the port using the latest version of MAX (measurement & automation explorer) on the systems with the problem? It's got to work with MAX first.
  16. Version 1.71??? The latest VISA driver is v3.5. Get it here (for Windows, otherwise see the link I posted above). When you get done installing VISA, you should also have something called "Measurement & Automation Explorer" (a.k.a. MAX)installed too. You can use that to do primitive serial communications tests. If you can communicate using MAX then you can communicate using LabVIEW if you program it correctly.
  17. Usually when you see an error number with no explanation like this it is an indication that the software for that device (which would include the error explanations) is not installed. Try getting a VISA driver from here, install it and run your code again.
  18. Parts of this discussion remind me of this show that TechNow! recently broadcast about a study of world events affecting random number generators.
  19. Pin #4, let's see, according to the 9-pin RS-232 spec, pin #4 is the DTR (Data Terminal Ready) pin (see the Serial Quick Reference guide found here). This is something I didn't know you could do until I just now went here and did a search on these three words: control DTR pin which turned up this posting (along with several others). The search pages, both here and at NI should be everyone's first stop when trying to find out something you don't know. Anyway, this appears to be how it would be done.
  20. Well I think that's your problem. You've got to stop installing those Microsoft viruses. Heck, if I were you I'd make a point of uninstalling any that you have installed. Everyone knows that Microsoft has a particularly poor record when it comes to producing viruses (though I hear that they have been known to produce code that supports others efforts in this area). :laugh: Seriously though, I too have seen the broken run arrow and nothing in the error list and this is with v7.1.1 so it's not necessarily something new with v8. I find that I can usually "fix" it by closing and then reopening all the VIs. That'll usually make the errors appear but, if I remember correctly, in at least a couple of cases it made the errors and the broken arrow disappear. I have no idea what causes it.
  21. Actually you might have to (hold your breath that is).One wrong move and you might end up deleting a whole day's work.
  22. Cool interface, but a real invitation to fingerprints on the display screen! :laugh:
  23. I'm glad that it is working for you now. And thanks for letting me know that I was able to help. :thumbup:
  24. First of all I don't think this is the correct forum for you to be using to ask this question. It should either be in the LabVIEW General forum or the Hardware forum (which includes serial communications). It also would have helped if you had either posted an picture of your block diagram or the actual VI since without either of those we can only speculate. It sounds like you have a loop that is doing the reading and it does indeed read and display a message fragment but then subsequent iterations of the loop either overwrite the displayed preceding fragment with the next fragment or possibly a blank text string if no message is available. If you are not using a termination character to to determine when a complete message is available at the serial port, then you should be. Once you get that working, it is easy to display only complete messages in your display window and they won't be overwritten until the next complete message arrives. This post has a simple example of this attached. This post has a more complex example (using multiple VIs) attached.
  25. What you are asking for involves a bit of complication because you are demanding that your system assume various states depending on whether or not some event occurred and then it needs to remain in that state until some other (timer) event occurs. That "complicated" (your word, not mine) state machine I posted 30 or 40 messages back could be easily modified to handle stuff like this, but it's also possible to add some logic to your existing VI to do it too. Take a look at the attached VI. It'll give you an idea how you can handle timed events. Instead of blinking lights, think "OC" command. I wouldn't be surprised if others suggested better ways to do this. Download File:post-2800-1143163097.vi
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.