Mads

Going a bit off topic (ironically), but wading through those endless topic-shifting conversations on Discord feels like a step backwards....It is a nice tool for a public chat, but it makes things harder to find and follow 😞

2026 Q3 was released the other day by the way...

2020 was my favourite for a long time as we had issues on RT with many of the later versions. 2025 Q3 has been stable both on Win 11 and RT although the Linux RT Images are too bloated for some of the smaller sb/cRIO targets 😞. I did try to switch to 2026 when it came out, but ran into serious VISA issues on RT with it (which NI says has been fixed now). The next version we will move to is the upcoming 2026Q3 unless any issues show up during testing. It will include "native" SBOM-support which is good to have for the EU CRA requirements that kick in later this year (Still hoping for more significant feature updates soon though. The 40 year anniversary would have been a great time for some of those... 😮)

Hi, Thanks for the tip. They want to hire someone who can be a part of buidling the company as well so only in-house I am afraid.

Living and working in Norway I am not sure about this; What would be the best way to recruit personnell (US citizens only due to security clearance requirements) with work experience in things like scientific computing, ray tracing/wave propagation simulation, tomography type of analysis - using C++/C# and GPUs (CUDA/OptiX e.g). in Ohio? (My first guess for this would be to look at former students from the mechanical or biomedical departments at the local Universities, but the feedback I have had so far on that is that the top students from UC and OU typically get recruited quickly and relocate...and that perhaps this would better fit someone with a computer science background...) The work involves data acquisition, signal analysis and motion control which are things LabVIEW-developers often have experience with, and hearing about this recruitment challenge I first thought about JKI e.g., but the company in question wants to recruit someone to work in-house, be located in Cincinnati (no relocation package)...and implement some heavy lifting using CUDA/OptiX or similar, so it is not a LabVIEW or consultancy job. Any tips (apart from hiring a local recruitment firm...), or someone who knows any suitable candidates (again - US citizens only)?

The first thing is that you should make sure your VI's diagram and front panels fit a normal screen size and that front panels show up at the center. That way you can collaborate with people with such screens easier, and force yourself to modularize (all that code copied everywhere; make subVIs of it and reuse them(!)) and keep the code tidy. Right now when I open the thing it is huge and off screen, even though my resolution is 2560*1600. This, and the messy non-modularized code will scare off most people from trying to help you as it becomes an unnecessary hassle from the start (dealing with such things instead of an actual logical puzzle is too boring 😉 ). Without an example of the issue you are describing (how does the output file look compared to what you expected e.g.?) and looking at the messy code this first reply now will focus on the style and structure of the code rather than the flagged issue: All the repeated data fetching code e.g. could be reduced to generate an array of fetch parameters and a single for-loop that generates the fetch commands and fetches the data - and outputs an array of the results. If there is a fetch command that avoid having to fetch one parameter at a time I would use that instead as well to eliminate the overhead of each request, otherwise it may sum up and limit your fetch rate....Even better; use a fecth that returns the histroy of multiple items instead of fetching one sample of one item at a time....(I do not know if the API offers this though). Timing-wise you have everything in one huge loop and there is nothing to ensure that it actually runs at the given rate (If you want a loop to run once a second e.g. you have to make sure the code inside it does not take more time to execute and at a minimum you should replace the wait function with a Wait Until Next ms Multiple. Split the code into separate loops and/or VIs that run in parallell instead, making sure each diagram or at least each loop is small enough to be seen on a normal display, allowing the user to get an overview at least vertically, some horisontal scrolling to follow the data flow might sometimes be OK. There are a lot of designs patterns that might be suitable for your code (Producer-Consumer, QMH etc) , but just separating the DAQ (REST Client) bit from the user interface handling e.g. is a good start) I would just skip the signal functions all together. Take the array of values you have fetched and convert it to a spreadsheet string (CSV format e.g.) with a time stamp added to each row and write that to a text file. If you really want to sample multiple times per second you might want to look at circular buffers and only write every now and then. At the level you are now just using the in-built buffers of the charts you already are using might be easier though. Have a look at some of the logging examples included with LabVIEW or available at ni.com to see how those structure the logic.

Generate a worst case list and update it at the (truly) necessary rate, with panel updates deferred while you are doing your required changes (if more than one property change is needed). If it runs fine, you saved yourself a premature optimization...If it does not look good, reevaluate if the update rate and list size is really required...

I had a brief look at the code when you first posted it and thought perhaps it could benefit by working more on U8 arrays directly instead of the boolean arrays, but sticking to U8 all the way would not be practical either, so after some minor test runs I left that trail... PS: One thing I did find was that the imgs folder is placed incorrectly in relation to the Example, making the default path to image incorrect. 🕵️‍♂️ The benchmark code, if it is going to be included in the release, might also look more logical if it was timing the individual steganography sub-components but with the contribution from other functions currently so small (relative to the current encode/decode functions at least) it has not much to say in practice.

That would be great. Linux RT support is all we need these days. I have not seen any VxWorks targets in ages.

We use 4.2.0b1-1 still (latest with Linux RT support I think) because of a requirement for RT-support, but I noticed today (surprised I have not notived earlier...) that if I try to edit anything in the produced zip files Windows will report that the archive is corrupt. I can still extract files from it with Windows, but trying to add a file e.g. will fail. Up until now we have always handled both compression and decompression with OpenG itself anyway, so the inability to modify it later in Windows was not an issue...until now. Is this a known issue with 4.2b and/or is there a way around it / fix?

Maybe this should be suggested in the idea exchange at ni: When working on RT we should be able to specify where VIs/LLBs/LVLIBs/Config files etc belong on the target in its properties or somewhere else, and whenever you run anyhting in the project in the development environment the system would automatically check and ensure that those sources were compiled and deployed to that location automatically (if not already there in their current form). This would replace the need to manually build and deploy an application to get the support items in place...(reminds me of this idea by the way; build and deploy in one go...)

They have to be compiled for the target yes, but you just include them in the application build and configure that to save them where they should be...I often just deploy the executable, then continue to work on the other VIs. If they are run from the development environment they still find the compiled dynamic VIs. It is not ideal, but not that big of a hassle.

If you start the VIs manually y clicking on the run-button you are really just launching VIs in memory from the host machine, not sourcing them from the file path. Have you deployed these VIs to the correct folders on the cRIO target so that the code will actually find them there (what error code doe sthe asyncronous call give?)? The atached project was not a real-time project so what the real-time application build pushed to the target is unclear...Once the files are where they are supposed to the launch will not be shown as they will run on the target with no user interface (unlike a VI that is manually started from the host) so you should add code to verify that they are indeed launching (make them write a log f.eks)...

The first error code might be due to lack of privileges, try running NI max as admin...Or a full disk (try reformatting the cRIO first). As for ports to open if blocked https://forums.ni.com/t5/Real-Time-Measurement-and/Cannot-access-cRIO-behind-NAT-firewall-with-MAX/td-p/1868251

You should have used Grok...