bjustice

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!

On 1/30/2020 at 2:07 PM, drjdpowell said:

The error is coming from where you attempt to convert null (as in "comment":null) to a string.   Intuitively, one would think that a null should be equivalent to an empty string (just as when converted to a number, null becomes NaN and does not throw an error).  Thank you for the report.

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?

On 3/22/2022 at 3:40 AM, Rolf Kalbermatter said:

However, be aware that the github code as is is an experiment in construction. Lots of things don't work right yet and there are many bugs in the underlaying shared library that simply won't do the right thing yet. I'm slowly working on it but it is a side project and sometimes I just don't feel like debugging C code very much.

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)

Today I learned.  Thanks Logman

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