Jump to content


Popular Content

Showing content with the highest reputation since 06/29/2009 in Posts

  1. 20 points
    After I made this post I decided to bring the LabVIEW Wiki back online. It was not easy and took several days of server upgrades and hacking. The good news is I was able to bring up all the original pages.. The even better news is I talked with @The Q and @hooovahh and we are all on the same page as to how to move forward. @The Q did a great job of stepping forward and trying to fill the void that the LabVIEW Wiki's absence had left. He's agreed to migrate all the new content he created over to the LabVIEW Wiki, from Fandom and continue to develop new articles and content moving forward on the new site. He will also help in moderating the Wiki and will be promoted to Admin rights on the Wiki. His help is much appreciated. The LabVIEW landing page created here on LAVA is awesome but the forums don't lend themselves to static content creation. Instead @hooovahh has agreed to move the old landing page to here. That will be the new home for the landing page. This will become a valuable resource for the community and I hope all of you start pointing new people in that direction. With many editors, it can only get better and better over time. Where do we go from here: Logging in. - The old accounts are still there. If you're a LAVA old-timer, then you can try to login using your LAVA username. If the password doesn't work then reset it. You can also create a new account here. I'm going to announce a day when new accounts can be created. I'm limiting it for now because of all the spam accounts that can be potentially created. There's an issue with the current Captcha system. if you are super-eager to start creating content now and want to help, send me a direct message on LAVA and I can manually create an account right away. - New account creation is now open. Permitted content: - I'm not going to put restrictions on content at the moment. Obvious vandalism or offensive\illegal content will not be tolerated of course. However, the guidelines will be adjusted as time goes on and new content is created. There's just not enough content right now to be overly concerned about this. We need content. Discussions about the Wiki. - Each article page has an associated discussions page where you can discuss issues related to that article. Please use that mechanism (same etiquette as wikipedia). General Wiki issues\questions and high level discussions can be done here. So now, if you need to add content, you can do it yourself. Feedback as always is welcome.
  2. 11 points
    The NIWeek 2013 Videos are compressed and ready for down load from Tecnova's ftp server All of the videos are files and are around 400 to 450 MB for an hour presentation. I would strongly recomend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple viedos the ftp client makes things much easier. My ftp client of choise is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found here Thanks to my IT department at Tecnova for giving me the space. V I Engineering has also volunteered the ftp server to help distribute the videos. Thank you Chris for your help. Use this log in information ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Use this log in information ftp://tahoe.viengineering.net/LabVIEW_Videos login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. I compressed and uploaded these videos in a rush and didn't have time to look through them all so if you find issues please post to this thread. Please enjoy and share the videos with anyone you can. Mark
  3. 9 points
    Tecnova has created a new LabVIEW Video site to replace the previous ftp server for downloading NIWeek and CLA Summit videos. Location: https://labviewvideo.tecnova.com Login: LabVIEW_Videos (Not case sensitive) Pw: LabVIEW (case sensitive) Check out the LabVIEW Videos Tecnova site Demo to see all the features of the new site. For comment or feedback please email LabVIEWVideo@tecnova.com Thanks to Tecnova Management for supporting the LabVIEW Community. Note: Testing has shown successful downloads using Chrome, IE and Edge for Windows and Safari for Macs. FireFox however tries to auto play the video and may not work like the other browsers. LabVIEW Video Demo.mp4
  4. 8 points
    I don't think it takes too long after deciding to do an actor based project to run into the case where you have an actor spun off without a way to kill it. You'll figure that out and get your solution working so you can pass it off to someone else and forget about it. Soon after, that someone else will come to you and say something like "yeah, those actors are cool and all, but they're really hard to debug" I ran into some of these problems a while ago, so I decided to write a little tool to help with it. I decided to call it a monitored actor. Here were my design criteria: I want a visual representation of when a monitored actor is spun up, and when it is shut down. From the visual representation, I want to be able to: stop actor, open their actor cores, and see if they're answering messages The visual representation should give you an idea of nested actor relationships. Implementing a monitored actor should be identical to implementing a regular actor. (meaning no must overrides or special knowledge) Monitored actors behave identically to Actors in the runtime environment. It turns out that you can pretty much accomplish this by creating a child actor class, which I've called Monitored Actor. A monitored actor's Pre-launch Init will try to make sure that the actor monitor window is made aware of the spawned actor, and Stop core will notify it that the actor is now dead. The actor monitor window contains ways to message the actors and pop up their cores and such. I think it's fairly obvious what each button does except pinging. Pinging will send a message to the actor and time how long it takes to get a response. This can be used to see if your actor is locked up. The time it takes to respond will be shown in the ping status column. if you want to periodically ping all the actors, set the "poll Frequency" to something greater than 10ms. This will spawn a process that just sends ping messages every X ms. Where I didn't quite meet my criteria: If you were to spawn a new actor and Immediately (in pre-launch init) spam it with High priority messages, the Actor monitor window will not know about the spawned actor until it's worked through all the High priority messages that got their first. You probably shouldn't be doing this anyways, so don't. Download it. Drop the LVLIB into your project. Change your actor's inheritance hierarchy to inherit from monitored actor instead of actor. You shouldn't have to change any of your actor's code. The monitored window will pop up when an actor is launched, and kill it's self when all actors are dead. Final note: This was something I put together for my teams use. It's been working well and fairly bug free for the past few months. It wasn't something I planned on widely distributing. A co-worker went to NI week though and he said that in every presentation where actors were mentioned, someone brought up something about they being hard to debug or hard to get into the actual running actor core instance. So I decided to post this tool here to get some feedback. Maybe find some bugs, and get a nice tool to help spread the actor gospel. Let me know what you think. Monitored Actor.zip
  5. 7 points
    I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.
  6. 7 points
    View File Plasmionique Modbus Master This package contains the Plasmionique Modbus Master library for LabVIEW. It supports RTU, ASCII and TCP modes with the following function codes: 0x01 - Read Coils 0x02 - Read Discrete Inputs 0x03 - Read Holding Registers 0x04 - Read Input Registers 0x05 - Write Single Coil 0x06 - Write Single Register 0x07 - Read Exception Status 0x0F - Write Multiple Coils 0x10 - Write Multiple Registers 0x16 - Mask Write Register 0x17 - Read/Write Multiple Registers 0x2B/0x0E - Read Device Identification Other features include: - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout). - Sharing a Modbus session across multiple communication loops. - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order. - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. - Detailed help document available through the "Help->Plasmionique" menu. Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\": MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230 The most recent version of this library will always be released on LAVA first before going through NI's certification process. ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master Submitter Porter Submitted 04/01/2016 Category LabVIEW Tools Network Certified LabVIEW Version 2012 License Type BSD (Most common)  
  7. 7 points
    At the (fantastically awesome) LAVA/OpenG BBQ, someone (apologies to whoever it was, I forget who - sometimes I think I'm the Dory character from Finding Nemo) asked about getting more recent projects in the GSW. Stephen Mercer / Aristos Queue had provided modified versions of the VIs to do this in 8.6. I added a config token for this in LV2009, so you no longer need the modified VIs. It's MaxGSWRecentProjects=10 (or whatever other number you want. We never display more than 10 recent files, though). - Christina, aka "Miss Eyes on VIs," LabVIEW R&D
  8. 6 points
    I just started down the rabbit hole of making a new XControl recently. Oh man such a pain. Here is a little graph I made complaining about the XControl creation process, and the time needed to make something useful. Any alternative is appreciated.
  9. 6 points
    Door Prize! Two of these custom bluetooth speakers will be given away, sponsored by the LAVA BBQ itself! [Front and back views]
  10. 6 points
    As rule I tend to avoid express VIs, but I happened to click on a link in Christian's signature and found this. I haven't looked at it in detail, but this may be the one express vi I'm willing to use.
  11. 6 points
    Hello, I use shortcut menus a lot, particularly for setting display options on graphs and charts. I have a pair of VIs that I use for this that leverages the variant data tools of OpenG, and I wondered if they, or something like them, would be a useful addition to OpenG. I’m not sure if they are quite right, but even if they are too specialized for my way of using menus, perhaps there are other more general VIs that exist for helping configure menus. So here they are for comment: The basic use case is shown in the top image; I have a shift register of program state parameters, including a number of options. When the User right-clicks on a control/indicator (a numeric in this example, but more usually it is a graph or listbox) the options are inserted into the shortcut menu via the VI “Add Items to Menu”. This VI can handle booleans, enums, and clusters thereof. The second image is the front panel and the pulldown menu that results. The third image shows the Shortcut Menu Selection case, where a second VI, “Change Variant by Menu Tag” (needs a better name) interprets the selected tag and updates the cluster of options accordingly. It also has a “Changed?” output that can be used to trigger redisplay with the new options. As I said, I’m not sure if these are general enough for OpenG, but perhaps someone else has a set of reuse menu VIs that might be more suitable. Menus are a UI feature that is very valuable, IMO, and they could do with some OpenG support. — James Shortcut Menu Utilities.zip
  12. 6 points
    Here is my proposition. Inspired by recent LAVA activity... However I haven't read that all And alternative version for the front, which is even more pure:
  13. 5 points
    Hello all. So NI is trying something new this year for NI Week. Year after year NI gets feedback from those that attend NI Week and one of the most common things people ask for is more technical sessions. We don't care too much for a marketing presentation telling us how your company is awesome, and we don't really need NI to tell us about some new hardware we'll never use. But coming back from NI Week with new technologies that excite me and make my job get done better, makes my boss want to send me next year. So as a way for NI Week to get more technical, NI has dedicated a room at NI Week to advanced users to give presentations on advanced topics, allowing them to make up their own Advanced Users. This track will be in addition to the other tracks NI usually has for various industries, like aerospace, and automotive. These presentations will be given by advanced developers who are LabVIEW Champions and will focus less on marketing and more on being technical, sorta similar to what you'll see at a CLD/CLA Summit. So checkout Room 15 Tuesday and Wednesday for the advanced awesomeness, you should expect lots of hearty frank group discussions. It seems not all of the topics are posted by NI yet, but here are just some of them. And yes for a bit of self promotion I am giving an updated presentation on XNodes that I gave earlier this year.
  14. 5 points
    I've occasionally seen or heard from people wondering about hosting labview web services in other servers, like apache, microsoft IIS, or nginx. They may already have a server they just want to plug into, or maybe they want to use some of the more advanced features available in other servers -- for example LDAP/activedirectory authentication (http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html). However dynamic content still needs to be provided somehow, from LabVIEW. I've never really done too much with web services and I was curious how this stuff works in other languages. I'm fairly certain I'm 'rediscovering' some of this, but I couldn't find what I was looking for anywhere in labview-land....so I thought I'd share what I found out and what I did about it in case anyone else was curious about the same. What seems to be the case is that when people using other languages want to add code to the back end of a web server, they have a few basic options: Compile code into the web server. This option is more difficult to reuse, as you're making a plugin for a particular server, but some servers can use plugins for other servers. Apache has modules, for example mod_perl which is basically a dll which runs perl. IIS can run all sorts of .net code and scripts I *think* this is what LabVIEW has done for its web service, but can't confirm. Use a protocol between the front-end web server and the back-end application. The simplest version is CGI -- the web server runs an exe, passes any post data as standard in, and waits for data on standard out or standard error. This is slooooow as it runs an exe every time. This was improved with FastCGI where the web server launches N copies of the exe on boot and then leaves them running. These EXEs are sent packets which correspond to the CGI standard in data and respond with standard out and/or standard error packets. These packets can be sent through standard I/O (which is tough with lv) or through TCP (which is easy). Some people use a simpler HTTP server running in their program as the back-end. It can be simpler and less robust than, say, apache because in theory you're only getting well-formed packets from the front-end http server. Compared to FastCGI this can be even faster because the HTTP request doesn't have to be re-packaged into an FCGI request, but HTTP is single-threaded (for lack of a better term -- requests must be responded to in the order they were received). The other advantage is you can use a web browser or other http client to talk directly to the simple http server, which you can't do with FCGI (for debugging purposes). This is essentially a https://en.wikipedia.org/wiki/Reverse_proxy There are some custom protocols used like WSGI which seems to be python-only, or things like java applets. The point is, its pretty common to let something big and complicated like apache take care of the incoming requests on port 80 while letting one or more back-end servers handle specific requests as needed. This could handled by the standard labview web services (ie Apache reverse-proxies to the standard labview web service) but I was still interested in how this stuff works so I made some (rough) code, which I've posted here, a few weeks back: https://github.com/smithed/LVWebTools tl;dr: Built, monolithic web-service-code like what labview does seems to be pretty uncommon. Most (citation needed) languages seem to just use a protocol between the main, very separate web server responsible for authentication, security, and static file serving and the tiny backend exe responsible for everything else. I made some neat tools to do this, in LabVIEW. Also, the internet really is just a series of tubes. ----------------------------------------------------------------------------------------------------------- Note: the following is really into some of the weeds, if you don't want to try the code stop here. I started with FastCGI because it seemed simpler...but it turned out not to be. You're still responsible for adding most of the headers and response codes and such into your response, so it seemed like it had less structure but that structure was actually necessary anyway most of the time. If you want to take a look at it, FCGI/FCGI server.vi is the main VI and FCGI/default responder action.vi is the main VI I was using to test out different responses. With apache, you'd set it up using mod_proxy and mod_proxy_fcgi, but I'd actually recommend a new web server called Caddy (http://caddyserver.com/) because it is more developer friendly. The "caddyfile" you'd need would be as follows: " fastcgi /lvroot" (adjusting the ports and such as needed of course). If you run the caddy server with that file, and then navigate to http://localhost/lvroot/anything it will invoke the labview code. With fastcgi, you manually add any headers you need to the top of the response, so as an example you'd have to write: "Content-Type: text/html <http><body>blah</body></http>" After that I decided to try out http, which I quickly learned was a really gross protocol. The core of it is nice and simple, but the issue to me is that the transport-related headers are mixed in with content-related headers, and oh by the way you can shove extra headers in the content section if you want to, oh and hey if you want to change protocols in the middle of operation thats supported too. Its weird. But I got a verrrrry basic server loop up and running and its located in http/http server.vi. This one I actually used for something (the Freeboard thing I mentioned in this thread: https://lavag.org/topic/19254-interactive-webpage-vi-options/) so I made a basic class to inject some behavior. That class is located in http/http responder and provides the "get.vi", "post.vi", "put.vi", and "delete.vi" you'd expect. Since I was 90% of the way there anyway, I added a protocol upgrade function in order to pass functionality off to (for example) a websocket handler. This was totally not worth it (the code got more complex), but its cool that it works. As above, I'd recommend caddy server and the appropriate line you'd want to add to your file is "proxy /lvhttp localhost:9001" Because HTTP allows sending partial results, my implementation uses a queue to send data back...I think most of the fields are pretty obvious, except to note that the headers field is a variant attribute look up table with a string/string implementation (header/value). If a response code isn't specified, 200 is assumed. Side note: Because I have a giant NI next to my name I feel the need to note that this is just a fun project, not intended in any way to replace the fully-supported in-product server which includes all the fancy things like authentication, URL routing, etc. My thought was that this could be handy for making really stupidly simple services that plug into big ones *already running* in apache, nginx, or IIS.
  15. 5 points
    Two ways to do what the OP is asking. 1. VI Server world: Children have a static link to their parents and Parents have a dynamic link to their children. This means that once a class is loaded into memory, the parent knows about the child. According to the documentation this will NOT work in the runtime environment, but i've used this several times when making IDE Tools. 2. Runtime Reflection: The following code will also give you an array of all of the children loaded in memory, but this time it uses less VI Server so it will work in the runtime environment. I use this when using a plugin architecture. I've not done a lot of performance testing with it, but on a medium-ish size project (one with ~150 classes) it only takes about 50 ms to run, so it's worked well for me so far. Having given you those solutions, I still think your best bet is to use a statically defined array. This will ensure things are loaded into memory when their needed and such. My solutions really only become worth it once you're dynamically loading classes.
  16. 5 points
    The big benefit for developers that I see here is that it may highlight some of the source control issues that we have suffered for many years. It may prompt changes in the core so that we can use these powerful tools (like github) much more effectively. I dare say that once you have 20 branches all pushing their changes, the nightmare of merging, cross-linking and phantom recompiles might be laid to rest once and for all That alone should be enough of an incentive to participate, if only because pushing changes will cause such havoc for the people merging the Master that they have to do something before they tear [the rest of] their hair out
  17. 5 points
    An unofficial response: avoid this primitive. It was requested by a group within NI and it turned out they didn't need it halfway through its development. In a lot of cases it can create a compile error. In some cases it will cause a crash on save. The author says that it was never thoroughly tested (so don't expect IEEE 754 conformance!) and that bug reports for it are rejected since it was never officially released (not even for internal use). This is a prime example of digging around in LabVIEW and finding fool's gold instead of actual gold.
  18. 5 points
    In what has to be the most off-topic LAVA/OpenG BBQ door prize ever, I'll be giving away two advance copies of my graphical novel Rune: A Tale of Wizards and Kings, which is coming out in October.
  19. 5 points
    I just realized I'm about to hit 500 posts on LAVA. I would have probably preferred if #500 was a deep treatise on some esoteric feature of LabVIEW that will change the programming world as we know it. But we all know that ain't happening anytime soon. Maybe post #1000... So instead, I would just like to express my heartfelt thanks to all of you here at LAVA. To those of you who have helped me out over the years (and will hopefully not tire of helping me out in the future). To those of you whose irreverent words have made me laugh out loud at some inappropriate times. To those of you who ask questions and make me think outside of my own little programming box. And of course, to the (real) Moderators who keep the Wonderful World of LAVA going. I love all you guyze!! Cat
  20. 5 points
    Any control represents as many as 5 copies of the data. Default value -- the value of the control by default. Operate value -- the currently displayed value of the control. Execute value -- the value actually in the FPTerminal. This may update several times before the data is passed to the control itself unless Synchronous Display is enabled. Transfer value -- the value last moved from the FPTerminal to the Operate data. The transfer data copy is made by the executing thread so that the execution isn't locked by a transfer to the UI thread. Can't copy directly to Operate data since the UI might be in the middle of a redraw when the transfer occurs. Extra value -- created only when VI Server Value property or a local variable gets involved trying to copy the data back out of the control. The comments here are talking about the extra data.
  21. 4 points
    Hey fellow LAVA people. I just turned 50 on April 2nd, and wanted to do something challenging for me, both mentally a physically. I'm running 10K every day for a year and raising money for cancer research. If you want to follow along on my journey, you can subscribe to the 10K365 youtube channel for the latest. Then go on over to 10K365.com and give whatever you can. Thanks, I consider all of you as friends and one of the reasons I love LabVIEW.
  22. 4 points
    DISTek will be giving away an Arduino based Sparkfun Kit. https://www.sparkfun.com/products/14556
  23. 4 points
    @JackDunaway Great analysis with which I agree with 99.9% (except for your first sentence). You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations. I think you have seen and hinted at, but not articulated, though. 1. it is impossible to create LVPOOP components with zero static linking (this is trivial with an open VI and a LLB full of functions which can be loaded and unloaded dynamically). 2. A function per VI is a purely semantic imposition for dynamic dispatch. 3. With the exception of namespacing with paths, classical labview programmers only have similar issues by bad architectural design rather than language imposition and can always avoid the issues by best practices and frameworks. Food for thought: If huge amounts of analysis and tribal knowledge is required to not write bloated, unscalable and buggy code with a certain tool. Is it not a better strategy to just not use that tool?
  24. 4 points
    The Vision Common Resources install is FREE and allows you to use the IMAQ image control in your application. You don't get any image processing but it is fine for loading images and displaying them with all the ROI tools. I believe the only bit you need a license for is IMAQdx...
  25. 4 points
    I disagree with Darin a little...I think there are valid times when you should comment on what the code is doing. Sometimes what may be self documenting to you is not as self documenting to others. I run into this commonly with bit manipulations and bitwise functions, and lately even more so with FPGA. Often times if someone just left a comment "this checks if bit 4 changed" I would understand quickly vs. trying to read the ands and ors and scale by power of 2's that my mind doesn't yet process as easily. Maybe this is my own shortcoming, but I still think it's worth noting. The problem is at what point do you determine whether something is self documenting in general and the majority of programmers would agree that it is, or whether it's self documenting just for yourself (code reviews, anyone?). I find myself looking at my own code and thinking "that makes sense" but forgetting that it took me 3 hours to get it to work. Anyways, this is just one example and I think touches on the same thing Cat is saying above. One thing I am always sure to document is the random "increment" or "decrement" function. C'mon, we've all seen this, the code works, yet we wonder wth is that there for!
  26. 4 points
    You can set the INI variable and restart LabVIEW using two Invoke Nodes. You will have to confirm "Quit will abort all running VIs" and it should start back up with the correct setting. (LV 2012)
  27. 4 points
    Wait till you see LabVIEW 2013. It's so ahead of it's time it's nostalgic. Lucky I hacked NI and stole a snapshot build so I can show you all:
  28. 4 points
    <sarcasm>What could possibly go wrong with this?</sarcasm>
  29. 4 points
    If you want to see a Certified LabVIEW Developer sample exam written using LabVIEW classes, I am uploading one here. I built this over the last four hours in response to comments in another LAVA thread which correctly pointed out that a sample CLD written with classes was not available for review. If you wish to comment on improving this class-based sample exam or ask questions about how it works, please post them here. If you wish to debate whether LabVIEW classes are worth using or whether they are overkill for real apps (including for the CLD exam itself), or any other philosophy, please post in the original thread that spawned this. The sample exam that I did was ATM version 2 (I am attaching the PDF to this post for ease of reference). After 4 hours, I have the solution posted below. It is not a fully fleshed out app -- it is exactly what I have finished after 4 hours and would have turned in on the exam. It is very similar to what I turned in for my actual exam, although I will note that for my actual CLD, I specifically brushed up on file handling and had that working. Tonight, I was unable to recall my cramming, so that just got dropped (but documented as a TODO!). Top level VI is ATM UI.lvclass:Main.vi. This VI takes an ATM UI object as input in case configuration options are added to this application in the future -- those options are already part of the UI loop. Issues that I know of: File I/O is not done, as I mentioned above. The display strings are placeholders ... I didn't type out all the proper strings. There's no way for the user's name to be displayed when they put in their card. Although I documented the VIs, I did not fill in documentation into the classes themselves and probably should have. Other than that, I think it all works given the limited testing I was able to do within the 4 hours. I have no idea why I felt the need to make setting the display message go through an event instead of just setting the local variable every time. I think i had it in my head to bottleneck the localization, but that doesn't work, of course, because you have to be able to format information into the strings. That should probably be removed entirely. I did build a message abstraction from ATM UI to ATM, but I didn't build a messaging abstraction from ATM to ATM UI. Why? Because I thought the data needed to respond was always the same. It wasn't until later that I decided that was a mistake, but I figured I should finish out this way. Building a true abstraction layer for completely isolating the ATM from the ATM UI is probably more than can be done in the 4 hour block unless you've got some scripting tools to back you up -- we'll have to see if it's reasonable in LV 2012 (without going into detail, assuming the beta testing goes well, there will be tools to help this exact problem in 2012). 100928-01.pdf AQ_ATM2.zip
  30. 4 points
    I just went though this for my business. I am based in the USA, and I am a small LabVIEW consultant. There are 3 types of insurance you generally need for a business. General Liability, Workman's Compensation and Professional Liability (aka Errors and Omissions). General Liability protects you if someone on your premises falls and wants to sue you. Mine has an additional rider called Baily's insurance. This covers equipment not owned by you. If you drop it, and break it, your Baily's will cover it. This is not expensive insurance and is great value for the money. There is also some product and data loss protection in my general liability policy. Workmans Compensation is if you get you hand chopped off at your customers site or someone working for you. It will pay for your (and employee) medical costs, and protect you from some liability. This is generally what customers want to see you have. Having this insurance protects the customer from getting sued by you if there is an accident (that is why they want to see it). This insurance is based on your payroll. It is not that expensive because computer programmers are at a low risk to get injured. (I got into the accountants category). In the US Workman's Compensation is by state. Michigan workman's comp laws are different than Ohio. If you have employees you MUST have workman's comp Professional Liability (aka Errors and omissions) protects you if you mess up and somebody wants to sue you. The thing you really want is the insurance company to pay for the lawyer. Legal fees will KILL you. I am more concerned about the cost of litigation than the amount somebody would potentially sue me for. Professional Liability insurance is expensive, and most folks in the insurance industry don't understand what we do. I went through IEEE. They spent the time to find an insurance company and explain the risks of our job. That means better and cheaper coverage for us. IMHO it is very rare to get sued. The costs of litigation for both sides usually causes cooler heads to prevail. However it only takes 1 a**hole... Reason does not exist in a legal situation. The judges, jurys, and lawyers have no clue on technical matters, and don't care. You could be totally in the right and be liable. Having a big bad insurance company with an army of lawyers on staff who don't want to pay claims is what you are paying for. Using a building contractor analogy, having LabVIEW certification and insurance you are now "licensed and insured". IMHO this is a very marketable thing.
  31. 4 points
    Hi, I was trying to track down a strange error in a library function and got the following: For debugging I had to disable VI inlining and the error changed in something more meaningful: Basically the problem was a parse error resulting in a wrong variant to data conversion (path to i16). I wonder who is "Akash B" and "Stephen M". About the latter I have a guess .
  32. 4 points
    Name: OpenG Config XNodes Submitter: GregSands Submitted: 08 Jun 2011 File Updated: 08 Jun 2011 Category: *Uncertified* LabVIEW Version: 8.6 License Type: BSD (Most common) These XNodes wrap the OpenG Variant Config routines so that clusters are automagically returned as themselves rather than as variants. The XNodes simply call the OpenG routines, as I didn't want to have to worry about handling (or rewriting) the reentrant algorithm used. XNodes are provided for Read/Write INI Cluster, Read/Write Section Cluster, and Read/Write Key, and should work as direct replacements. Many thanks to Gavin Burnell for his extremely helpful toolkit, and his release of Array XNodes which provided the inspiration for trying my first XNodes. I also use a modified version of the XNode Manager by Aitor Solar to create the initial XNodes. All the usual caveats apply when using XNodes - i.e. don't, unless you know what you're doing, or don't care what happens! Dependencies: oglib_variantconfig >= 2.7-2 lava_lib_labview_api_scripting_tools >= Click here to download this file
  33. 4 points
    Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG community is moving its primary discussions into the LAVA discussion forums. This will server two primary purposes: 1) To increase the visibility of OpenG and make it easier for more people to contribute, find support, and stay up to date about developments in OpenG. 2) To reduce the burden of the spam and other server administrative tasks. The existing OpenG discussion forums will remain available as a read-only archive, and will include a prominent notice that the discussion forums have moved to a new address, here on the LAVA forums. We hope you agree that this is a great step forward for OpenG and that it will add yet another positive element to the already solid foundation of LAVA. We are confident that it will allow the OpenG team to better serve its users, as well as increasing the amount of participation as a whole. If you have any questions about this transition, please post a topic in the OpenG forums on LAVA. Thank you, Jim Kring OpenG Founder
  34. 4 points
    Speaking as the guy who wrote the queue primitives... The queues are meant to be the primary means of communicating data in LabVIEW between parallel chunks of code. They are completely thread safe, and they participate with LabVIEW's concurrency scheduling algorithms. They're designed to minimize both data copies and latency and have been stable for many years. User events go through queues that share most of the code with the general queues, although they have a bit more overhead since at any time there might be multiple listeners for an event, which can (not necessarily "will", just "can") cause more data copies. User events are data broadcasters, where as general queues are data point-to-point transmitters. The general queues thus have less overhead, but it is a very small amount less overhead. For me personally, I prefer the general queues instead of the user events only because of the arcane nodes and special terminals that are required to register dynamic user events. I use user events when I need to have code that sleeps on both UI events and data arrival. But it is really personal preference -- many programmers are successful using user events generally.
  35. 4 points
  36. 4 points
    I tried it through .net and it works. I had to browse for the mscorlib.dll file for LabVIEW to find the SHA256Managed-class. Cheers, Mikael
  37. 3 points
    I also have a method to propose: U64 Nanoseconds to LabVIEW Timestamp.vi
  38. 3 points
    There was a crashed cache table in the database which I repaired. I think this might have been the source of the problems. So perhaps it's fixed now. Not sure how this table always gets corrupt. Mysteries of MYSQL and the forums software.
  39. 3 points
    Without the source your only hope is to use the mechanisms left by the developer. If there is no ActiveX and the only interaction is with a mouse and keyboard, then you'll have to simulate a mouse and keyboard. There are several examples of using AutoIt or LabVIEW to look for windows to be active (based on their titles) then simulate pressing keys to navigate where you want and type in information. This is quite error prone and user interaction may mess with stuff.
  40. 3 points
    "Resolved to customers satisfaction" it is then. FWIW. Escalation can be very quick or many days. It's only the time-zone differences that make the delay if (and this is a big if) the application engineer knows who to contact and can articulate your concern. This is why examples are so important. Once you have found a well connected application engineer that you can ask for by name to get past the front door bouncers - 24 hours max for a useful response.. As en ex European. - a telephone call with a follow up email (with example and bulleted list of questions) at 4pm and you will usually have the result sitting in your inbox in the morning . That named engineer is now your dive buddy (as much as they might resist ) in the murky waters of NI support procedure. Hold on to them as if your life depended on them because your sanity does
  41. 3 points
    Once again, I'll be there with (some of) the rest of the LabVIEW Tools Network team. See everyone in a few weeks!
  42. 3 points
    But.... If I ignore what everyone says, then I must also ignore what you say..... D'oh, what to do? Coffee.
  43. 3 points
    Alternatively, if you dont have the command line tools installed (or don't want to use them ), you cou could use TortoiseSVN's COM interface (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev-com-interface.html)
  44. 3 points
    Been there, done that. I have G implementations of ZMTP (at least most bits I need) and AMQP (0.9.1 not the 1.0 trainwreck). I tend to use AMQP most often since my code is more complete (and there was more adoption of it when I wrote it), but they are both great. The brokerless nature of ZMQ can be great when you need it, turns out most times I was implementing a de facto broker and could have stuck to AMQP. Unfortunately the specs are really laid out seductively in terms of classes and methods so I gummed up the works by using a bit too much LVOOP (not to mention busted my carpal tunnels). Performance is ok, but as I de-LVOOP it is finding another gear. I create worker pools consisting of simple LV workers and similar C++, Java, or Python workers and see what share each worker does. LV is behind, but getting up there with the big boys. The LV9 to LV12 performance kick was also welcome here. The AMQP implementation gave rise to one of my new mantras: No LVOOP in a loop.
  45. 3 points
    If you don't always want to debug, add a context menu item or an off-panel button with a hotkey set. Bury your breakpoint in the event handler of that object, and tada! On-demand block diagram!
  46. 3 points
    National Instruments is donating a 4Gb DatastickPRO USB thumb drive: Well that doesn't sound very interesting, does it? What kind of lame-arse prize is that NI? I mean, come on - you've got to do better than a 4Gb thumb drive - seriously. Wait, what? What's that you say? There's something on the drive? You're kidding! A LabVIEW 1.0 Emulator, complete with instructions of how to run it! You can run the emulator from the datastick, and test out your favorite retro code - just remember, do not adjust your monitor - the code is meant to be in black and white Thanks to National Instruments. for continuing to support the LabVIEW community!
  47. 3 points
    The list should always be sorted. I have filed CAR 308287 to update the documentation accordingly.
  48. 3 points
    Awesome! I've just printed this and placed it on my cubicle wall next to my 'How to be an expert' chart (see below)
  49. 3 points
    I love LabVIEW and it lets me develop dependable code quicker than anyone thought possible for a decent price. I'm sorry NI, but this is for your own good. You'll thank me one day. LabVIEW is the Apple of programming languages. You are only allowed to do what NI thinks you are smart enough to do. A little less hand holding would be nice. (I swear I'm smart enough to not create race conditions) It took you 25 years to develop a pointer (DVR) to data? really?yes, i understand 1EQs have been around for some time, but they are kind of a hack[*]File dialog globally remembers last path[*]"lost" files in classes/libraries/xcontrols cannot be replaced with a file name that differs from the original lost file[*]ctrl+drag (the operation that "makes" space on the FP/BD) can't be disabled ever blow a hole in a case structure with 20 cases? datasocket/shared variables unpredictably gain/lose bugs every release cyclecauses me to go through weeks of DS/SV qualification testing every time we upgrade Network malfunctions/dropouts are highly visible to end users. #1 reason why my upper management doesn't think LabVIEW is a real programming language. would drop DS completely and go with SV, but i don't wanna buy DSC for security features that were included in DS going to raw TCP/IP communication as soon as i can. [*]LabVIEW Developer Suite does not include developer tools Express VIs don't count as developer toos Most webcasts/Virtural User Group presentations either cover basic/intermediate new user training or around something NI wants you to buy.Why can't they just be about becoming a better advanced programmer? Or how about an advanced application developer? You want to be a real advanced programming language, but you aren't giving your customers the tools to become advanced developers. The large application user group is a great example of this. gimme more! Most of us do not have computer science backgrounds. Anything you can do to bring in CS concepts and strategies would be appreciated. [*]Front Panel objects are outdated #2 reason why my upper management doesn't like LabVIEW (a.k.a it doesn't look cool) customizing objects is difficult and kludgy. because of this, i don't have time to make things look pretty. if you released a front panel control dev tool, the NI community would solve this issue for you Ok, now I'm done hatin...back to work.
  50. 3 points
    Am I the only one who thinks this is really stupid? Not because of the shortcuts themselves. They're useful. The problem is with placing them in QD. W. T. F. !. This is the kind of thing that would be ideal in something like the right-click framework - select something, operate on it. Why is it in QD? Obviously the answer is simple - someone wanted it and didn't have anywhere else to put it which would make it easily accessible, but I find this to be totally unrelated to the QD functionality and very undiscoverable.

  • Create New...

Important Information

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