Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/21/2014 in all areas

  1. Hello everyone, I don't how you manage that on you own, but when I have spent to much time on LabVIEW code I need to do sports to find inspiration or simply forget concerns for one hour or two. If you are used to do the same thing, you can joined "LabVIEW Users Do Sports" STRAVA club http://www.strava.com/clubs/LabviewUsersDoSports I'll find it funny to follow and challenge other LabVIEW users all around the world. I look forward to seing your run on Strava. Olivier
    2 points
  2. You’ll need to mark your Image Indicator as “Synchronous Display†if you want it to display before the Producer overwrites the buffer. Indicators are asynchronous by default and update at something like 60Hz, slower than your 400 frames/second. BTW, I can’t see how this code would interface with some other process doing the main application work on all 400 frames. What do you do with the full 400 frames?
    1 point
  3. This is a common issue when working with by-ref objects. The way I solve it is by making static VI called things like "MyAction" and then making a Dynamic dispatch VI named "MyAction-core". All "MyAction" does is de-reference the object, call "myAction-core" and then updates the DVR value. Also, if these are actions that HAVE to be performed, I'd just throw the common code in "MyAction", and then let the children override "MyAction-core" to implement the code that's specific to them. This eliminates the need for children to call to parent. I'm not a big fan of requiring a call to parent, because I find most of the time it matters if the child calls to parent before or after running it's code. So you end up having to put in documentation "Make sure the first thing your child code does is call to parent". This is bad. Basically what I'm saying is a lot of time when people (and I think you in this case) are checking the "Require Call to parent", what they really want is a Template Method pattern. http://en.wikipedia.org/wiki/Template_method_pattern
    1 point
  4. ShaunR - I was unaware that you could use events like that with Imaq IO refs...very nice. I will have to remember that for my next vision app. While the Godwin Global approach is nice, I think there are two issues: 1) I believe the poster is not using IMAQ camera interface (Matrox proprietary instead) and 2) Somehow his Imaq Image Display is getting corrupted by newer images when it is updated faster (400fps) than it can be painted by the OS. I'm not suggesting the "triple buffering" approach is the proper solution here, but I am collaborating with the hopes that he can see a "simple" LabVIEW queue approach can work. PS. I surprised ShaunR doesn't have a "Cantankerous Callback" approach and I haven't seen any Actor Framefork approaches with multiple Actors.
    1 point
  5. And the stage is set! In the blue corner, we have the "Triple Buffering Triceratops from Timbuktoo". , In the red corner we have the Quick Queue Quisling from Quebec and, at the last minute. In the green corner we have the old geezers' favourite - the Dreaded Data Pool From Global Grange. Dreaded Data-pool From Global Grange.llb Tune in next week to see the results.
    1 point
  6. hello, here is my Chess Game. (Chess Engine) (100% LabVIEW) Artificial Intelligence : Algorithm MIn-Max + alpha-beta pruning + evaluation function the latest version Beta 5, can be downloaded here : https://decibel.ni.com/content/message/83307#83307 enjoy and good fun If you like it, a little kudo will be a pleasure, on the original post, here : http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Chess-Engine-100-LabVIEW/td-p/2870892 Comments and feedback are welcome. Ouadji,
    1 point
×
×
  • Create New...

Important Information

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