Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by PJM_labview

  1. Thanks for all the answers While both type are identical (between no strict static vi ref and non strict generic vi ref) the behavior expressed while using either of these are not identical. For instance, doing a run vi method on the first one (static vi ref) with the auto dispose flag set to true will not dispose of the ref (makes sense to me) and doing the same thing on the later (generic vi ref obtain with the open vi ref) will dispose of the reference (again, this makes sense to me). In conclusion, knowing which type is "passed in" (a subvi) has some benefit that could be levera
  2. Hi Darren, I did look at the type string, but because both are non strict they are identical (see image). I also looked at the variant introspection vi for reference "Get Refnum Information.vi" but it return the "vi server generic type" as "kLVObjVI" for both (so no luck that way either). Thanks
  3. Does anyone knows if there is a way to programmatically differentiate between "static VI ref" and a "generic (non strict) VI ref"? After some digging up, I came to the conclusion that it is not possible but I would love to be wrong. Thanks
  4. LabVIEW 2020 I am seeing an inconsistent behavior with a public vim calling a dynamic dispatch protected member. The calls is not broken as long as no child is made or loaded into memory. Once a child has been made (and the override created) trying to reconnect the call to use the child brakes the wire (at that point I am unclear what is the desired behavior). call is not broken (but converted vim is broken with a scope error). Also, this code above just run fine (and the protected dynamic dispatch does as well). everything seem fine (but converted vi is
  5. Use case: The selection of the target VI will not be under my control so I have no knowledge about it ahead of time (so I cant do a CBR). I can detect other potential issue with the run VI method (ex: reserved for execution ) through the "Open VI" primitive but I can not detect lifetime related issues (shown in the example). I can script a wrapper (at edit time) around the target to do a static call (somewhat similar to what actor framework do with message class), but I would rather avoid doing this if I can help it as this introduce various complications.
  6. Yes. I thought about changing it, but since it does not make any difference, I left it. in Any case, I changed the example to show that. Note: Just to prevent more confusion, the error shows up immediately before clicking the stop button. Thanks rvm.zip
  7. Lifetime of VI launched by the "run VI method" are managed by LabVIEW (meaning the caller do not own the the lifetime). Practically, as soon as the target VI terminate LabVIEW will dispose of the resource created by the target resulting - among other thing - for every references created within the target scope to die (see attached example). I have a use case where this is undesirable and I would love to have the flexibility of the run VI method (generically address control on the target VI) while keeping ownership of the VI call chain in the launcher (like the CBR does). N
  8. Thank RolfK. I was actually hoping that you would chime in on that topic We were suspecting something around the lines of what you described (Virtual memory address not appropriate for the DMA transfer). We will move forward and find out how to lock the memory. Thanks again.
  9. Hi We have an application where we need to have a custom PCIe board transfer data to the PC using DMA. We are able to get this to work using NI-VISA Driver Wizard for PXI/PCI board. The recommended approach is to have VISA allocate memory on the host (PC) and have the PCIe board write to it (as seen below). While this approach works well, the memory allocated by VISA for this task is quite limited (~ around 1-2MB) and we would like to expand this to tens of MB. Note: The documentation (and help available on the web) regarding these advanced VISA function (for inst
  10. I have had to face the same issue in the past and I did not found a solution. It just occurred to me though, could you subpanel the background monitoring async VI into your probe and see if the subpaneled VI UI update (even though the probe is not)? I am not sure that this will work, but might be worth a quick try.
  11. Just closing the loop on this topic. Below is the screenshot of the fastest solution to date that does include the buffer allocation (array creation) as part of the code that is being bench marked. Thanks for everyone help. PJM
  12. I down-convert it to 2013 and 2011. Since that post yesterday, I got a slightly faster version that operate on each line (like you suggested) [see image below]. Also typecasting is not faster than split and interleave. This is an interesting suggestion. I will have to give this more thoughts. Thanks
  13. Hi Everyone. I am trying to figure out the most efficient way to manipulate somewhat large array of data (up to about 120 Megabyte) that I am currently getting from a FPGA. This data represent an image and it need to be manipulated before it can be displayed to the user. The data need to be unpacked from a U64 to I16 and some of it need to be chopped (essentially chop off 10% on each side of the image so if an image is 800 x 480 it becomes 640 x 480). I have tried several approaches and the image below show the one that is the quickest but there might be further optimization that could
  14. 1st oddity: The documentation specify the following: "Clusters and enumerations defined as type definitions or strict type definitions—LabVIEW uses the label of the type definition or strict type definition as the name of the .NET structure" In reality I find that to be incorrect. Instead it used the typedef instance name. Am I missing something? Note: I know I can rename it, but there are very good reason while I would love to have it worked as described in the documentation 2nd oddity: When a typdef is part of a class it does not show as such when call from a .net app.
  15. Not at all, thanks for doing that!
  16. Did not mean to record the background music with that, but enjoy! http://screencast.com/t/gfKwlvMcCsHI
  17. Ya, I use the built-in parser to do that too. I am not entirely sure by what you mean about putting the icon from the "monster" class into an empty class but my goal is not to have our developer do extra work in order to be using an internal tool that, among other thing, get library thumbnails.
  18. Thanks Darin this will be useful. I think that the data need to be un-escaped too because I see a bunch of text like & and so on. On a side note, I did an histogram of the data but I did miss the 64 bit pattern..
  19. Reviving that thread... I am wondering if anybody got more information about the escape (or encoding) mechanism. Nothing obvious (such as base64 for instance) comes to mind looking at it. I would love to be able to get (read) the class icon without loading the class in memory.
  20. Like you we have been experiencing this slowdown for years as we routinely have project using classes with 5k or more VIs. In respect to "fabric" comment about refactoring/restructuring your code, this may help but it is a sad reality when you have to dump a perfectly valid architecture for a another one simply because the LabVIEW IDE make it unusable. With 9K VIs I shudder thinking how long it will take applying a typedef changes given that in our framework this sometime can take a couple of minutes. Regarding solutions: The single most bang for the buck that we have found is to NOT use th
  21. Here is the MCL control again (since the previous links in the Thread are broken). Thanks special MCL.vi
  22. Pierre Thanks for reporting back your findings. That class that was giving you issues, was it doing anything out of the ordinary? Also, what do you mean exactly by "I regenerate the class"? Did you recreate if from scratch, mass compile it or something else? Thanks PJM
  23. Pierre, We do have a customer application with similar statistic (6000+ VIs but only around 100+ classes) and the build does take about 15 hours. Like you we have a lot of problems with the build (it is very easy to brake it for no obvious reason and when it take so long to do a rebuild this can very quickly eat weeks of your time). Here is some info that might help you. We notice that adding xcontrol can brake our build (ex: adding the 3dsurface plot xcontrol did that [took us 2 weeks to find that this was the issue]). Make sure your build output is as close as possible to the root folder
  24. Unfortunately I have seen this a lot as well. I think I saw this first around LabVIEW 8.0 (for sure I never saw this in LV 7.1 or earlier). I don't have a fix, but I have a work around that sometimes help get better number. Before your application run, start the "profiler" Click on the snapshot button a couple of time (<- this is the trick that do sometimes help) Start your app Hopefully this will be useful in your situation. PJM
  • Create New...

Important Information

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