Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 06/14/2024 in all areas

  1. Because I can immediately test the correctness of any of those VI's by pressing run and viewing the indicators. Nope. That's just a generalisation based on your specific workflow. If you have a bug, you may not know what VI it resides in and bugs can be introduced retrospectively because of changes in scope. Bugs can arise at any time when changes are made and not just in the VI you changed. If you are not using blackbox testing and relying on unit tests, your software definitely has bugs in it and your customers will find them before you do. Again. That's just your specific workflow. The idea of having "debugging sessions" is an anathema to me. I make a change, run it, make a change, run it. That's my workflow - inline testing while coding along with unit testing at the cycle end. The goal is to have zero failures in unit testing or, put it another way, unit and blackbox testing is the customer! Unlike most of the text languages; we have just-in-time compilation - use it. I can quantitively do that without running unit tests using a front panel. What's your metric for being happy that a VI works well without a front panel? Passes a unit test? It may be in the codebase for 30 years but when debugging I may need to use the suspend (see below) to trace another bug through that and many other VI's. There is a setting on subVI's that allow the FP to suspend the execution of a VI and allow modification of the data and run it over and over again while the rest of the system carries on. This is an invaluable feature which requires a front panel This is simply not true and is a fundamental misunderstanding of how exe's are compiled. Can't wait for the complaint about the LabVIEW garbage collector. We'll agree to disagree.
    4 points
  2. Hi @greatjames don't take this personally but are you are human? I really don't think it is appropriate for an LLM to generate content in response to advice on something as nuanced as a LabVIEW career.
    2 points
  3. This looks interesting. What are the licensing used? What are the restrictions? Is there a manual that is in English? Is the source code available?
    1 point
  4. Oh, I knew. I just like to poke dormant threads (keeps the context instead of duplicating it into a new one) until their issue is resolved. Only then can they die, and live on forever in the cloud😉
    1 point
  5. This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all. Kudos (or critique) welcome!!
    1 point
  6. 1 point
  7. Yes, as a general rule, it is fairly unusual to stick an equal sign on a floating point number. This applies to most programming languages, not just LabVIEW. So, I would never stick an equals zero on the output of std dev but I have once or twice broken the rule like this:
    1 point
  8. Hi Diac, What in particular do you need help with as you ask about how to implement the whole project! If you have something working with an ESP32 try and mimic the implemention in LabVIEW
    1 point
  9. I will contact both of you to understand your concerns a bit more, since these toolkits (IO-Link for LabVIEW and TestStand) were developed exactly to accommodate the scenarios you describe. I can clarify a couple of things here as well: - Our runtime licenses are always perpetual, never a subscription that could expire. - For development licenses we offer both subscription (to get going for less) and perpetual (if you know you want to use it for a long time). - We do offer discounts on license bundles. So if someone has "hundreds of systems", they could use that option. - The software in question currently has more than 3,000 hours of development time behind it, with ongoing improvements. I assure you, no matter when you begin it will be a long time before you have something that is close to what you could buy today. And at that point you wouldn't consider giving it away for free 🙂. This toolkit parses the entire IODD XML standard, which is huge. It is not quite the same as picking the 2% you need today, and discovering that the next device you want to connect uses a different part of the standard...
    1 point
  10. Not sure about 2011 to be honest, but no you do not have to have all dependencies included in a PPL. You can have a PPL depend on other PPLs and configure the build to exclude that dependency from you PPL build, so that it remains external. This has of course to be down from bottom up, which is quite a work. Only PPL dependencies and other binary dependencies can be excluded from being pulled into a PPL. So if you want code that has to be shared between your PPL and other PPLs or your exe, that code needs to be in its own PPL, so each of those can refer to it. Yes it is not trivial and you need to plan before you start programming. You need to have a clear hierarchy overview and be able to cleanly modularize your code into different PPLs. Tools like the MGI Solution Builder definitely help with that as you can script the creation of a whole hierarchy of PPLs to be compiled in the correct order. Someone from NI was busy creating another solution that could build PPLs and in the process of building them also relink any dependencies on lvlib's into dependencies of lvlibp's but that didn't quite finish.
    1 point
  11. As an experiment in seeing what VIMs can do, here is an all-VIM implementation of a "circular buffer", based on code from a 2D DBL array circular buffer I had previously used. In LabVIEW 2018. Features: Works on any scalar type, giving a 1D array buffer, or any 1D array, giving a 2D array buffer (could be extended to a 3D buffer of 2D arrays) Has VIMs that accept either a by-Value Buffer, or a DVR of a Buffer Package contains simple examples. Comments welcome. jdp_science_lib_malleable_buffer-0.1.0.5.vip
    1 point
  12. For me it has improved but is not quite fixed. I still get broken wires on the calling VI when changing anything in some vims. In fact, I have a VI which I copied from the Debug Log.lvlib:Debug Write.vim in vi.lib and made some changes to. My version breaks when I change anything in it, but the VI.lib-one does not. I have force-recompiled and am now trying to make my VI work like the one in vi.lib, but mine still breaks. I just might recreate it and see where/if it breaks then. I don't know if I am unlucky or if that might happen for others too. When the wires do break, it seems like they auto-heal better than before, when I had to rewire at every broken place, but now its enough to just do something that triggers a compile (I think).
    1 point
  13. Put a new 0.5 version on VIPM.io Remember, this is still beta code.
    1 point
  14. Malleable Buffer.zip James: I did a lot of polish on your library -- cleaning diagrams, finishing out a couple of API points, documentation. I deleted the experiment stuff. You're free to take the attached files and add them to your published VIP if you want. There was only one real functionality change that I made: a performance improvement to "Add to Buffer (By Value).vi". Thank you -- this code is quite helpful in my current project.
    1 point
  15. Decided to update this to 2020 and release (this is 0.3; I never posted 0.2): jdp_science_lib_malleable_buffer-0.3.0.8.vip
    1 point
  16. This IS fixed in LV 2020, but it got left out of the Upgrade Notes*. I have posted details here: https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624 The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-defined. * My mistake -- apparently my tech writers cannot read my mind; I actually have to hit Submit on bug reports, not just leave them in Draft. *chagrin*
    1 point
  17. The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.
    1 point
  18. I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.
    1 point
  19. I thought this was an interesting exercise so here is my attempt. OpenG has some image tools and one of them is the ability to open a GIF, but for some reason it crapped out and died with your GIF even after resaving it to something much smaller. I did find some other GIF API over on the dark side and instead used that. Attached is a zip, extract it and run Demo Saving Button. It will show the first image. Then when you click the image it cycles through the first half of the GIF and waits for the simulated save process to complete. Once it is complete it rotates through the second half of the images, and then after a few seconds returns back to the first. Parsing of the GIF takes time so I put in the GIF images as a constant, along with the code to parse the GIF. I also set the pane to be the color of the (0,0) pixel in the hopes it will blend in better. Honestly this could be turned into a QControl and be made very seemless. Demo Saving Button Gif.zip
    1 point
  20. Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history. If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.
    1 point
  21. First up, it's not that I don't like Front Panels! Rather, the idea comes from the recognition that, as evidenced by a fair number of ideas in the Idea Exchange, FPs often add unnecessary work to developing VIs. I was trying to pull a number of different ideas together into a solution, sparked by reading this idea which suggests adding yet another layer to a VI - and questioning whether we can reduce complexity instead of increasing it. There's been some discussion on how to limit the FP to show only what's needed for the user interface (e.g. here). Having unneeded (from the interface point-of-view) controls and indicators on the FP means we need to work around issues such as edit-vs-run-time displays, setting up tab orders, rescaling controls (but only some of them) as panels change size, disabled code, and so on. The basis of my suggestion is not that we shouldn't have FPs, but that FPs should only contain what is needed to be seen by the user. Secondly, the data that needs to be seen during development or debugging is often very different again. When we use a Probe, we essentially create a virtual indicator. Take the Probe Window slightly further in its development, and we now have a second FP, which contains another set of controls/indicators for showing, or setting, the data during execution. Also, for many VIs, the variables that are passed through the conpane interface are not required to be shown in the user-interface - Error clusters for example. It makes sense to be able to link the conpane directly to BD controls, and therefore there is no need for the controls/indicators to appear on the FP at all - many subVIs without user interaction wouldn't need an FP defined at all. To me, the conpane has a much stronger link to the BD than the FP, as it is there to provide the programming interface to the code. The downside would be that it is perhaps more difficult to find terminals on a crowded BD, but that could be enhanced (e.g. mouse-over the conpane, and everything fades except for terminals). Perhaps there would even be the opportunity to see the FP as a virtual cluster. The LV paradigm presumably arises from the concept of Virtual Instruments, where the controls/indicators are what you define your instrument by - and much early code was all contained within one VI! This idea suggests that LV has perhaps grown past that stage, with far more emphasis now on subVIs, classes, libraries, etc which are maybe more like patch panels or breadboards (still thinking as an engineer!) - things that are hidden from the end-user. I don't see it as such a radical change - more a response to the way that LabVIEW is being used anyway - to make that process easier and more transparent.
    1 point
  22. It's with a saddened heart that I pass this news along, that we've lost a dear friend and LabVIEW Champion, @Kurt Friday. https://www.linkedin.com/feed/update/urn:li:activity:7212115164492353541/ We will miss you, mate.
    0 points
×
×
  • Create New...

Important Information

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