Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by dadreamer

  1. Well, seems like I had to say that LabVIEW also should behave as RTE does, but it does not for some obscure reason. So, my bad in phrasing there. It's not so easy to answer, not knowing how Vision internals work. I suppose, it has something to do with the way, how Vision's memory manager allocates memory. Perhaps it's more optimized to work in LabVIEW and less (or not) optimized for EXE's. I noticed that in IDE IMAQ Create takes nearly the same amount of time to run (0,03 to 0,06 ms), while in RTE that amount starts at 0,03 and raises on each iteration. Here are the shots to illustrate. I
  2. Same behaviour here on LabVIEW 2020 64-bit, but... Do you really need to create and store in memory 10 000 images at once? I'm even not surprised, that both LabVIEW and RTE go crazy trying to do that. When I take IMAQ Create out of the loops, the situation improves significantly. IDE: 0,1 s for the extracts, 0,4 s for the thresholding EXE: 0,2 s for the extracts, 0,4 s for the thresholding Of course, there's no any reason to divide the whole processing into two separate loops in this case (because you would get the same image slice on all 10 000 iterations.
  3. I believe it appears to be SQL Toolkit for G, that was superseded by SQL Compatibility VIs from Database Connectivity Toolset, which is named as LabVIEW Database Connectivity toolkit these days. I'm sure, you even could try to replace some of your obsolete VIs to their counterparts from \vi.lib\addons\_SQL directory, if you install Database Connectivity toolkit. As to where you could download that old SQL Toolkit, I'm at a loss to suggest as it was obsoleted a long time ago (LabVIEW 5.0 or so), thus likely no any alive links to download that now.
  4. Maybe you could figure out more information, when you add these lines to your labview.ini: You need to restart LabVIEW after that. When started, it will create DPrintf text file near labview.exe with a tons of a technical information. That info is often very low-level and internal to LabVIEW development, so it may be difficult to analyze. But it's something at least.
  5. How to get a list of image buffers? When I need some piece of code to run in a few instances simultaneously, I just set unique image names based on the meaning/purpose, what that code is invoked for (e.g., "sensor 1 - binarization" or "scanner - edge locator" and sort of). No extra magic here. And I even don't dispose the rest of images, as they are always reused on subsequent runs of the program (and between loop iterations too). Although I never launched too many IMAQ code in parallel (max. 5 threads, I think).
  6. It's difficult for me to figure out the reasons behind your situation as I don't have your application and cannot do some tests with it. To me it looks like you don't have all the necessary dependencies extracted, thus LabVIEW fails to open the VI (assuming that you've done every step from the instruction properly). Are you receiving the same message when placing that VI onto the BD of a brand new VI? Well, I spent some time searching for ways to extract project library files (.lvlib, .xctl, .lvclass) and seems I found one. You might try to complete your file list by doing the following s
  7. You may easily overcome this with the following modification. But you also will need all .xctl and .lvclass' files (that are plain XML after all) from the exe, otherwise your linked VIs won't open properly. Sadly I don't know the way to pull out such files from a LEIF, because App.ExportedVIs property does not return them. I'm not saying now, that you have to recreate .xctl/.lvclass from a scratch, as they are actually stored inside the exe. But the way to extract them is yet to be found.
  8. To extract the VIs out of LEIF section (produced by Fast File Format option) you may try my instruction above. Depending on the number of the VIs in your executable and their hierarchy it may be not that easy, but it's definitely doable at least.
  9. I confirm that in LabVIEW 2020 (both 32- and 64-bit) on Windows. 32-bit LabVIEW dies silently in case of the error, whereas 64-bit LabVIEW shows the following report.
  10. I'm not completely sure (as I never saw that myself), but you likely have encountered a bug with Event Structure names messed up, described here. So you might try what's suggested there - do a total uninstall (including msi...Blast running after all) and then a fresh install including all the service packs and hot fixes. It may solve that issue or may not. If not, then obviously you have to upgrade LabVIEW or alternatively you may figure out, what's your "Mouse Down" even is really named by going through the event names one by one and checking, whether it works when clicking on a pane. There s
  11. I mostly agree with Rolf here. Even though it looks definitely doable, if necessary effort is pushed into, it will require a lot of work for sure, be it Import Shared Library Wizard enhancement or some new tools, based on scripting. At the current stage, I do not even believe that someone will do this in relation to LabVIEW, until it would be done for any other widespread programming languages at least. Besides of that, I suppose, some rework of the current Call Library Function Node is required, as it wasn't really maintained in many years and doesn't allow some use-cases to be automated. For
  12. I have used PostLVUserEvent Manager function for a few times in my own callback libraries to send the video/image data from the framegrabber into LabVIEW. It was always working fine for me. I'm sure, back in the days I have used this code sample as the base for interaction with a callback DLL. On Linux you may use dlopen (instead of LoadLibrary) and dlsym (instead of GetProcAddress) from \usr\lib\x86_64-linux-gnu\libdl.so to pass your callback into the vendor's API.
  13. Finally here it is. Refnum_to_Pointer-Linux.zip Refnum_to_Pointer-MacOS.zip Tested in LV 2020 on Ubuntu 20.10 and macOS Big Sur. It's assumed to work in 64-bit editions of LabVIEW only.
  14. Maybe it's not what you are looking into, but did you consider using VI Tags to store, read and write the data? It's contained inside a VI in a dedicated resource section, so it will be inside an EXE after the building as well. It has one disadvantage though - you can't use OS tools to view and edit the data directly, but have to use LabVIEW/RTE to do that. If you're fine with it, then try to give it a go. https://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/generic_m/ https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-13-2009/m-p/888538?profile.language=en
  15. I just hardly understand, how new features of NXG could be integrated into classic LabVIEW editions, given that a classic is written on C/C++, whereas NXG is made on C# mostly. It's also worth mentioning, that some code pieces of classic LabVIEW were not updated for decades, so it would take years literally to rework them and reimplement some NXG possibilities (as zooming, Unicode support etc).
  16. Might it be that LabWindows/CVI RTE should also be installed on a clean machine? DLL dependencies utility shows, that QCMM2000.DLL depends on cvirte.dll. I'm not sure, where you could download 4.0.1 RTE for LabWindows, it's not available on NI.com. Maybe try to request it from the vendor?..
  17. Definitely yes. I have done this many times for simple applications a la "Calculator" and it does work. Although for modern LV versions (starting from LV 2018 as I can remember) it has become more complicated, because universal CRT is used, that requires Microsoft Visual C++ 2015 Redistributable to be installed or a whole bunch of DLLs should be placed near the exe instead.
  18. When I found a way to obtain the object's pointer given its refnum, I remembered my old and currently declined idea on NI Forums - Ability To Get .NET/ActiveX Window Handle By Its Automation Refnum. The solution proposed there is not good for many reasons, so I decided to see, whether I could pull out a HWND of NI Container Clipping Window from LabVIEW's internals using the object's pointer only. After some experiments I have succeded! So, now it's clear that LabVIEW retains that HWND in the memory to be able to do some manipulations with the window (like resizing / moving etc.). Okay, he
  19. Did you know that this option shows "Autopreallocate arrays and strings" checkbox on VI Properties -> Execution tab? Here's the excerpt from the LabVIEW Help about this setting.
  20. Nice catch, Rolf! It works and I am able to pass the input/output parameters now. RunVI.vi SubVI.vi But it appears that CallInstrument wants to be ran in UI Thread only, else LabVIEW goes big crash. It calls the VI synchronously, waiting until it finishes. That makes me think that this function is not the best idea to use as a callback, because when the user will be interacting with some GUI elements or the program will be running some property/invoke nodes, the callback VI will be waiting UI Thread to become idle, thus we could experience the delay between the events from
  21. I have not, but I just tried and saw no difference in passing strings into CLFN (no matter, if variable, bounded or fixed length). I think, it could be some archaic setting for early LVs before 2009. It even doesn't cause a VI to be recompiled unlike "Type Only Argument" option. It just adds 0x40000 to the flags field in the terminal's DCO properties. Having played with that flags field a little, I can conclude, that it affects IDE behaviour and the terminal look only (to accept some wire(s) or not), but has nothing to do with the compiled code execution. For example, with value of
  22. I'm afraid, we can't use them, because they don't actually run a VI, but "prepare" its state for a run. I guess it's used only for LabVIEW Adapters to be called later from TestStand. VIRefPrepNativeCall requires a VI to be in reserved state, otherwise it returns 1027 error. If we mark the VI as reserved with StatVIRefReserve, then it all goes OK, but the target VI is not executed. Something like this: int32_t StatVIRefReserve(uintptr_t viDS, uint32_t *pVIRef, int32_t unknown, int32_t setUnset); int32_t VIRefPrepNativeCall(uint32_t viRef, uintptr_t *pVIDS); int32_t VIRefFinishNati
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.