Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by egraham

  1. At JKI we have a tool we use internally to do this, but I haven't looked at the code under the hood and can't confirm it works cross plat form. It does work correctly on Windows, though.
  2. egraham


  3. egraham

    Vision Licensing

    From the album: Images

  4. I didn't read this discussion closely enough to see if you were already part of it, but if you haven't read it, I think it touches on your problem. Steven Mercer talks about the differences in typedef behavior between different LabVIEW versions and says 2014 vastly improves upon this. https://decibel.ni.com/content/thread/20339
  5. Wilfried, I just saw this post. To answer the question you asked on the NI forums, yes, it's the same guy answering your Reach questions over there.
  6. A while back I was using DashCommand in my car with pretty good results. The updates were about 1-2 times per second. I wanted to see smoother updates on things like RPM. I used it a few times to read diagnostics codes and reset my engine check light. Also, my car didin't display gas mileage so I would use it on longer trips to see what type of gas mileage I was getting at any given point in time. Linking to the bluetooth ODB2 transmitter was kind of a PIA because it took about 10-20 seconds to get it set up so it's not the kind of thing I would use around town or on shorter trips. Around
  7. The difference is that you now have a way to have multiple processes (state machines) running simultaneously and communicating with each other. In that example, events are the communication mechanism.
  8. JKI has a presentation on how to do this using their state machine and user events. It's a convenient and simple way to expand on an already very useful architecture. You'll find the JKI state machine gets used a lot in the LabVIEW community. Check it out here: http://blog.jki.net/events/niweek-2011-beyond-state-machines-slides-and-code-now-available/
  9. I should post this for anyone's future reference who happens to be doing a search. There is an example provided by REACH that I had overlooked. They call it ikb and it's one of the demos. It's a more complete keyboard, but is stil lacking as there are some undesirable visual artifacts on some of the bitmap images used. I had to modify some of the macros to make it useable for my application, but a lot of the functionality was already there in the example macro so it definitely saved me some work.
  10. Thanks to both of you for pointing out these keyboard options. Unfortunately the REACH touch screens rely on bitmap images that have to be uploaded via serial or using an SD card. They can't actually display LabVIEW front panels. At this point it's looking like I will have to create my own.
  11. For those of you out there that have experience with the REACH touch panels, has anyone created a complete keyboard yet? The examples provided by REACH are limited in that they are only letters or numbers and lack a lot of the additional characters that make up a complete keyboard. If anyone has done this work already and wants to share it, let me know! Thanks, Eric
  12. Karol, Are you wanting to open the subVI front panel if it's already running? If so, you need to use the reference to the subVI to check its state so that you don't try to start it asynchronously if you've already started it. Rather, you would just open the front panel of an already running VI. When you use the stop button on the subVI you can start it again from your main VI, but closing the front panel of the subVI leaves it running... so you can't start it again since it's already running. You can override the panel close of the subVI using an event structure (see attached). Or you can le
  13. This should be one of the more interesting sessions at NI Week. I'll definitely plan on being there! Thanks JKI for always putting such great material together.
  14. I'm not a hater, but saw this sticker over at the Evil Mad Science storefront and thought it was pretty funny. If anyone hated LV enough it definitely wouldn't be worth spending the time to make a post about - instead they would just stop using it. Some of us are always looking for something to complain about when we don't have enough other things to keep us busy. http://evilmadscience.com/directory
  15. How much data are you wanting to write real time? TDMS might be the way to go.
  16. I can't downconvert to 7. Here's a screenshot of what I did.
  17. chrichter, Attached there is a VI that makes the tanks run backwards with both in a While loop instead of a For loop. There is lots to study up on in terms of events, state machines, etc. This looks like a cool program. You are well on your way. Keep tinkering and making programs. That's the best way to learn. Hopefully you can convince your company LV is a tool they need. There is a lot to point out, but one thing I'll say right now is that property nodes that only need to change a property once can be placed outside of your main loop. That way they only happen at startup. You can use your
  18. This sounds like a good project to learn about image acquisition. Christopher Relf (http://lavag.org/user/181-crelf/) has written a book about this subject. I'm sure he would appreciate a plug for his book. It's probably one of many places you could start. http://www.amazon.com/Image-Acquisition-Processing-LabVIEW/dp/0849314801/ref=sr_1_1?ie=UTF8&s=books&qid=1302458393&sr=8-1 http://zone.ni.com/devzone/cda/tut/p/id/2808 Eric
  19. Ian, I'm not sure if you're still working on this, but it sounds like what you're tring to do is allow the user to configure the setup of the channels to acquire. This should be simple enough using the DAQmx functions like create task, creat channel, etc. This could be done in a VI at application startup before the main application loads. The output from that VI could be a cluster containing the data for your channel configuration. Is that what you're going for? The information could be updated easily enough during the middle of a test, but the application would continue to acquire data fro
  20. Ha ha! I thought vintage was in these days... Neville, Thanks for your insight/ideas. Splitting the tasks seems like a good idea. The application works, that's the important thing. For my own education I was wondering if there was a really convenient way to make the hardware scan channels differently. At this point it seems like I know all the options I have to work with. Eric
  21. Gaurav, I'm not sure a couple of local variables would hurt your score all that much. If you really wanted to avoid using those you could make sure you've set the default values for all controls in the entry console, then create an invoke node for your cluster to reinit all to default values. I think it's not a bad idea to have separate folders for your controls and subVIs as illustrated in the sample exam solutions. You could consider using a typdef enum for your case selection. It might be faster to code than using strings, but I don't know that they would take away points for this. I di
  22. That's one idea. However, I'm still starting and stopping tasks to accomplish this. I'm using an old SCXI system for all analog measurements - thermocouples, 4-wire RTDs, current inputs. I average measured samples to increase accuracy, especially on the 4-wire RTDs. The RTDs happen to be connected to a mechanically multiplexed module. The NI manual suggests scanning multiple samples from one channel before switching to the next channel to avoid wearing out the mechanical multiplexer. The channel switching is actually audible. Imagine switching a mechanical multiplexer 100 times/second - it wo
  23. I saved the edited version in 8.5 and attached. A queued state machine could work for what you're doing, but might be more than you want to look into right now. If you're really going to use the timeout event like that, at least wire a number other than zero to it. That prevents it from eating up as much CPU by limiting how often it executes. Keep in mind that making your application work this way is something you should consider changing in the future as it's not considered best practice. I added a clear button and a corresponding event case that writes zeros to all your indicators. After
  24. This is a question I've wondered about for a long time... During continuous acquisition is there an easy way to scan from the same channel multiple times within a task set up in MAX before switching to the next channel? By default, channels within a task are scanned one at a time and this process continues - acquire one point, switch to the next channel, acquire one point, and continue through the list. Where the time relationship between channels is not important, sometimes it makes sense to acquire several samples from one channel before switching to the next. Chapter 4 in the M series use
  • Create New...

Important Information

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