Jump to content

ShaunR

Members
  • Posts

    4,856
  • Joined

  • Days Won

    293

Everything posted by ShaunR

  1. Like Tim_S. I assume this is an NSV issue since I've never seen 8 second delays with TCPIP. I havn't timed it, but it usually breaks the connection as soon as the LED goes off on the port although WiFI can be problematic for this sort of thing. You could open another connection with straight TCPIP just to monitor to see if it disapears since a lost wire will affect all connections on that wire/card. If you go that route, then it's sometimes a good idea to have it in a separate exe running in the background so that it also crowbars your main application (taskkill /f kinda thing).
  2. No. You cannot cast clusters containing variable length items (like strings and arrays) but the clusters can be contained within an array and can be compund types. If you could set the length of the arrays to be a specific value, then you would be able to use arrays etc within the cluster (as you can with FPGA), but this feature isn't available in normal LabVIEW. The cluster is synonymous with the C "structure" (struct) which also cannot define variable length arrays within its definition.
  3. Not quite what you are probably thinking. I added serial to the transport.lvlib. So I didn't exactly produce a polymorphic VI directly from the serial frames of the AE, but to all intents and purposes it is the same.
  4. Well. My "negative" comments are'nt so much about your code. More about the serial implementation of VISA. The fact that once you are in a "read" you are stuck until it times out (not even the vi stop button will have an effect) means that you are forced into checking bytes at port and re-implementing the timeout. This makes any serial vis far more complicated than they need to be (and incongruous with all other VISA interfaces). My "positive" comment would be "if it's not broke, don't fix it" and you have proven it works since you state that you have "used for some time". Therefore it's only a style thing if anyone is going to comment. Anyhoo. Up until recently (well a year or two ago). I too used the action engine approach also. I eventually split out the sub-frames into separate VIs and pulled them together in a plymorphic VI. This has a couple of minor advantages over the AE in that you can have different terminals for each action, different icons (if you so desire) and a nice little drop-down under the VI instead of a typdef (slight readability improvement IMHO). You could just wrap the current vi in some more VIs to achieve this rather than pulling out the frames as I did, but it was just a personal preference and brought the serial in-line with tcpip and others that I chose to go that route with. Wrapping in a polymorphic VI at this level does have one disadvantage though. Since you cannot nest polymorphs, it means you cant wrap higher level protocol vis that use these into a polymorphic VI. It forces you to make protocol dependant serial transactions (e.g reads based on a byte length) an item in the drop-down at the same level (flattens the hierarchy and couples dependancy).
  5. Unlikely to be Cat. Ballistic weapons don't work too well in submarines Must be using LabVIEW 2010
  6. OK. Which one of you has a brown sweater? : http://www.dailymail.co.uk/sciencetech/article-2108129/Railgun-Video-shows-hit-targets-100-miles-away-7-times-speed-sound.html
  7. Event structures have been screaming to be re-vamped for years. Shame the focus so far (and for the foreseable future) is on less useful wizards and eye candy.
  8. ShaunR

    DAQ Device safety

    Zener diodes.(clipping)
  9. Not if he gives them away free too
  10. Indeed. Your mileage will depend on what you want. The advantage of the license/waiver is that it's not a per-seat license (effectively a site-wide license) so you can have lots of developers and install it on as many machines as you like (for developing that product) as well as no new fees for updates (of the toolkit) or periodic payments. 100 developersx1 product = about $1200 for the lifetime of the SQLite API (free upgrades). And lets not forget that if you are using it internally (e.g for your production line) it's completely free. I prefer to think of it that businesses that are interested in using it for monetising are supporting the development so that everone can benefit (after all, if you are selling product, the commercial cost is passed on, is it not?). The other way you have to pay per developer and everytime a new release (of the toolkit) comes out. 100 developersx1 product= about $69,900 every time you want to upgrade. It always strikes me as funny (as in ha, ha) that Labview people are prepared to pay tens of thousands of dollars every year to NI (basically just to get bug fixes) but balk at trivial costs for anything non-NI. I'm not making huge amounts off of it. But if others are, shouldn't a little bit of that come my way? At the end of the day, though. It depends on how much you value your time. For the amount of time I have spent on the API, I would have quoted considerably more if a customer wanted it. (the gochtya are the dlls )
  11. Wow. I'm a crowd? I really can be in two places at once (multiple salaries ) For raw speed. It's the only way. Labview is fast (in comparison to, say Java), but not the fastest. A dll call will probably only add about 1-3 usecs of overhead.
  12. Well. The database logger is shipped, as an example, with the SQLite API now (so it is covered by the sqlite api license). But it's not a lot of good without the API. I suppose you could hack the api stuff out and use something else, but I think it would be a lot more complicated. "Fair Use" is a bit moot since the SQLite API is distributed under a non-commercial share-alike license, so for evaluations, articles etc (where fair use is targeted) it is perfectly acceptable to use it under the current license.
  13. So. Where can I download the IDE? (I like it!) The example of an electrical circuit was the original premis of labview. We have had this sort of functionality since day dot (custom probes with a waveform graph). I think custom probes are generally underused and i'd love to see a custom probe pack with waveforms, plots etc.
  14. Naaah. He just means they've added more wizards So. Anyone offering the car wash and traffic lights?
  15. Nope. Apart from the odd list encapsulation. I steer well clear of it unless dragged kicking and screaming. However. LVPOOP is now a part of LabVIEW and the CLD exams are specified tasks with example answers. So for people learning LabVIEW (and have been infected with the OOP virus), they are an ideal way to learn the pro's and cons of adopting the paradigm. More importantaly though, they can show that elusive aspect of how to go about solving a specific task using LVPOOP rather than trying to review more complicated private projects (that have no exampled equivalence to classical LabVIEW) and then trying to figure out how to apply it to thier situation.
  16. The CR/LF constant in labview is platform dependent. It also depends on which browser you are viewing in (some are happy with only one EOL char, others require both). You should use a constant string with "\r\n" which will work on all platforms and browsers.
  17. Hmm. The CR seems a bit "formal" to me but has the "pro" that each submitter is responsible for their submission so no centralised maintenance. Not keen on the document idea which would basically be just a list of links that someone has to maintain. I was thinking of just an extra category in the forums (like the Object-Oriented Programming, User Interface, Remote Control, Monitoring and the Internet, etc) that would just pull together the current posts and people could add theirs as and when they were created. People could also use that area for requests for code reviews of examples they want people to comment on.
  18. Sweet. I wonder if we could get an "area" on Lava for these so they are all in one place and easy to find
  19. Great. Traffic lights, car wash anyone?
×
×
  • Create New...

Important Information

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