All Activity

Anyone interested in QUIC? I have a working client (OpenSSL doesn't support server-side ATM but will later this year). I feel I need to clarify that when I say I have a working client, that's without HTTP3 (just the QUIC transport). That means the "Example SSL Data Client" and "Example SSL HTTP Client TCP" can use QUIC but things like "Example SSL HTTP Client GET" cannot (for now). If you are interested, then now's the time to put in your use-cases, must haves and nice-to-haves. I'm particularly interested in the use-cases as QUIC has the concept of multiplexed streams so may benefit from a complete API (similar to how the SSH API has channels) rather than just choosing between TLS/DTLS/QUIC as it now operates.

Not sure about 2011 to be honest, but no you do not have to have all dependencies included in a PPL. You can have a PPL depend on other PPLs and configure the build to exclude that dependency from you PPL build, so that it remains external. This has of course to be down from bottom up, which is quite a work. Only PPL dependencies and other binary dependencies can be excluded from being pulled into a PPL. So if you want code that has to be shared between your PPL and other PPLs or your exe, that code needs to be in its own PPL, so each of those can refer to it. Yes it is not trivial and you need to plan before you start programming. You need to have a clear hierarchy overview and be able to cleanly modularize your code into different PPLs. Tools like the MGI Solution Builder definitely help with that as you can script the creation of a whole hierarchy of PPLs to be compiled in the correct order. Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.

Hello everyone, Note: I have tried to post this on the NI Discussion Forums but it is "under review"... I am trying to get my FPGA program working. I have been able to get the first three modules working (at least not throwing an error when the FPGA starts I haven't actually tested data though put yet) but no matter what I do I can't get the 9213 to work except an empty example project. If I diagram disable the loop with the NI 9213 (Module 4) calls in it the FPGA will run with no errors. Here is the error I keep getting : Error -61017 occurred at Open FPGA VI Reference in NI 9213 Getting Started (Host)ud.vi Possible reason(s): LabVIEW FPGA: You must recompile the VI for the selected target. ========================= LabVIEW FPGA: You must recompile the VI for the selected target. Here is my setup: LabVIEW 2024 Q1 cRIO-9064 (Firmware: 24.0.04129, OS: NI Linux Real-Time ARMv7-A 4.14.146-rt67) Slot 1, NI 9203 Slot 2, NI 9265 Slot 3, NI 9474 Slot 4, NI 9213 As a test I used the NI 9213 Getting Started.lvproj from the example finder to verify that the module by it self would work. And it does. To make the example work with my system; * Create a copy of the example * Right click the Project name -> Add Target and Devices * Select Existing target or devices -> Discover an existing target(s) or devices(s) -> Real-Time CompactRIO -> Select my cRIO * Click OK * Select LabVIEW FPGA Interface * Click Continue * Click Discover * Copy the NI 9213 Getting Started (Host).vi from the sample cRIO to my cRIO * Copy the NI 9213 Getting Started (FPGA).vi from the sample cRIO/FPGA Target to my cRIO/FPGA Target * Create and Build a Build Specification for the NI 9213 Getting Started (FPGA).vi * Open the NI 9213 Getting Started (Host).vi and right click the Open FPGA VI Reference select Configure Open FPGA VI Reference * Select the Build Specification created above * Click OK * (optional) Add an probe on the Error wire between the Open FPGA VI Reference and the Reset (Invoke Method) * Click Run at the top Next I added a second loop in the NI 9213 Getting Started (FPGA).vi and added in the channels for the other modules. It will compile just fine but as soon as I try to run it it, the Open FPGA VI Reference throws the above error... again (See the NI 9213 Getting Started (FPGA) - w other modules.vi, The top loop is the added modules and the bottom loop is the untouched loop from the example) Next I disabled the new loop and recompile and it still throws the same error. You can see the diagram disable statement around the top loop. Next I deleted the new loop and recompile and it still throws the same error. (saved the NI 9213 Getting Started (FPGA).vi as a new vi so I could keep the previous one as a sample and created a new build specification) Next, in the project I disconnected from the cRIO, changed it's IP address to 0.0.0.0 and re-added my cRIO again (same steps above to add my cRIO to the sample project). This time I added the re-named NI 9213 Getting Started (FPGA).vi to my FPGA and recompiled again, and it works. So a few comments / observations, 1. In the attached vi, in the bottom loop, the case structure that is connected to the error wire, I can't use that in the top loop. I tried to reproduce this in my original project and I had to use Error State boolean from the unbundle by name in both loops. This seems odd to me. 2. I am not worried about the timing right now. The only thing I really want the FPGA for is to create a PWM output from one of the DO channels. If I can't figure this out by Monday I am going to try to switch to Mixed Mode and put everything except the DO module on the Scan interface. I have done similar things to this in the past but I can't figure this out. Any help would be appreciated. Thanks, Ryan NI 9213 Getting Started.zip

Hi, are there any toolkit or examples for OPC UA without using the official NI OPC UA Toolkit? I have a couple of applications using OPC UA and to avoid a 300€/y suscription licence I had to use python to communicate via OPC UA. I'm using LV2017 with no python functionalities so I developed a python service and used a simple text file to exchange data with labview, but now I'm looking for asomething faster than a consinuous file reading. Any ideas? thank you so much

Well, basically your program does never read anything from the serial port so your sending anything like *IDN? to it is totally superfluous and even wrong. As soon as it starts up it starts to spew a line of text every 500 ms, no matter if there is anyone listening or not. Basically, you want to startup your LabVIEW program - initialize the serial port with the correct parameters, leaving the Enable Termination character on as you now do - do one read of at least 100 bytes or more, possibly even multiple times to make sure the serial port input buffer is cleaned from any partial or old data - do NOT send anything to the device - then do a VISA Read with something like 100 bytes at least, every 500 ms, DO NOT USE Bytes at Serial port!!!!!!! You should see a string like "Temperature: <number> °C | Humidity: <number> % | Air Quality: <number>". The degree sign ° and the pipe symbol | might however pose a problem. No sure what locale your Arduino device uses, but it may not be the same as your Windows computer uses and then those characters will not match with what you expect.

My team and I didn't have any of those excuses back in 2012, we were running on Windows only, 'My Computer' target only, and were only dealing with LabVIEW 2011. We were probably guilty of starting coding without a clear enough understanding of how PPL work. We thought we could create a Plugin archiecture based on PPL to avoid having close to a hundred plugins built inside the executable. But this created a 2-way dependency that made this impossible. I later realized that every dependency of the PPL needed to be themselves in PPL, but this felt like a lot of work and we gave up!

This is the code i use! It works, but what i want is to take the data in the response and to separate and to put separate! sketch_mar23a.ino

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.😭