bjustice

Hooovahh in the hole!

Really? You're suggesting that there's potentially a faster way to convert a u8 byte array to an array of DBLs? I hadn't considered that. I really thought that TypeCast would have been the fastest option. But, I also didn't realize that type cast used the string unflatten code under the hood until AQ communicated this.

oh, I do wish that the typecast allowed for me to specify endianess though. I recognize that the unflatten from string allows for me to specify endianess, but this is substantially slower than typecast. So, I often have to reverse the byte array before typecasting to get the endianess correct.

Hooovahh, I find myself running into this situation somewhat frequently. Usually, it's because I am pulling off an arbitrary blob of data from either a network connection, or from a data file, and then have to type cast this into the appropriate numeric data array type. In these situations, performance is paramount, data is often very large or coming in at high rate. Unless I'm missing something, my understanding is that this mechanism here represents the most performant way to convert an array of bytes or a string into a strictly typed numeric array. Thus, the optimization discovered by AQ here is very useful. Thoughts? Thanks!

Got it. Thanks!!

Even better, @Aristos Queue could this be turned into a generic VIM?: "TypeCast with optimization.vim" I tried my hand a creating this, given my understanding of your explanation: Type Cast with Optimization.vim

Thanks for posting this. This is going to make me go back and change some code. Is this performance boost agnostic to the "type" input on the typecast primitive? Your explanation makes this seem to be the case, but I just want to confirm. Basically, can it be stated as a general rule: "if you are wiring a u8 array into a type cast primitive, then it's always best to go ahead and drop in a byte array to string primitive" Thanks!

I had not considered simply ignoring the JSONtext error output. While this is still not ideal, I like this solution much better. Thanks!

I'm running into this same issue. A web server returns "key":null When trying to use JSONtext to convert JSON to LabVIEW data, I get the error: Unable to convert the following JSON to LVType 'String':null I would love for "null" to return an empty string. Is there a workaround here that anyone has been implementing? I'm doing a string replace for now, but this is hacky and not bulletproof:

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:

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.

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

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?

Understood. For what it's worth, this code met my personal needs. Thanks for the community contributions!

oops, sorry, I scanned a bit too fast then Edit: Hooovah's spec changed also worked for me. Upvote

Just installed the 4.2 beta package. I'm looking for 64-bit support. Is there some funkiness happening with the naming that is upsetting VIPM? This beta package installs as a separate VIPM package with a separate palette, but it's still causing the non-beta ZIP library to "think" there's an upgrade available. Is anyone else experiencing this? It's causing some confusion here. Thanks!

dev's who only know LabVIEW:

yikes, what a weird bug. good to know, we're about to upgrade

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.

It was a pleasure having you on the team Shameless plug, we are still hiring:

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

I just go to see all of you guys "dance" at the Spazmatics band night

🎅🎄

@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

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)