Jump to content

smithd

Members
  • Content Count

    739
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by smithd

  1. Are you referring to the "Reason-Phrase"(http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html) ( If so, I've tried everything I can think of and have been unable to come up with a way to set that field. LV seems to default to using the ones defined by http. If you just want to send data back you can always just use "set response.vi". I just used that setting the header to 401 and writing a response string ("OH NO! ERROR!" in my case) and the browser correctly displayed that string despite the error code. Are you saying this didn't work for you?
  2. I think most people would disagree with me, but I think of it like this... it feels to me as though a VI is only something where the UI is intended to be used (even if just as a dialog or debug screen). Anything else, which is intended to always be called by something else with a UI is a subVI, function, or subroutine. I think I personally would just call it "a function to do blah". I mean, technically I don't care if its written in LabVIEW, just that it does what I want it to do This becomes tricky with RT, where the top level VI should the the only function in your entire codebase which *doesn't* have anything on the front panel, but...its still the thing you go to in order to run the system, so thats still the "UI".
  3. Something posted above makes me less confident about my use, but I have a set of objects which store configuration information and a set of objects which present a UI for that configuration. However, I don't want the config objects to know about the UI objects *and* this all has to be in a plugin system. I want it so be {some subset of N}:{some subset of N}. That is, editor A may support configurations 1 and 2, but configuration 2 may also be used by editor B. So what I did was I made sure the editors know what classes they can support and use preserve runtime class to test every available configuration object (1, 2, 3) against the configuration objects supported by every editor (A, B, C). This seems to successfully let me know if (unknown config object) is supported by Editor A, B, or C. I don't know if there is a better way to determine class hierarchies in the runtime environment, but this is what I came up with.
  4. Glad to hear it. One other tip you might keep in mind is to ensure you have a timeout of 0 in your DMA loop, or otherwise fairly tightly match the timing of the loop with the timing of the DMA. Any time period in which the DMA node is waiting on data is a busy wait--that is, is is hogging the CPU looking for data. This will definitely hurt the performance of your system (even if you are able to keep up, it can't hurt to do a little bit better ). This limitation is resolved in the shiny new cRIO released a few weeks ago, and the solution is documented here: http://digital.ni.com/public.nsf/allkb/583DDFF1829F51C1862575AA007AC792
  5. It does sound like you should be able to get better than that, but its hard to say without breaking up the problem a bit. One option is that the code is doing something strange which limits your max log rate. I'd try running the code and have it log to the local disk and see what rates you can get. Then you can compare to these benchmarks, which are on the main disk: http://www.ni.com/example/31206/en/#toc7 (the sbRIO should be a little better than the 9074, but likely not as fast as the 9068). Assuming you get the expected rates when writing locally, you can start looking at the USB. There is absolutely no way you're going to hit 480 Mbit/s -- thats the *bus* limit, not the rate at which your CPU or the attached device can log to disk. But you can still look at the performance and try to improve it to meet your needs. One option is trying a different USB stick. Another thing worth checking is the formatting. I believe the sbRIOs should be able to handle FAT16 or FAT32, but you won't get anywhere near the speed of an NTFS system. (Source: Random person on the internet: http://www.msfn.org/board/topic/125116-fat16-vs-fat32-vs-ntfs-speed-on-usb-stick/)
  6. Hey sharkera, That toolset actually consists of a few things. The first package, tagwebclient, is a javascript+HTML web page along with some LabVIEW type definitions which are intended to allow you to create new web services which provide tag-oriented data to the web using a standard interface. At present it needs some work, but the basic concept is down. For example, there is a "tag browse" page which requests the available list of tags from a correctly-formatted web service. The second package, cvt web addon, is a LabVIEW web service which uses the CVT and aims to meet the contract required for the tagwebclient. Originally, these packages were combined but we are interested in making a web service which supports the new tag bus library (which is basically CVT on a wire): https://decibel.ni.com/content/docs/DOC-36995 Finally, the cvt web addon does have a sample websocket server. However, to the best of my knowledge it currently just supports sending strings back and forth. It is not used to transfer tag data -- standard labview web service functions are used for that. Thanks, Daniel
  7. Sorry about that. The link was to a poll on the CLA community, as Christian mentioned. The results indicated heavy support for opening the GDS toolkit which is now covered under the process identified here: https://decibel.ni.com/content/groups/community-source-of-ni-code This new discussion was intended to be more open-ended than the poll. It is posted here: https://decibel.ni.com/content/thread/23441
  8. Do you still have this (or have you posted it somewhere)? When I found found my most recent issue with property nodes (which is fixed) I went through code manually to do the same. Interesting changes. I wasn't sure whether writing the same value would be optimized out so thats why I made a new random value for each run. Is there an easy way to see what code gets eliminated? The reason I personally don't like property nodes is because of the error checking. I know a lot of people disagree with me but I prefer not having error nodes if you don't expect that code to throw an error. Accessors shouldn't throw errors (unless I know I want to do validation on it). Property nodes force me to add error wires which I never expect to use. However, property nodes do keep things clean in some cases and they really improve discoverability of data, so I see them as a necessary evil
  9. I was curious so I put something together (well most of it was stuff I've had lying around from previous benchmarks). I figured my first go at the benchmarks would be wrong, so there is a script to generate them. 1. Run gentests/gentests.vi 2. Open Benchmarker.vi and set the path to a generated report file 3. Run benchmarker.vi My first attempt is attached. If you want to change the benchmarks, they are the templates in the folder. From this first run, I don't see a difference, but as I said my first attempts are usually wrong when it comes to benchmarking. propbenchmark.zip first run.zip
  10. Something stupid I've done in the past when I'm in a hurry and can't figure out what that VI wants from me is to create something known (like a numeric) and then on the newly generated control, immediately call replace. Replace has a path input. I'm not a big fan, but it usually works.
  11. If anything, issues with property nodes have gotten better over the last few years -- at least in my usage. All of the really bad bugs I've seen have been fixed as of this most recent patch (see this recent thread for an example: http://lavag.org/topic/18308-lvoop-compiler-bug-with-property-nodes/). But, there are still a lot of usability annoyances related to case sensitivity. For example, if I name my folder Properties in the parent class and "properties" in the child class, you'll see two property items which link to the same dynamic dispatch VI. When a recent code review found a misspelling in the property name of a parent class, I had to go through every child implementation (~15 at this point) and fix the spelling there, because the classes were broken somehow. This and more is tracked by CAR 462513. Finally, I remember seeing Stephen post somewhere that property nodes, due to their inherent case structure, prevent LabVIEW from optimizing the code -- even if the VI is set to inlined. For this reason alone I avoid them in any code I expect to be running at high-priority. For UI, however, I use them extensively.
  12. I'm in the systems engineering group at NI. Over the course of the past year(s), we've received feedback (most recently here -- sorry, this link is in the ni.com/community CLA group so access may be restricted) that some members of the community would be interested in contributing to some of the projects we've already released, or potentially working with us to identify future projects that might benefit the community at large. We'd like to renew this conversation by opening up a discussion of what projects might interest the community. That discussion is posted here: https://decibel.ni.com/content/thread/23441 If you have any thoughts or feedback, feel free to post here or in that discussion. We're very interested in hearing from you.
  13. If you're going to go for the DVR solution, you might take a look at the Extensible Session Framework. It could provide a good jumping-off point for your work. I've used it before and it worked well for me.
  14. I remember this being an issue in 2011, but hadn't encountered it for a while. I recently ran into it again where the property node won't notice the transition from 1d->2d array. This may be fixed in sp1 patch f3 (look at issue 467722): http://digital.ni.com/public.nsf/allkb/4415B312CC61449A86257C820053B65E If updating to this patch doesn't fix it, I would highly recommend letting the applications engineers know, and file a bug report.
×
×
  • Create New...

Important Information

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