Jump to content

bjustice

Members
  • Posts

    95
  • Joined

  • Last visited

  • Days Won

    5

bjustice last won the day on December 13 2021

bjustice had the most liked content!

About bjustice

  • 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

2,364 profile views

bjustice's Achievements

Explorer

Explorer (4/14)

  • Conversation Starter Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Reacting Well Rare

Recent Badges

24

Reputation

  1. Our team is responsible for the design, implementation, testing, deployment, and maintenance of LabVIEW based data acquisition and controls systems that support rocket engine test stands, component testing and ground support equipment. You will share in the teamโ€™s impact on all aspects of component, vehicle subsystem, and engine testing. This position will directly impact the history of space exploration and will require your dedicated commitment and detailed attention towards safe and repeatable spaceflight. Blue Origin has 2 facilities in Huntsville, Alabama. We operate a large engine test facility located in the west test area of NASA Marshall Space Flight Center. We also operate a factory near Explorer Park, which is tasked with mass production of our 550lbf methalox BE-4 rocket engine. Within a 50 mile radius, we will build, test, and deliver this rocket engine to ULA for integration into a launch vehicle. Position is for the Huntsville, Alabama office. Must be a U.S. citizen or national, U.S. permanent resident (current Green Card holder), or lawfully admitted into the U.S. as a refugee or granted asylum. https://blueorigin.wd5.myworkdayjobs.com/en-US/BlueOrigin/job/Marshall-Space-Flight-Center-AL/LabVIEW-Software-Engineer-II-III_R21643 We are still hiring positions for our team in the Kent, Washington office as well as indicated here:
  2. For what it's worth, the INI file and INI file signing isn't that big of a pain. Somewhere in the links posted previously is an INI signing tool. NI basically open-sourced this. Do it once, and never worry about it again.
  3. There is also a presentation on youtube, which I found helpful: https://www.youtube.com/watch?v=xXGro_DylHs&ab_channel=LabVIEWArchitectsForum FWIW, a few lessons learned: The project provider VIs have to be installed in the LabVIEW resource folder. Distributing this through VIPM makes this super easy to specify this install location, and also turn on "require LabVIEW to restart" after install You have to restart LabVIEW to test code changes The code executes in a separate LabVIEW context. This can cause some weird behavior, I found that not all code runs in this context safely
  4. Was there ever a call for presentations for this event? Or should we expect for this to be all NI presentations? Will there be a LAVA (advanced users) track?
  5. yikes, what a weird bug. good to know, we're about to upgrade
  6. I've used the G Web Development Module (fairly heavily) once for a project. Also used the MediaMongrels WebSocket API to then have the WebVIs talk back to a LabVIEW application. Worked out quite well. The most alarming aspect of the G Web Development module seemed to be the lack of a user-base. I struggled to find any examples online excluding NI's own examples. The darkside forum felt like a ghost town when I asked for help with a problem. Even now, looking online, I don't see any published roadmap or planned features for the G Web Development. It's kinda sad. I really liked working with what existed.
  7. It was a pleasure having you on the team Shameless plug, we are still hiring:
  8. For what it's worth, I've been heavily using/stress-testing that padding code for flattened strings in TDMS. On the Windows OS, I've had no issues. I'm sad to hear about the issues on the Linux RT OS. I think the saving grace is that, I rarely ever need to read a TDMS on a Linux RT. Usually it's create/write to TDMS on RT, then read on Windows
  9. I just go to see all of you guys "dance" at the Spazmatics band night
  10. @Porter @Antoine Chalons There's some background info here. A few things. Both of those libraries are branches of the Erdos Miller code. However, I communicated all of my modifications to Antoine, who then re-implemented them in his library. I have little intention of making additional changes to my branch. Conversely, I suspect that Antoine intends to continue to support his branch, if only in a limited manner. BlueTOMLSerializer is not just a TOML library. It was written as a TOML-based plugin for the BlueSerialization engine. https://www.vipm.io/package/blue_origin_lib_blueserialization/ This is a large piece of code that handles serialization and deserialization of classes quite well. The user can select an implementation of JSON, TOML, or other by choosing a different plugin library. I fully intend to modify BlueTOMLSerializer to drop all the TOML code and directly consume Antoine's library as a dependency. This, for example, is what I do for JSONtext. Unfortunately, I'm waiting on a specific feature request to be implemented in Antoine's library: https://github.com/AntoineChalons/lv-toml/issues/24 Hope this helps
  11. My goal is always to produce a user interfaces that users won't recognize as being written in LabVIEW unless you told them. 2 examples of this that I've seen online come to mind: VIPM (VI Package Manager. This received a major UI overhaul in 2020.) Scout TDMS viewer (From Signal.X)
  12. Today I learned. Thanks Logman
  13. lockup.vi I ran into a strange LabVIEW (bug?) today. (Note, I'm using LabVIEW 2020 SP1) Figured it was worth sharing, maybe you guys have insight here. I've attached a VI that demonstrates the behavior. Basically, if you click the "Do" button, then LabVIEW will completely lockup. You have to hit the abort button or task kill to escape the lockup. In the "False" case below, the event structure loop doesn't get kicked off. However, it seems like LabVIEW locks up when the Do button is pressed... perhaps indicating that LabVIEW is waiting for the event structure to fire off the event... which, of course, never happens in the False case. What's even stranger is that if you flip the disabled structure, you'll see that the code doesn't lockup if the case structure is given a constant False input. This tells me that compiler shenanigans are at play. Weird weird weird
×
×
  • Create New...

Important Information

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