Jump to content

bjustice

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

2

About bjustice

  • Rank
    More Active
  • Birthday 10/31/1990

Profile Information

  • Gender
    Male
  • Location
    Van Horn, Texas
  • Interests
    Rockets

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
    2012

Contact Methods

Recent Profile Visitors

619 profile views
  1. drjdpowell touched upon the primary (and initial) purpose for the code. I had an issue where I wanted to use user events, but the rule of "who starts first" came into play. This eliminated that worry. I could spin up a sub-process, register it for the user event, and force the user event case (only in that subprocess) to initialize with the most recent data. And, it's clean! Notice how I'm able to share the "mycluster" user event case structure with both the initialization UE and the normal UE. No tacky need for another case structure event that only handles first call initialization, or some other similar thing.
  2. Oh, and it's saved in 2018 and makes heavy use of VIMs. So, apologies to those using older versions of LabVIEW
  3. I made a fun piece of code, and thought that I'd share. Maybe it'll spark some good discussion. Here it is: Push-Notifier.zip I wanted to accomplish 2 things with this code: 1) I wanted to be able to create a notifier that I can register as a user event. Basically, I want a user event to be generated whenever a new notification is sent. 2) When I register for a user event, I want to be able to also force the event structure to generate a user event using the most recent notification. (Helpful for initialization of data in the event structure) Demo VI looks like this: Anyways, thought this might be fun to share
  4. CAR created: Reference ID 726196.
  5. Interesting history. Thanks for the information. I've reported this to NI. I will post here if they generate a CAR thanks everyone
  6. Benoit, thanks for looking at this with me. It looks like the error that you generated there is a result of the "Vertical Arrangement" property not being allowed to be applied to boolean text. I get the following possible reasons for that error: So, this is good proof that not everything in the "text property palette" is compatible with boolean text. Which is fine, but the text select end/start should return a similar error in order to indicate the lack of support. Also, as I said earlier, I can copy/paste text into the boolean text and have it retain properties. Which means that the property node interface simply doesn't appear to support programmatic interaction.
  7. X-POST to NI forums. (No luck there so far.) https://forums.ni.com/t5/LabVIEW/button-with-different-size-text/m-p/3864798/highlight/false#M1095147 I am hoping to determine if there is a programmatic method to have a button with boolean text with varying font size/color. This is achievable with a strong control using text selection end/start. Booleans expose these same properties in the property node... but it doesn't appear to do anything. Even more interesting is that I can copy/paste text with varying color/size into the boolean text... and it will work. Thoughts? Thanks! bool_text.vi
  8. I still actively use the OpenG toolkit. I would say that 90% of my usage lies in the Array and File palettes. I also recently learned that Hooovahh rewrote the Array pallette using VIMs though, so I've been using that in newer projects. Hooovahh Arrays It might be nifty if OpenG added Hooovahh Arrays to the OpenG Arrays palette...
  9. Fantastic! This is exactly what I was envisioning. Thank you.
  10. Hey guys! This might be a dumb question... so ignore me if I'm out of touch. But, I'm a big fan of the OpenG toolkit. Is there intent to ever rewrite any of this codebase using malleable VIs? I know that many of the tools (especially the array VIs) use a polymorphic VIs in order to handle different data types. When malleable VIs were announced, I always envisioned that this toolkit would immediately benefit from this new capability. I'm mostly just curious
  11. 7 years later, this information helped me! Thanks for coming back to post
  12. I haven't head of TestScript before. Sounds interesting. But I have tried both the Enthought toolkit as well as the LabVIEW Python Node. I've been majorly impressed with the Enthought toolkit. I've passed fairly large data to/from Python and the performance has been pretty great. And it certainly does solve some deployment headaches. It has a building mechanism that is able to generate a self-contained python environment with only required libraries for running your code. You can copy/paste this environment directly onto a deployed machine and it will run! No need to install and configure a python environment from scratch for every deployed machine. 10/10 recommend
  13. Co-worker found the solution! This option in the packed library build spec will exclude the lvanalys.dll from being placed into the packed library build directory. Furthermore, when the application EXE build spec runs, it seems to be smart enough to include lvanalys.dll in the resource folder when the packed lib is a dependency. (Cool!)
  14. Good people of LAVA, I am running into a peculiar issue involving packed libraries. I have attached a zipped folder that illustrates this issue in a simplified format. When I run the build spec in the attached folder, I get the following error: My understanding is that the application builder is running into this issue as a result of trying to include the lvanalys.dll twice: -lvanalys.dll is a dependency of G-code in the main.vi -lvanalys.dll is a dependency of the packed library build: "math.lvlibp" One workaround that I've discovered is to rename the dll in the packed library build spec: As you might expect, this results in the Main application builder including both lvanalys.dll and lvanalys_mathlib.dll in the resource folder. However, since the names are different - this doesn't generate a namespace collision warning. The downside is that this feels a bit kludgy. And it would be nicer to find a solution where the application builder is smart enough to understand that it only needs 1 copy of this dll in the resource folder. Thoughts? Am I missing something? I have only recently started to explore packed libraries. Thanks! math.zip
×
×
  • Create New...

Important Information

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