Jump to content

All Activity

This stream auto-updates

  1. Today
  2. Rolf Kalbermatter
    The straight-jacket should take care about shooting in your own feet, or actually shooting at all. 😁
  3. Michael Aivaliotis
    Thanks for raising your concerns. I'm aware of the problem. The root cause I believe is the forums framework itself. It has many safeguards, but it seems that the spammers are always one step ahead. There are still more avenues I can explore, so I haven't given up.
  4. ShaunR
    You actually have 2 levels with LLB's (semanticly) and that's more than enough for me. I also don't agree with all the private stuff. Protected should be the minimal resolution so people can override if they want to but still be able to modify everything without hacking the base. This only really makes sense in non-LabVIEW languages though so protected might as well be private in LabVIEW. And don't get me started with all that guff on "Friends" But in terms of containers, external users can call what they like as far as I'm concerned but just know only the published API is supported. So making stuff private is a non-issue to me. If I'm feeing generous and want them to call stuff then I make it a Top Level vi in the LLB. Everything else is support stuff for the top level VI's so call it at your peril. I still maintain PPL's are just LLB's wearing straight-jackets and foot-shooting holsters.
  5. str
    str joined the community
  6. Rolf Kalbermatter
    Well, except that LLBs only have one hierarchy level and no possibility to make VIs private for external users. I do feel strongly about packed libraries being a potentially good idea with many limitations that I think were not fully thought out. - Version resource to have some control what version a packed library is? Tacked on by wrapping the proprietary archive format into a PE file and storing it as a custom resource in the PE file. And of course only under Windows, sorry Linux and Linux RT users, we forgot about you. - And the project environment is terrible in supporting them, as LabVIEW does not isolate packed libraries into their own application context. A PPL loaded into one application context, contaminates the entire LabVIEW memory space with its symbols and trying to load the same PPL but compiled for a different architecture into a different application context (RT target for instance) just messes up your project and sometimes beyond repair. And this is even so insane that if you load two projects separately at the same time with the same PPL with different architecture, you just managed to mess up both projects equally! Why does (almost) everything properly observe application context isolation except PPLs?
  7. ShaunR
    *prerequisite. Packed libraries are another feature that doesn't really solve any problems that you couldn't do with LLB's. At best it is a whole new library type to solve a minor source code control problem.
  8. weiyanshuo
    weiyanshuo joined the community
  9. Last week
  10. DreamSS
    DreamSS joined the community
  11. dasdawsdawdqwa
    dasdawsdawdqwa joined the community
  12. ciozi137
    @drjdpowell I’ve tried to reproduce the error with the DVR but so far unsuccessful. when you have a chance can you review or comment latest pull request? Targets mostly libpq install, threading, etc. thanks
  13. zCyRIL
    zCyRIL joined the community
  14. Rolf Kalbermatter
    I didn't say they are a poor mans class, just that they are similar in several ways. 😁 The entire low level mechanics underneath are very similar, the interface provided to the user is somewhat different. Classes can have private data, libraries not. Libraries are the pre-request to creating packed libraries, or as you found out to use the 3rd party Activation Toolkit. They both have their use cases that are distinct from each other.
  15. ShaunR
    There isn't anything really special about lvlibs. They are basically containers with a couple of bells and whistles. If you look at them with a text editor you will see it's basically a list of VI's in an XML format. The main reason I use them is that they can be protected with the NI 3rd Party Activation Toolkit. A secondary reason I use them is for organisation and partitioning. It would be frowned upon by many but I use lvlibs for the ability to add virtual directories and self populating directories for organisation and contain the actual VI's in llb's for ease of distribution. I don't see them as a poor-mans class, rather a llb with project-like features.
  16. Mike Vinyard
    Mike Vinyard joined the community
  17. ensegre
    This is the situation in 14 and 19 here. In 14 Wire has some interesting properties in 14, but not Value. Note that e.g. Attach Probe is accessed as a property in 14 and a Method in 19; and BD is an array of integers in 14.
  18. Rolf Kalbermatter started following LabVIEW Libraries lvlib
  19. Rolf Kalbermatter
    Have you used LabVIEW classes? A LabVIEW Library is in many ways similar except that you do not have methods and properties but simply only functions (a sort of method) in them, and yes of course no private class data. You can set functions to be private, public or community. Obviously there is no protected type function.
  20. ManuBzh
    Yes, Diagram property exists, and as a reference, since at least 8.5, I've checked. Edit : and ... I put here a simple VI containing the following code. It's saved in LV2015 version, if someone can tell me with which version it won't be broken... Thanks ! value of wire classe reference.vi
  21. ensegre
    Rolf is correct, I forgot to enable scripting in the LV19 I used to check OTOH, in LV14 "Block diagram" is indeed present but is an array of I6 rather than a ref. I can't guess what was its intended use back then, maybe it was just an uncooked feature.
  22. Rolf Kalbermatter
    I can create it without problems in LabVIEW 2018 and 2020! So it is either that Scripting is not enabled in that LabVIEW installation or a bug in backsaving some of the scripting nodes to earlier LabVIEW versions. And I'm pretty sure that the Diagram property (called Block Diagram in the menu) is available since at least 2009 or thereabout. I can check this evening. My computer at work only has LabVIEW versions back to 2018 installed.
  23. skibidi
    skibidi joined the community
  24. ManuBzh
    Thank you ensegre ! Very strange that diagram property does not appear in LV2019/2021 ! it's the basis for scripting...
  25. smiga started following Image grab without IMAQdx
  26. ensegre
    Since you asked, here are my findings: LV23 - can create the attached snippet (don't know if it works), and save it for LV14 (also attached). All the pulldown menues show relevant properties LV21 and LV 19 - open the saved for LV14, show a correct image, but the first property node lacks the "Block Diagram" entry in the pulldown; further properties have no menu ETA - and show the relevant pulldown menues when "Show VI scripting" is checked. LV14 - the first property node menu *has* a "Block Diagram" entry, but the further properties don't match LV23 W14.vi W23.vi
  27. viSci
    Apologies for the bad example. GrokAI emphasized the importance of closing .net references which I blatently disregarded
  28. Zou
    You forgot to close .NET reference.
  29. ManuBzh
    And so the question is : is there different subVI refnum[] for each clone... I guess yes but note sure and can't figure how to reach them.
  30. ManuBzh
    Yes, I agree with this (That's what I saw after in the heap). There's only one diagram for all, but you can set breakpoints or probe on each instance "diagram",(it's only images ?) However, it would be enough for me to be able to do the same : programmaticvally put BP or read wires values on them. I don't really know where to go now clone DS... if ever I can do something (But I think yes).
  31. Rolf Kalbermatter started following Accessing Breakpoints and Wire Values in Preallocated Clone VIs (LabVIEW Scripting)
  32. Rolf Kalbermatter
    Top Level here almost certainly doesn't mean the diagram of the template VI. Instead LabVIEW distinguishes between a Top Level diagram which is basically the entire diagram window of a VI and sub diagrams such as each individual frame inside a case structure but also the diagram space inside a loop structure for instance. The tricky part may be that the diagram itself may indeed only exist once and remains the same even for clone VIs. The actual relevant part is the data space which is separate for each active clone (when you have shared clones) and unique for each clone (when you have pre-allocated clones).
  33. ensegre
    I thought it had to be read as in "the *top level node* of the BD of that particular instance", not as "the BD of the Top (prototype) VI", but haven't really tried... How do you get the values running onto a wire, btw, for my education?
  34. ManuBzh
    It's the Top Level Diagram reference... no the clone diagram reference (if ever this has sense) (If you look at the exact name on the property node linked to your diagram ref, you'll see : TopLvDiag )
  35. Techy
    Techy joined the community
  36. ensegre
    I assumed that if you obtain externally the clone VI ref and just pass it to the VI Block Diagram property you get the clone block diagram ref, but I haven't really tried it. Isn't that the case? If so, sorry for misleading you...
  37. ManuBzh
    I took a look to everything but seen no mentions about clone Diagram refnum...
  38. viSci
    Example of camera grab using the Pylon .net API. (Credits: GrokAI)
  1. Load more activity
×
×
  • Create New...

Important Information

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

  I accept