All Activity
This stream auto-updates
- Past hour
-
[CR] 55 easily distinguishable color.vi
istvanferencz replied to Benoit's topic in Code Repository (Certified)
Dear Benoit, Is it possible to download this vi in LV 2015 format? Thanks in advance, Istvan -
istvanferencz joined the community
-
I was working with a PXI-8840 dual-core, so slightly different than OP's, but we were successful in replacing the RAM using off the shelf parts just this past week. The original 4GB stick it came with was this: https://www.crucial.com/memory/ddr3/ct51264bf160bj We just bought the exact same model*, with instead 8gb: https://www.crucial.com/memory/ddr3/ct102464bf160b There wasn't any issues installing it, or being recognized.
- Today
-
Hello, I have a complex application which calls a proprietary dll from another company. Recently, we have been having repeated crashes (silent, no error dialog except "Application Errors" in the Windows Event Log). As a test, I ran 5 copies of the application (using AllowMultipleInstances=True in the EXE's ini file). All four copies calling the dll crashed within a couple of seconds of each other (crashes happen only on hours/days timescale) while a fifth, not calling that dll, did not. I am confused as to how all the 4 copies failed at the same time. The dll just does a calculation (complex, but does not access anything external), so I do not understand how all the copies could fail at the same time (they were running independently on simulated random data). Anyone have a similar experience? All copies are presumably running in the same LabVIEW runtime engine; could there be any relation to the Runtime Engine?
-
Just checking in on the topic looming in the back of my mind every time NI Week occurs (although it is delayed this year). When will LabVIEW NXG have feature parity to LabVIEW 20xx? When will we be forced to move to NXG for new features? As can be seen from the LabVIEW NXG Roadmap, it appears it is at least 3 releases away. http://www.ni.com/pdf/products/us/labview-roadmap.pdf Assuming an annual release cadence, that would mean 2023. Is there any roadmap for the last release of LabVIEW classic (aka 20xx)?
-
Matteo Mastellaro joined the community
-
TKiouimet joined the community
-
Ubik joined the community
-
Aurelien Guery joined the community
-
Add menu to LabVIEW Options Window
Nicolas Bats replied to Nicolas Bats's topic in Development Environment (IDE)
It seems there is no solution but it exists a workaround. NI Forum -
gavinlaw joined the community
-
Максим Кравцов changed their profile photo
-
Jeffrey Thomas changed their profile photo
-
Setting the key focus on an array control programatically
Aristos Queue replied to John Lokanis's topic in User Interface
Benoit: I just saw this post while hunting around for a bit of help myself. I looked at your VI. It's not a bug. You aren't ever setting the active element of the array -- the same physical position remains active unless you click with the mouse or use TAB key to move to the next element. To the best of my knowledge, there is no programmatic way to set the active physical slot of the array control other than simulating a mouse click or something exotic like that. The array control is not a particularly good control for UI, in case you hadn't noticed. It was never designed for a interactive front panel. The one in NXG is better. - Yesterday
-
rdm joined the community
-
Hello, i created a new tips repository in: https://edupez.com/ English and Portuguese
-
David Pokhsraryan joined the community
- Last week
-
I recently did a code review with @Jim Kring about upcoming Caraya 1.0 (yeah, I know, I'm using the opportunity to plug Caraya... shame on me), and when I showed him this block diagram, his eyes immediately caught the top comment I placed on the block diagram. It took him less than two seconds to say something like: "You have to put that on the Idea Exchange." (Jim, let me know if I'm misquoting you) Indeed, the Block Diagram... erm... the Mother of All Diagrams... does not have a Subdiagram label property. I say this is a grave injustice. So anyhow, I wanted to share the paternity of this idea because without his enthusiasm, it would not be there: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Subdiagram-label-for-Block-Diagrams-too/idi-p/4033465 If you like it, please vote!
-
You are welcome Neil.
-
Ramon Hammerschmidt changed their profile photo
-
Aniket, thank you for posting this and congrats on starting your journey with lavag 🙂
-
Thank you for your kind attention & valuable time. I checked this functionality, In this you are using Queued message handler to request for read/write. I thing it will increase latency to read/write variable if there are many request. We never know how many times developer will call read/write operation. So instead, I obtained reference directly without any message request. And VI Register uses implementation similar to FGV, which i tried to avoid. This toolkit strictly not used for Read-Modify-Write operations, Since each feature can have pros-cons. Again, Thank you for your time. Please let me know if you have any improvement suggestions.
-
Thank you for your attention & time. I think using variant data type you can read/write any data type. Also, Most of the users are still using LV2015 so i kept this code in 2018. I tried to avoid FGV in this feature/toolkit due to some limitation of it. If you wanted to load/read variables from file you can develop that logic outside. I think obtaining queue/notifier reference, set value & close reference for 100 times is much cheaper than calling FGV 100 times. I saw your "Variant Repository" and it was nice, But each time you have to connect wire and pass data in subVI's, to perform read/write operation. Where as in my toolkit you don't have to at all. Again, this feature can store large data also and can be accessed by Named reference. Please let me know if you have any suggestions.
-
Hi, I wanted to share this tool also on LAVA. This above mentioned post is posted by me.
-
Reusable Events Between Parent and Child Classes
GregFreeman replied to GregFreeman's topic in Object-Oriented Programming
Sounds good. I have decided to just register for the events scoped to the parent, in the childrens' event structures. It does result in some duplicate event handling code between children, which I'd like to live in the parent, but it's not really that big a deal. I may refactor to use something more like the actor framework for this class, but I think with the minimal number of events I don't get a whole lot of lift from refactoring -
Hello, Recently i started working on NI DSC module and exploring how to make use of different concepts related to DSC. for eg. Connecting different devices mostly PLC based systems (having OPC I/O server driver support in HW), then reading and writing data PLC I/Os using LabVIEW I/O server mechanism, reading Alarms and events, Processes, Creating tags etc. Well, I want design typical application in LabVIEW using DSC module which has following implementation. for eg. 1. Adding or Removing new PLC or Devices. 2. Once the PLC is connected, Adding tags using I/O server lvlib. deploying it programatically. (Which we can do using Process deploy/undeploy VIs in DSC). I have seen the given LV example. 3. Raising Alarms or Events for a shared variable, monitoring complete process, logging data, Taking user action againt abnormal condition related to hardware. 4. HMI Front panel design in labVIEW. etc So far, i have tried all the given examples in NI example finder in LabVIEW. That gave an idea on using different concepts. -
Need way in G to get monitor size minus taskbar, OS independent
LogMAN replied to Aristos Queue's topic in User Interface
I don't know of a way to do this OS independent. Here is a VI that gets the monitor and workspace area for any monitor, given a screen coordinate. Of course, this only works on Windows. Workspace.vi -
So I took a quick peek, nothing too detailed, but from what I saw there is pretty much no way this is unequivocally faster than the CVT or the tag bus. With the CVT it might be possible this approach is faster if you give it the worst possible load (10000000 simultaneous readers, each of which is reading a random, constantly changing name), but in any sane case you'd lookup a reference beforehand and then write to those, and the write time is bounded at basically the same performance as any reference-based data access. For tag bus...its literally just a cluster with an obscene number of different data types in big arrays. Data access is just indexing an array. There is no way in labview for data access to be faster than indexing an array. In contrast you are obtaining a queue by name which involves several locks, doing a lookup, and writing to the queue which requires another lock. The CVT only needs 1 lock and tag bus requires zero. Memory I'll give you. Its also worth you looking at this:
-
Need way in G to get monitor size minus taskbar, OS independent
The Q replied to Aristos Queue's topic in User Interface
I guess you could do your trick of maximizing momentarily with the transparency at 99% transparent. Open the VI Hidden, change the transparency, maximize, get VI panel size, change back to standard, set size and transparency. -
Does anyone have a picture showing how, given a VI, I can get ... ... the size of the monitor hosting that VI's panel... ... minus the taskbar size (if any) on that monitor... ... in a platform (OS) independent manner? I had a clean-but-annoying way to do this until I discovered that Windows10 has a mode that lets the task bar be replicated onto different monitors (and, worse, those taskbars aren't necessarily the same size). The only trick I can come up with is to maximize the panel momentarily and grab the panel size at that moment, but that creates flicker in the UI. Yes, I am aware of these two properties: They do not suffice. The first one gives all the monitor sizes without accounting for taskbar. The second one only reports taskbar on primary monitor. If I could be sure the taskbar was only ever on the primary monitor, I can figure it out from this info, but discovering taskbars on multiple monitors was an option throws a wrench in that plan.
-
Thanks for your contribution. A couple of things. Using polymorphics for this type of thing can become a pain pretty quickly. I had a similar thing for reading and writing variant attributes and used scripting to generate the 60+ data types I supported. But even then there were times that the data type wasn't supported. This also added 120+ extra VIs (read/write) adding to loading overhead. The more modern way of doing this is with a VIM that adapts to the data type provided. Your VIs were saved in 2015 when VIMs weren't an official thing, but you say you use 2018 where it is. Back then I'd still support doing this data type adaption with XNodes. Posted here is my Variant Repository which does similar read/write anything including type def'd enums and clusters. Putting these in a global space that any VI can read and write from is pretty trivial. All that is needed is a VIG, functional global variable, or even global variable in a pinch. This will keep data in memory as long as the VI is still in memory and reserved to be ran. This has other benefits of easily being able to load and save data from a file since it is all contained in a single place. Also with this technique there are no references being opened or closed, so no memory leaking concerns. Performance-wise I also suspect your method may have some room for improvement. If I am writing 10 variables 10 times, looking at your code that will mean 100 calls to the obtain notifier, 100 calls to the send, and 100 calls to the release notifier. I suspect reading a variant, and then calling the set attribute 100 times will likely take less time and processing power.
-
Cross post: https://forums.ni.com/t5/LabVIEW/Data-Variable-Toolkit/td-p/4032397
-
Nice simple find! Thanks for the tip.
-
Why RT or ARM targets? No, it's all quite simple. I've installed VIPM, it installed this drjdpowell SQLite Library, it seems that all work marvelous! Thanks again for this great library! I've tested two sqlite examples - they work without problem! The only inconvenience - the search in Example tab cannot find "sqlite", I've found examples in a directory search of Examples window.
-
Things are not that simple! LabVIEW on Linux RT comes in two flavors. For the ARM based targets and the x86 based targets. The 64-bit Fedora/Centos/Redhat binaries MIGHT work for the x86 based targets, but in my work with these I always compiled shared libraries from the source for these targets. For the ARM based targets you will almost certainly need to recompile them from source. Just because it says ARM does by far not mean that it is all the same although many of the SmartTV and similar hardware are probably running on some ARM CPU. The NI Linux RT used on the ARM targets needs binaries compiled specifically for the ARM CortexA implementation and should be compiled with softfp enabled. Otherwise floating point performance will be not very good. There are basically two ways to get a valid binary for the ARM cRIOs (works also for the x86_64 based cRIOs too): 1) Either cross compilation with a GNU C cross compiler that is prepared for the specific target such as explained here: http://www.ni.com/tutorial/14625/en/ 2) or installing the C development tools on your actual target using the opgk feeds from NI and compiling the sources there on the command line. This is however only for those who are not faint at heart and know about how configure, make, make install works. 😀 And you shouldn't be afraid to tweak the generated Makefile a little to fit your system exactly.
-
So I just discovered this, this morning and I think it will help out in making VIMs when dealing with supporting a scalar, or 1D array data type. I have an example which is my Filter 1D Array VIM, posted here, which is heavily inspired by OpenG's implementation. In it the developer can filter out a scalar, or a 1D array of something from a 1D array. I did this by adding a Type Specialized structure at the start which checks to see if after building the array, if the data type matched in the incoming array. If so it is a scalar and should be used. I then have another case where the data just goes straight through thinking it must already be a 1D array. But what I realized today is that is unnecessary. If in the VIM my input is set to a 1D array, and we add a build array with only 1 terminal, and that build array is set to Concatenate, then that whole structure isn't needed. A Scalar will become a 1D array with one element, and a 1D array will have no items added to it after the build array. In this example the code simplification isn't much, but someone may have had two cases in a type specialized structure which handle scalar and 1D array separately and using this they could be combined them into one. And one other minor thing, I don't think I will actually be updating the Filter 1D Array VIM to use this, just because knowing if the input is a scalar means other sorting work not shown can be ignored helping performance.
- 1 reply
-
- 4
-
