bjustice

I ran into this exact issue as well. There is even a good issue ticket on this with some discussion: https://github.com/vipm-io/http-rest-client/issues/29 Jim and I spun off a plugin based package architecture to solve this. Just as others have commented, the plugin architecture means that the parent package is abstract, and then users only need to download the plugin implementation that matches their needs. Pointedly, the windows-only advanced-http-client library is a separate plug package... so you don't need to pull it into memory unless you install and use it. Here is a good discussion on this: https://github.com/vipm-io/http-client-plugin-base/issues/4 Tangentially related: Jim wrote a LabVIEW wrapper around the RUST reqwest crate. and then we wrapped this in a http client plugin. The native LabVIEW http client library is blocking/single-threaded on linux. But, this reqwest implementation is nonblocking. It's been amazing for my needs

I have a LabVIEW-built DLL. (2021 SP1, 64-bit, Linux) I am calling this DLL cyclically by a RUST application over FFI. Never on the first DLL call, but sometimes on subsequent DLL calls, I am hitting a segfault: LabVIEW caught fatal signal 21.0.1f6 - Received SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x170 I can't seem to figure out why this is happening. It has something to do with the fact that I am needing to call the DLL several times, with little wait time in-between calls. I suspect that the DLL is unloading, and then reloading between each call. And I suspect that this unloading might be creating a weird race condition with the runtime engine, where the runtime engine is still busy unloading the DLL from the first call, when the 2nd call happens. Any ideas are welcome. Scratching my head on this one.

I have experienced the same thing when my VI was the member of a large class. I removed the VI from the class, set the splitter positions, and then added it back to the class. :shrug:

Most IP cameras that I have played with will also implement simplistic PTZ via HTTP GET or HTTP POST commands. And these are usually the commands sent from the web interface of the camera. So, Just wireshark capture that traffic

Whelp, nevermind, I did indeed have a LabVIEW clone in the shared object not shutting down. Sigh

I have a RUST application that loads and calls a LabVIEW-built shared object in Linux. This is working! However, it appears to me that the RUST application is hanging when I try to shut it down. Presumably, I think this might be because the LabVIEW runtime engine process and thread pool is still running. The shared library itself isn't running any processes. I'm curious if anyone has run into this before, and if there is a proper way to stop-calling or unload a LabVIEW DLL/SO.

Thanks Wiebe, good catch. Also note that this post pre-dates the release of the JKI .NET library. As always, the JKI product is very polished. I don't think they added the Ctrl-C command to the library yet though, but there is a request: https://www.vipm.io/posts/d078e550-5920-460f-8c12-a9dc547cdde4/

I'm updating my dependent packages to reference the new method. So, don't feel pressure to push a new package on my behalf. But it felt like it was worth bringing to your attention. Cheers!

Hi Hooovahh! I think I found something that could be considered a bug? I saw that a sort option was added to the remove 1D duplicates VI. It looks like the old version of this VI was left in the package. (Presumably to protect backwards compatibility) However, something must have happened, and I'm seeing that the connector pane on the old version of the VI got rotated.

Via the afformentioned benchmark test, the unflatten from string method is on-par with the "To String/Typecast" method. My VIM is still beating those noticeably for little endian operations. So, I'm going to try using my VIM for a project and I'll see how that goes.

In THIS THREAD, Rolf suggested that the TypeCast primitive should have an endianness selector. So, I took the code that I created above and slapped a byte order input on it! Of course, this isn't as flexible as the real primitive. But this fills a wide use-case from a project that I'm working on. Why is this interesting to me?: On more than one occasion now, I've run into situations where I have to receive a stream of bytes at high rate over the network, and TypeCast these into LabVIEW numerics. and usually when this happens, I'm getting those bytes sent to me in little-endian order. Because that's what dominates the industry these days it seems. I use the TypeCast primitive to convert the byte stream into numerics, but this means that I have to reverse array order before handing the data over to TypeCast. And then, depressingly, TypeCast performs another set of byte swapping against the data. So, I was hoping to remove all the byte swap operations with this VIM. I plugged my VIM into the benchmark tester, and the results seem to make really good sense to me: 1 = My VIM with "Big Endian" input --> My VIM must perform array reversing; this makes it slower than all other methods thus far. 2 = My VIM with "Little Endian" input --> My VIM does not have to perform array reversing; This makes it almost as fast as MoveBlock with preallocation. Would love to know what you guys think TypeCast.zip

Ok, I made a VI that emulates the TypeCast primitive with a few notable differences: Uses the MoveBlock command to perform the memory copy Input "x" restricted to u8 byte array type. (Common use-case) input "type" restricted to scalar or 1D numeric types. (Common use-case) Assumes platform endianness = Little Endian. (Valid due to above convos) What's cool about this is that it gives me control over whether or not I want to perform the endianness conversion. (You can see that I use the reverse 1D array primitives to handle this.) If your byte array is already little-endian ordered, then you can remove the reverse 1D array functions and reclaim that performance. TypeCast using MoveBlock.vim

Revisiting this thread for a new project. (Rolf, your posts here have been very educational.) A bit of an academic question here (I'm mostly trying to make sure that I understand how this all works): 1) Are there any primitives in LabVIEW that would return the endianness of the platform? (I supposed this would be absurdly boring if LabVIEW only ships on little-endian platforms at the moment.) 2) If this primitive existed, could I theoretically use this in conjunction with the MoveBlock command to replicate the behavior of the TypeCast primitive? My understanding: IF platform endianness = big endian, then perform memory copy without byte swaps IF platform endianness = little endian, then perform memory copy with byte swaps

2018. also fixed the typo All decorations.vi