All Activity

There are several alternatives for the NI GPU Toolkit that are considerably more up to date and actually still maintained. https://www.ngene.co/gpu-toolkit-for-labview https://www.g2cpu.com/

Definitely can echo things. PPLs work fairly well when you only use one platform (Windows x86 and x64 are two different platforms in that respect). Basically a PPL is quite similar like a DLL in that respect, it is binary compiled code and only works in the LabVIEW platform that it was created in. In addition you also have to watch out about LabVIEW versions, although with the feature to make a PPL loadable in a newer LabVIEW version since about 2017 or so, this is slightly less of a problem, but not entirely. There are possible issues with executing a PPL in a newer LabVIEW version than in what it was created. Where things really get wonky is if you want to support multiple platforms in LabVIEW. Different platform versions of PPLs in the same project is absolutely out of questions. You can't have a project that references a PPL under your My Computer target and the same PPL in a Realtime target in that project (same in name only, they obviously need to have been recompiled for each target). LabVIEW will get into a rats about that and render both targets as broken since it will try to match the two incompatible PPLs to both targets. But it is even worse than that! Even if you separate the two targets into their own projects you have to be extremely careful to never load both at the same time. For some reason the context isolation between LabVIEW targets (including targets in different project files that should be fully isolated in theory) simply doesn't work for PPLs. It seems that LabVIEW only maintains one global list of loaded PPLs across all possible contexts and that of course messes royally with the system. Instead PPLs should be managed based on the context they are referenced in and there should be no sharing at all between them. There is also an unfinished feature in LabVIEW that allows to install PPLs and other support files in target specific sub directories, so that you could theoretically have PPLs for all the different targets on disk and reference them with the same symbolic path which then resolves to the target specific PPL. But it has many bugs and doesn't quite work as intended on some platforms and as long as PPLs are not managed on a context base it is also of limited usefulness even if it would fully work.

Thank you for the note regarding the compiler and the need to "use" all the outputs. I know it but forget when writing this specific vi. Regarding the GPU toolkit: it's the one I read in the past. In the """""documentation"""", NI writes: https://www.ni.com/docs/en-US/bundle/labview-gpu-analysis-toolkit-api-ref/page/lvgpu/lvgpu.html And, for example, I found the following topic on NI forum: https://forums.ni.com/t5/GPU-Computing/Need-Help-on-Customizing-GPU-Computing-Using-the-LabVIEW-GPU/td-p/3395649 where it looks like the custom dll for the specific operations needed is required.

Thank you very much for the tool provided by the author, it is very practical, but there are some problems with this tool. When I install this tool, the attribute accessor of LabVIEW class object created by LabVIEW class tool will produce an error, this tool will cause class object error in class accessor vi generated by LabVIEW. The type of the class object in class accessor vi is changed to DNL object. I am not clear about the specific cause of the error. If the author sees this reply, please check your program.

It's just a cosmetic token to get "Run At Any Loop" option visible in the IDE mode. After the flag is set, it's sticky to VIs, on which it was activated. No need to add the token to the EXE's settings.

Does this token need to be added to the INI file of a compiled exe or does it automatically get included?

Yeah multiple targets is the main issue I've had over the years. I have a great reuse library that is written well to work on RT or Windows. But making a single PPL for both targets is impossible. And having the palettes, and builds, and projects pull from the right PPL, and pull the other dependent PPLs, is such a major pain that I abandoned it.

I have been using PPLs in my architecture for many years with very little issues. But I am generally using them in Windows only and the PPLs are pretty small. I use the LabVIEW Solution Builder to build my core libraries. I will also state that NI is actively working on the PPL build process behind the scenes.

And if possible, at each write operation write the same channels, this will prevent the creation of a new segment, as Hooovahh hinted.

You mean you're overlapping the subpanel and the tabcontrol on purpose? This is usually seen as a bad practice. That being said, this is a interesting "bug", I had not seen it before.

There is a section for job postings further down the main page. Please move your post if you can. Thanks!

Can you explain what you mean by "key" in this context? Maybe you can post a little screenshot of the code you have so far?

5 years later... Have things happened in the recent years with PPLs that would remove some of the reasons people may have abandonned them in the past? I was one of those people back in 2012, I'm thinking that 12 years later I could give them a try again...

Hi all,I'm new here I have 1 element in combox box in GUI and it has a key which is written in INI file and read to cluster. Now , I need to add another element to combo box and read it to cluster. So technically it comes under same key. Idk how to programmatically code it in LabVIEW. Can anyone please help.

The data in the sub-panel is always at the very top level when refreshed, I don't want that, what should I do? The picture below is a screenshot of me.

Thank you for your continued help and advice. I'll think about it myself and learn to implement it on FPGA. Thanks!🙂

Option 1: Find your 2 nearest W points (minimum Euclidian distance) Find where on the line between those two W points that's perpendicular to your unknown point Use 1D interpolation between the two W points to estimate the W point's value. Option 2: Because W1,W2, and W3 are not colinear, you can define a surface between them. The approach would be somewhat similar to the above: Find the 3 nearest points and use them to define a surface. Find the cross product of the two vectors give you a normal to the surface Find the cross product of the normal and your unknown point. That should give the point on the surface that corresponds to your unknown point. Based on what you drew (your points were nearly colinear), I expect the second method to be very sensitive to noise and thus somewhat unstable and inferior to method 1.

I think I know what I need, but I can't seem to describe it accurately. I'm sorry.😭

Frankly, It seems more that you don't know what you want, than that you don't know how to do it on a FPGA.

I know about bilinear interpolation. But I don't know how to do it with my lack of data points. The hollow points in the graph are known points and the solid points are the points to be interpolated, （Hollow points don't have some kind of linear relationship） I don't know how to use bilinear interpolation. I am not able to find 4 known points.

Yes, I think that should work fine for positive numbers. It's probably less efficient than my method though.

It's the same as 1D interpolation except you repeat it a few times. So, if you have data at 0,0 0,1 1,0 and at 1,1 and you wanted to get (0.7,0.3), you could start with finding the values at 0.7,0 0.7,1 and then interpolate between those two values. https://en.wikipedia.org/wiki/Bilinear_interpolation (see repeated linear interpolation)

There is a GPU Toolkit if you want to try it. No need to write wrapper DLL's. It's in VIPM so you can just install it and try. Don't bother with the download button on the website-it's just a launch link for VIPM and you'd have to log in. One afterthought. When benchmarking you must never leave outputs unwired (like the 2d arrays in your benchmark). LabVIEW will know that the data isn't used anywhere and optimise to give different results than when in production. So you should at least do something like this: On my machine your original executed in ~10ms. With the above it was ~30ms.

Breathe BioMedical is looking to hire a LabVIEW Developer. Breathe BioMedical (BBM) is a medical technology company focused on developing an accurate breath test to detect early-stage breast cancer in women with dense breast tissue. If you are interested in the opportunity to design, develop, test, and document software necessary for the operation of our company’s medical device products and internal software applications, then this might be the role for you! Learn more about this job opportunity and how to apply at: https://breathebiomedical.com/join-our-team/

Thanks for trying! How "easy" is to use GPUs in LabVIEW for this type of operations? I remeber reading that I'm supposed to write the code in C++, where the CUDA api is used, compile the dll and than use the labview toolkit to call the dll. Unfortunally, I have zero knowlodge in basically all these step.