I'm away at a meeting, but I got a colleague to open this and save it for me in a lower LabVIEW Version, so I'll take a look at it and (I hope) get something useful to you early next week. I apologize for the delay, but I'll really try to be helpful ...
Bob Schor
Thanks a lot! I will check that out.
That could be the case, except each computer in the lab (about 8 or so) have their own dedicated myDAQ. Sometimes the USB ports are touchy and we have to unplug/plug back in the myDAQ when the computer doesn't recognize it as an input. Could this be what creates the second myDAQ profile in MAX?
I have a rather large application that is well established and has been in use for many years now. Recently after some minor updates to the application it is eating up memory during execution. The changes made didn't add any type of arrays, queues or things that would increase in size. As stated, the application has been in use for years without this issue. I have been reviewing all of the recent code changes and cannot find anything that should result in the application devouring memory. Unfortunately I cannot post any code due to intellectual property concerns as well as simply the size of the project.
The application is quite literally increasing by several hundred kilobytes every few seconds. I have tried disabling large blocks of code which include the recent updates but that does not seem to help. I have tried using the Execution Trace tool but that messes with the timing in the application. However, nothing really stood out in that tool. Tried the profiler but that reveal anything. I went back to a working released version of the code and now that is also exhibiting this strange memory issue.
Does anyone have any thoughts on I might be able to narrow down where the issue is coming from?
Did you switch LabVIEW versions at any time? Or did you change the way some code was called from static to dynamic?
I am wondering if there are some references being opened that are not being closed. And a wild stab in the dark is that maybe in one LabVIEW version they were being closed automatically and in another they were not.
Are you using a new version of LabVIEW?
@Mark_Yedinak wrote:I went back to a working released version of the code and now that is also exhibiting this strange memory issue.
Is this version compiled with the option "Allow future versions of LabVIEW to run this" or whatever the verbiage is?
I had an issue in the past with DAQmx, an update to the driver led to a memory issue that wasn't there before, then another update seemed to get rid of it.
Check if you also updated any other LabVIEW drivers, versions, etc. Newer versions of LabVIEW seem much more buggy to me, than in the recent past.
The code is currently running LV 2018. I also have LV 2023. This issue did appear to show up after I ran a repair which ended up updating stuff. I would like to avoid having to uninstall everything because I have several versions of LabVIEW installed and I need those multiple versions. The application does log the memory usage to a DB but for some reason the call to get the memory usage is not working in LabVIEW 2023 64-bit.
Just curious if anyone knows of a good custom dynamic probe for viewing class data?
Some of these are a real stretch, and if any of these are met I'd be interested, but here's what it'd do ideally:
- show class data, regardless of what class is actually on the wire
- show class data of classes that are in the probed class
- in the perfect world, handle classes in array, clusters, etc.
- allow debugging class data from PPLs (that I build)
- allow for easy (ok, useable) navigation of the data.
Annnyway...it's a long shot, but figured I'd ask!
If possible, I would try reverting the changes and see if the memory problem goes away, if it doesn't, then it may be the environment (i.e., software versions) instead of your application code.
please Help to convert from LabVIEW 24 to LabVIEW 22
Instead, post your request here.
The fact that running fhe old application exhibits the same problem clearly hints at an environment issue rather than something in your application code itself.
Things to consider:
- that old application is a compiled exe?
- it doesn’t have “use future runtime” enabled in the build options?
- are you using DAQmx or similar drivers? There only can be one version installed on a system, whatever is the newest you successfully installed.
- other third party drivers that may have gotten corrupted or upgraded?
- your memory monitor functions use what API? Third party .Net, LabVIEW application properties, NI system API?
質問です。
画像の16bit以上のBCG補正をLabViewで行いたいのですが、IMAQ BCG Lookupだと8bitに落とさないと行えない為困っております。
画質を落とさずにBCG補正を行うにはどのようにすればよいでしょうか。
お知恵を拝借したく、VIを添付していただければ幸いです。
やりたいこと
①16bitの画像のBCG補正(白黒)
②VI上で実行させたときに、元画像・変換画像を比べながら調整できる。
③LabView2017 SP1で使用可能であること。
よろしくお願いします。
@rolfk wrote:In LabVIEW this is simply a pointer sized integer, but that of course does not provide any security for a LabVIEW user to not pass a VkBuffer to a function that wants to see a VkImage! And crash, bumm! 💣
Basically the only way to make such an API LabVIEW safe is to do one of these:
1) wrap everything into LabVIEW classes. Those VkBuffers and VkImages etc. are in fact objects, no matter if the underlaying programming is in C or C++. So you would have to map them to according LabVIEW classes and keep the pointer sized integer a private data element of the class, never to be exposed in any way to the LabVIEW user. That way you can prevent the user from accidentally or willfully mistreat those pointers. These VIs can't be created by the Import Library Wizard, and writing your own variant of such a wizard that creates LabVIEW classes instead would be a major project in its own. Some of the functions the API exposes likely will use complex datatypes as parameter that are difficult to interface from LabVIEW since LabVIEW doesn't really know pointers on the diagram level. Traversing arrays of structures containing pointers in pure LabVIEW code, while not impossible is a true exercise in pointer voodoo far beyond what you would need to do when accessing that same structure in C. So you either end up writing a wrapper function in C anyways or start to play advanced C compiler on the LabVIEW diagram of those VIs.
2) LabVIEW knows a concept of user refnums, but it is not publicly documented. It requires creating a *.rc and according *.rch file that is placed in the <LabVIEW>\resource\objmgr directory and then a restart of LabVIEW. If the *.rc file does not contain any syntax errors, LabVIEW then knows one or more new refnum datatypes that can wrap a pointer sized integer and is type safe as far as LabVIEW is concerned. There are non-public LabVIEW nodes that can wrap the pointer into such a refnum and also deallocate it at the end just like other refnums. The entire thing is highly complex and not for the faint hearted, any errors anywhere in this can lead to very unexpected effects. So I can't recommend its use to anyone.
3) Write a wrapper library in C that exports more LabVIEW friendly APIs. Again you still would have to somehow protect the various object pointers in a way that a casual LabVIEW user is not easily able to mess up. This could be one of the above two options but considering the difficulties with 2) would for anybody but the most diehard nutcases mean to use LabVIEW classes again. 😁
And forget about the Import Library Wizard! It's a nice tool if your API is very simple but simply can't properly import complex APIs. If the API is simple, the effort to create the LabVIEW VIs to call the API functions through Call Library Nodes yourself is negligible anyways. If it is complex, you have to go through each and every function anyways, and carefully review and modify it to be correct and LabVIEW user friendly. This usually amounts to at least as much work as if you had created it all yourself from scratch anyways.
Basically, if you can't create the VIs yourself from scratch, you won't be able to review the wizard created VIs to be correct and use of such VIs in any application simply would be a major liability.
Here we are in late 2024 and the documentation search is still horrendously slow.
@joshdoe420 wrote:I don't have any concerns with OpenGL but it's in C++ so I'd rather write a native C++ application if I were to use it..
The LabVIEW 3D Picture Control is basically OpenGL, based on the MESA library. May not be hyper-optimized but a good starting point.
Bonjour je rencontre des difficultés à réaliser le TP ci-joint. J'ai besoin d'aide s'il vous plait c'est urgent
I looking for a way how to generate PDF report with multiple data (string, tables and image included) without opening the Word application or user ability to edit it.
Current solution is that Word will be generated from template and with RGToolkit I add data into it and save is as a PDF.
Problem is that even if I open RGT Word minimalized, the data operation took a while (15 sec data to table15x6 written individually by RGToolkit) and there is concern that user will be able to edit or close this document during the process.
Any ideas?
Thanks! 🙂
CloneA and cloneB are from the same git repo, (git clone https://repo cloneA, git clone https://repo cloneB) both cloned from the "main" branch, saved in the same local folder (that is not tracked with git). They're currently on "branchA" for cloneA and "main" for cloneB but that shouldn't have an impact since they're now two seperate entities.
no problem, thanks