Jump to content

LogMAN

Members
  • Content Count

    398
  • Joined

  • Last visited

  • Days Won

    32

Everything posted by LogMAN

  1. Indeed, there is (to my knowledge) no way to achieve what you want with pure dataflow. You could put your string in a DVR and make it part of the parent state. As long as you keep the DVR contained inside the class, its behavior is well defined and can be documented. Of course, anyone who uses the class needs to be aware of the caveats.
  2. Yes you can. Have a dynamic dispatch EventHandler.vi that handles the events from Parent in Parent:EventHandler.vi and a Child:EventHandler.vi for every child. Use Call Parent Method in Child:EventHandler.vi parallel to the event loop of the child. Only the Stop event needs to be handled by each child. Here is an example I put together (saved for LabVIEW 2013): Reusable Events 13.0.zip
  3. Actually, if you turn your cluster back into JSON you can compare it to the original JSON string to see if there are any differences. The string is empty if every element is defined in the source string. Try this: Extract Parameters.vi Notice the "Differences" string, which lists all differences (missing elements) in your source JSON string.
  4. @ThomasGutzler here is a version that does most of what you describe. The order of elements inside Parameters doesn't matter. You can use enums. It doesn't matter if the JSON string has additional elements (no error) However, you don't get an error if an element is missing ("two" in your example). That would require something like a "strict" mode, which I don't think is supported by JSONtext. Unfortunately code is removed from VI snippets on LAVA, so here is the VI. Extract Parameters.vi
  5. You can change your terminals to dynamic dispatch at any time by choosing This Connection Is > Dynamic Dispatch Input/Output (Required) at the terminal block. You'll find that this option is only available for class inputs and outputs. To change your VI from static dispatch to dynamic dispatch, simply change both - input and output terminals - to dynamic dispatch.
  6. Not necessarily. Controls, Indicators and local variables have "built in logic to prevent front panel updates when continuously updating the same value. This prevents front panel re-draws". You can achieve similar results by deferring FP updates. Of course, writing to the control or indicator directly is the most efficient solution, because they "do not need to de-reference pointers, nor make copies of the data in memory". For your specific case, perhaps you can update the UI less frequently to reduce CPU load. Displaying a new value every 100 ms is more than sufficient for most applications. If you have a lot of graphs, pictures, etc., consider reducing the amount of data and update them only when necessary.
  7. Here is a KB article regarding the differences between controls and indicators, local variables and property nodes: Control/Indicator, Local Variable, and Value Property Node Differences There is also an article that explains the different threads in LabVIEW and what they are used for: How Many Threads Does LabVIEW Allocate?
  8. The front panel should be visible during the test to ensure that it is actually redrawn. It should also contain the necessary number of indicators to make both cases are comparable. If you reuse the same reference multiple times and defer panel updates, it only measures the iteration time of the For-loop + a single redraw, which is not the same as updating the UI on every loop iteration. Here is a version of your VI that has 100 boolean indicators on the front panel and is visible during test (it is also important to have all indicators visible on screen during test): MethodPerformance.vi On my PC the differences are much smaller with this version (if you set the number of elements to 1, the number of updates is roughly the same).
  9. You need at least four characters. Try "DLLs".
  10. Did you enable foreign key constraints? You need to set PRAGMA foreign_keys = ON Otherwise foreign key constrains are ignored. https://www.sqlite.org/pragma.html#pr>agma_foreign_keys
  11. Tested on two machines, same version, same issue. Selection box is an issue only on one machine, though. Found another strange behavior: When using View >> Always Show Labels and View >> Actual Size, this happens: 😕 Thanks, that fixed it for me too. However, only after opening the Launcher.vi. It didn't work by simply opening the example project. Than again, restarting LabVIEW unfixes it. Turns out, it sort of works when you open the class hierarchy window from inside a VI (an empty VI works as well). Steps to reproduce: Start LabVIEW Create new project Add new class to the project Open the class hierarchy window => notice that the window is broken Create a new VI Open the class hierarchy window => fixed 🤷‍♂️
  12. Got (the same?) issue with LV 2019 Version 19.0.1f1 (32-bit): One thing I noticed, if you try to box-select inside this window, it behaves irrationally, like a panel that was moved to far on the X or Y axis. Maybe that's a clue?
  13. I see the same issue with Version 19.0.1f1 (32-bit).
  14. LogMAN

    VIM and units

    http://www.ni.com/product-documentation/7900/en/ "LabVIEW 7.0 or earlier used a 64-bit double (DBL) to represent time, yielding 15 digits of precision. The number of seconds between 1st Jan 1904 (the timestamp Epoch or year zero) to 1st Jan 2000 is 3027456000. Representing this as a DBL would use 10 out of the 15 digits of precision. That leaves a very small resolution space to perform hardware timings using most of the resolution by simply going from 1904 to today. Representing time as a DBL was not ideal since it did not meet industry requirements."
  15. Most of them are actually LabVIEW specific and do not change based on OS settings. I suppose these are used to make LabVIEW look the same on all platforms. Some of them also emit special behavior. For example, 0x01000037 (system owner) is an opaque color that automatically adjusts the color of an element to the color of its owning container. Changing the color of the container then also changes the color of the contained element without having to address it individually. Maybe this is also useful for XControls.
  16. There are, actually, quite a few: https://labviewwiki.org/wiki/Color#Environment_colors
  17. It's a dataflow programming language that supports both functional and Object Oriented programming paradigms. Like C++ but not confusing LabVIEW will likely never be popular by the definition in this video, because it is not just a programming language but an ecosystem of hard- and software. It requires a lot of trust in NI and partners. You'd have to compare it to other proprietary programming languages with similar ecosystem for it to be "popular" in comparison. The first thing that comes to mind is interoperability. Calling external code from LabVIEW and vice versa still requires a decent amount of Voodoo (see the SQLite Library or OpenG ZIP as prime examples). To my knowledge there is no "plug-n-play" solution for these kinds of things. This is when the second best solution is often good enough. NI is of course interested in making LabVIEW more popular to grow business. As users we should be interested in making it more popular so that NI and the community can cope with ever-growing requirements and to open up new (business) opportunities. At the same time there is also a risk of growing too fast. The more popular LabVIEW gets, the more LabVIEW is used for tasks it wasn't originally designed for. This will inevitable result in more features being added which increases complexity of the entire ecosystem. If this process is too fast, chances are that poor decisions lead to more complex solutions, which are more expensive for NI to implement and maintain in the future. At some point they have to rethink their strategy and do some breaking changes. I assume this is where NXG comes into play. Is this good or bad? I don't know. It probably depends
  18. There is a forum where they want to discuss conversion tools, best practices et cetera: https://community.atlassian.com/t5/Bitbucket-articles/What-to-do-with-your-Mercurial-repos-when-Bitbucket-sunsets/ba-p/1155380 At git-scm they suggest using hg-fast-export. git-remote-hg seems to be popular as well. Someone wrote a script to automate the migration process to GitHub without using GitHub import. Although I'm not sure how well it performs it can be worth a try: https://magnushoff.com/blog/kick-the-bitbucket/
  19. Thanks for the heads up, this completely went by me. Here is the official blog post from Bitbucket if anyone is interested: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
  20. I wish it were that easy. Yes, they all adequately describe what's being talked about, but only when used in the same context. For example, what do you mean by "code complexity"? The amount of code in a single VI? => i.e. visual code complexity The way code is structured? => i.e. semantic code complexity (not sure if semantic is the right word for it. What I mean is code that is prone to interpretation by other programmers) The way code is executed? => i.e. running time complexity The number of possible code paths? => i.e. cyclomatic complexity It is my understanding that the first two points are about "readability", the third is "time complexity" and the last "code complexity". Good point. "accidental complexity" confused me as well, but the more I thought about it, the more it made sense (good for me, I know). In my opinion "accidental complexity" is a good way to describe how architectures and frameworks can go sideways very easily if decisions inadvertently lead to additional complexity (code complexity, system complexity, whatever). I don't think it's an official term though. Then again, English is my second language. I'll use that as an excuse 😋
  21. As @Daklu mentioned, "complexity" is being used for various perspectives in this thread. Maybe this entire discussion should also be moved to another thread? Here is a definition for "complexity" I find helpful at times like this: The important part is "difficult to re-create". Now let me pick up the example from before: By this definition of complexity, DQMH is indeed more complex than the Actor Framework because it produces many more potential outcomes (its operating state space is larger). The keyword in this example is "determinism": Priority messages in DQMH are nondeterministic (less deterministic is probably a better definition). Priority messages in AF are deterministic. A subtle yet important difference. Of course, here we are looking at the complexity of the framework itself, not the complexity of the user's code. When designing the architecture of a software, optional features like this should be taken into account. If determinism is a key requirement, AF is certainly a better choice than DQMH (not taking other key requirements into account). Let's assume we went with DQMH. This decision can lead to higher costs in the future if determinism turns out to be important and priority messages are being used a lot. In this case there are multiple options: Keep using DQMH and work around the problem with a custom solution => see sunk-cost-fallacy. Switch to another framework like AF You might think "that's never going to happen to me" => see Murphy's law If options were truly optional they would be extensions, not part of the core framework. The fact that priority messages are part of the core framework is a strong indicator that it is not possible to create the same behavior with the API. Thus, it is not optional but an important feature of the framework. As a user certainly, yes.
  22. According to the activity log @Rolf Kalbermatter is the only active user for at least the past 6 years (log ends there): https://sourceforge.net/p/opengtoolkit/activity/?page=1&limit=100 @jgcode compiled a nice list some time ago. Not sure if all of these are done yet: Here are some ideas that come to mind: Allow the community to participate in the project (create and maintain tasks/issues/features, add maintainers, add admins, etc...) Bring back openg.org (could be a different domain) and allow the community to contribute to the site via pull requests Split the monolithic repository into separate repositories for each project for best practice (and to prevent linking between projects) Convert the SVN repository to Git to allow offline branching, pull requests, etc... Use tags when releasing new versions, this allows everyone to use a prior version if needed. Add documentation for how to deploy new versions (the building process). Add documentation about which LV versions to use and what tests to perform before opening a pull request. Use a single license for all projects. Add a CLA to ensure the license holds for all contributions Work on Feature requests, bugs and change request (there are a lot) Share your thoughts SF is a good place for a small team of developers, working on their project. Users are only meant to report issues and make feature requests. All development is taken care of by the admins/maintainers. Although there are ways to do pull requests, they are very inconvenient and tend to scare potential contributors away. In my own experience, there are a few ways to revive a project like this: Get the original admins back to the project (unlikely, they left for their own reasons) Add new admins/maintainers who have full authority over the project => Requires at least one responsive admin / SF is difficult for contributors (compared to GitHub) Do what @Michael Aivaliotis did. Archive the original code base, move to a simpler platform and build on top of what is currently available. Option 3 is most likely to bear fruit.
  23. Here are some common files that could be helpful: The contribution guidelines are shown for pull requests: https://help.github.com/en/articles/setting-guidelines-for-repository-contributors LabVIEW versions, build instructions and the release process are commonly placed in a README file: https://help.github.com/en/articles/about-readmes The license can be managed in a similar fashion: https://help.github.com/en/articles/licensing-a-repository All of these files, if they exist, add to the GitHub experience. For example: https://github.com/microsoft/vscode
  24. They do: https://help.github.com/en/articles/setting-your-commit-email-address
  25. @Michael Aivaliotis You are right, organizations are the only way to group projects. Just as @JKSH said, a prefix is very helpful in finding things. Looks like you figured it out
×
×
  • Create New...

Important Information

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