Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 10/07/2019 in all areas

  1. The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert. Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE. This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it. A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value. Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. I’ve created two malleable VIs, Read DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type. Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values. Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments! DVR Read and Write VIs 1.0.0.zip
    1 point
  2. 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.
    1 point
  3. I have a "rule" something quite basic like "VisionSystemRef_CameraName_BufferType_Index" For the buffer type I have a typedef with a few options : - "Acq" for acquisition only buffer, I never do any processing on these, they are used only to store an image that has just been acquired from a camera - "Save" buffers reserved to store images that will be saved to disk - "Proc" for processing - "Disp" buffers reserved for images to be displayed on the UI So I use the "image copy" VI a lot do to transfer image data from a buffer to another
    1 point
  4. I've migrated most of the code to Github.
    1 point
  5. I followed these instructions: https://www.atlassian.com/git/tutorials/migrating-overview I did that because my goal initially was to export to bitbucket, which I did. Then I changed my mind and decided that Github would be better for a community project like this. So then, since it was already in a Git format it was simple from within the Github website to select "import" and just point to the Bitbucket URL. Note: Those instructions work best if executed from a linux machine. I quickly spun-up an Ubuntu VM to do this.
    1 point
×
×
  • Create New...

Important Information

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