Jump to content
News about the LabVIEW Wiki! Read more... ×


Popular Content

Showing content with the highest reputation since 01/22/2019 in all areas

  1. 4 points
    You know how you can change the wire appearance for a class in the class properties? As it turns out, LabVIEW internally allows for more flexibility than that dialog gives you. So I made an advanced wire editing tool...and unlike a lot of stuff I post, you can actually use this for serious projects, because it does not use any private/unsupported LabVIEW functionality! With this tool, you can set wire size without limits (with results similar to this), customize both wire layers with any 8x8 monochrome pattern, and also mess with different draw options. Strangely, a few of these settings seem to have no effect, and many of the options for one of them actually crash LabVIEW. (These ones are disabled in my tool, but you can re-enable them by editing a typedef.) Given that this is actually a documented, supported property that's officially supposed to work, I've reported this as a bug to NI; if any NI engineers see this and feel like investigating, you can refer to service request #7762024. Latest version: Wire Studio 2.zip Old versions: Revision 1
  2. 2 points
    Wait, what about the person who already had the name Bryan?
  3. 1 point
    View File 55 easily distinguishable color.vi This is the only way I found how to have a bunch of color that are unique and easily distinguishable. The maximum I saw in the web was about 26. This one offer 55 of them without gray tone. You can modify this VI to support gray tone as well and goes up to 60 colors. Please use the new version at: New version Submitter Benoit Submitted 02/08/2018 Category *Uncertified* LabVIEW Version  
  4. 1 point
  5. 1 point
    I made a fun piece of code, and thought that I'd share. Maybe it'll spark some good discussion. Here it is: Push-Notifier.zip I wanted to accomplish 2 things with this code: 1) I wanted to be able to create a notifier that I can register as a user event. Basically, I want a user event to be generated whenever a new notification is sent. 2) When I register for a user event, I want to be able to also force the event structure to generate a user event using the most recent notification. (Helpful for initialization of data in the event structure) Demo VI looks like this: Anyways, thought this might be fun to share
  6. 1 point
    I've noticed a lot of slowdowns with LV2017 and LV2018 doesn't seem any better. Also, I use the NI-IMAQ extensively and NI-IMAQ 2018 is buggy and doesn't seem ready for widespread use. I've been trying to deal with these massive slowdowns with LabVIEW 2017 for over a year now and it has really slowed down development for me. I too have issues scrolling (I have the same 2Hz refresh rates sometimes, but then it seems to mysteriously go away), slow window drags, slow selection dragging, etc. and have contacted NI technical support about this but since I can't provide my project, haven't gotten far at determining cause or solutions. Why does it seem that nobody at NI is concerned about this behavior?
  7. 1 point
    I use the dll wizard often and it has saved me a lot of time. It took awhile to understand how to massage the .h files into something digestible but once I got the hang of it, it was worth the effort. The error handling is pretty good at pointing you to the offending spot in the .h file. I think that the wizard has improved over time so if your last exposure was years ago I would give it another try.
  8. 1 point
    My understanding from what came up is that Matlab is attempting to build a wrapper dll with some more matlab friendly interface. A quick google didn't find me anything about how it does this, but that seems to be what its doing. I say that because the "we dont know the..." come from the labview headers. So it seems like Matlab is running a compiler against stim.h which includes the platdefines header, and since I'm assuming the matlab compiler is not one of the ones NI was expecting when they built this (or if matlab simply doesn't #define the same definitions NI is expecting), the compiler correctly spits out the errors shown, as in this snippet of platdefines: #ifdef _M_PPC #define ProcessorType kPPC #elif defined(_M_IX86) #define ProcessorType kX86 #elif defined(_M_X64) #define ProcessorType kX64 #elif defined(_M_ALPHA) #define ProcessorType kDECAlpha #elif Compiler == kBorlandC #define ProcessorType kX86 #elif defined(_ARM_) #define ProcessorType kARM #else #error "We don't know the ProcessorType architecture" #endif So the question becomes what should it be. My guess is that they should be defined per the labview exe/dll which is why I suggested the MSVC compiler definitions (as I understand it, this is what NI uses for windows builds). However it may be that the right answer is to edit the headers to set something more appropriate. For example, in the section above, you could comment every line out except for "#define ProcessorType kX64". Similarly you could comment out the compiler section and replace it with "#define Compiler kGCC" (if that is what matlab uses, which I assume it is). The only reason these need to be defined is so that extcode.h picks up all the appropriate definitions and headers for the platform. For example. stim.h uses the type "uint32_t". This is defined in stdint.h, but if your compiler isn't including it already then stim.h can't be compiled. So, in fundtypes.h, it has a bunch of platform checks to see if it needs to define those types. The easier route, vs trying to make extcode.h have the proper types, would be to just edit stim.h directly to include the type definitions you need. I would suggest editing your stim.h to look like this (lines 1-7): //#include "extcode.h" //this dll only uses two uncertainly defined types, but they are defined by stdint.h. This section is borrowed from fundtypes.h #if !defined(_STDINT_H_) && !defined(_STDINT_H) && !defined(_STDINT) #include <stdint.h> //alternatively comment the line above and uncomment these lines: //typedef int int32_t; //typedef unsigned int uint32_t; #endif #ifdef __cplusplus extern "C" { #endif .....
  9. 1 point
    From time to time, albeit sporadically, I have to build wrapper sets to .dll and .so, and I would love any improvement. Back in the days I was used to have to write my wrapper VIs one by one, and by now, especially for large libraries, the import wizard is a lifesaver to me. However, I end up still spending some amount of time, often significant, domesticating the .h files provided with the libraries so that the wizard sees better through them, writing LV translators between C structures and casted down byte arrays, creating ad hoc enum ring typedefs, hunting untranslated pointers, and similar chores. If that could be automated, I would enjoy it, though I agree that beyond some point that becomes project-specific. And at times (callbacks, message pumps i.e.) still no choice but having to write C containers. Have btw the import tool parsing capabilities got any better across versions? (I vaguely think yes but I don't have fair data for a comparison)
  10. 1 point
    LLVM/Clang is truly a marvel! If you need to write wrapper VIs for DLLs, then I think a tool like this is the way to go. However, unless the C API has anything non-trivial like passing a large struct by-value or strings/arrays, you'll end up having to write your own wrapper DLL, right? (side note: I do wish LabVIEW would let us pass Booleans straight into a CLFN by-value...) This struct has the same size as a single int, so you can lie to the CLFN: Say that the parameter type is a plain I32. What are the possible types in the union? If they're quite simple and small, you could tell the CLFN to treat it as a fixed-size cluster of U8s (where the number of cluster elements equals the number of bytes of the union), then Type Cast the value to the right type. The type cast will treat your cluster as a byte array). These would require project-specific scripts that don't fit in a generic automatic tool though. The import wizard was useful for study purposes, to figure out how I should create my wrapper (using a simple sample DLL). That was about it.
  11. 1 point
    Also, this is kind of a side point but the concept is the same. Has anyone noticed that reentrant VIs get super slow sometimes when debugging? Its not always, but I can't figure out what conditions might be causing it. Its like you're going along debugging some code, you step into a reentrant VI, and everything just stops, and it takes like 20-30 seconds for the window to materialize. I know its not just one computer, sadly.
  12. 1 point
    As a consultant I have to work with whatever code my customer has developed. Some of it does indeed take several monitors to scroll across and I just have to deal with this. The IDE should not choke or do "stuff" constantly while I am editing. Also, as is pretty common during development my code spends a lot of time broken as I develop or refactor stuff, and I have to deal with missing VIs all the time as I integrate other team members code back into the main branch. As LogMAN pointed out, the behaviour of the selection rectangle is so much quicker in 2015 (at the expense of the "amazing must have could not live without" feature of shading the contents of the rectangle). I bet ShaunR is having a quiet chuckle about this whole thing as he gets to use 2012 or something like that. Sorry if I am coming across angry, but I am. LabVIEW is not exactly a new immature product that is given away for free. We really should not put up with this rubbish. If I have to wait for my IDE to draw a shaded rectangle, regardless of the quality of code underneat, something is deeply wrong.
  13. 1 point
    I can present less complex VIs with the same behavior, more or less intense. @Neil Pate likely also doesn't use broken VIs for real world applications and gets similar behavior. The VI in my video is certainly an extreme case that is not fit to be part of any code base, but it serves as a good example for how bad things can get. I don't expect that VI to work flawlessly, but it wouldn't hurt trying to achieve that, even if that means disabling fancy stuff for more complex VIs. Here is the same VI in LV2015 for reference. To be fair, scrolling is as slow as in LV2017 (or vice versa), but the selection box is so much better. 2019-02-01 21-33-45.mp4 The VIs I'm normally working with are much smaller than this one. Most of them fit on the screen, so scrolling is not an issue for me. The selection box, however, is a different story and part of my daily work. It being slow is a red flag.
  14. 1 point
    😁 2019-02-01 21-13-21.mp4
  15. 1 point
    That is very unfortunate. NI really needs to work on that. For reference, I found a complex VI here and used that on my private notebook (decent hardware, enough for LV2015). This is what it looks like on my end (using LV2017.0f2). 2019-02-01 20-59-05.mp4 It's a bit faster without recording of course, but not much. Also the CPU consumption is about 20% while dragging, which is way to high in my opinion. How did that ever pass testing phase? Looks to me like they never tested with more complex VIs like this because it works fine for smaller (or empty) VIs. Anyway, it seems that the dragging operation in LV2017 is not a O(1) operation. More like O(n) where n is the number of objects on the block diagram. They probably check every object during the drag operation to figure out which one to highlight. Works better on the front panel but that is probably because there are less objects on the FP (i.e. no wires).
  16. 1 point
    There should not be, adapting to type is all you want and thats what vims do. As pointed out, queues are not a runtime-dispatchable type in the same way you cannot dynamic dispatch off a boolean or an array. The contents are irrelevant. Its worth noting that vims support dispatching based on method name rather than class hierarchy. There are examples of using vims to make lvclasses act kind of like interfaces (ie if you have two separate hierarchies with a method "Get queue" which returns a thing at connector pane position 3, you can put that in a vim and it will adapt, including if that outputted thing has a different type). As a side note, you can and should wrap the queue status and index primitives inside of a disable structure.
  17. 1 point
    Python is like a candy store and it is so easy to deploy a package and start using it. I'll try to explain yet keep in mind that I prefer working with LabVIEW end to end mainly because of maintenance 5 years from now. I don't want to employ a C, python or whatever language programmer forever and ever. Building a well documented and automated tool in one language makes the development somewhat limited but the result should be much more stable in the long run without issues rising from bad communication between departments. Let's say you have several generic test-benches with different devices in them that can test different uuts. There are versioned generic drivers for those test-benches that can be operated via an API. I'll open the browser and communicate to the server back and forth through xml rpc. The server will decide which generic driver to deploy and through celery it will decide which uut is going to be tested where and when and by whom. The server will send the relevant flow of uut test. The db with matchmaking of station+uut+sequence of a test is mongo db since the structures are not as strong as in sql, it fits the development in a much more harmonic way. Take notice that this way a control in a function doesn't have to keep all the inheritance limitations in an OO HAL. You simply deploy the relevant test sequence. Finally, Kibana will create reports from the results collected with recipes which are fast again since the mongodb is tailored to the development and doesn't enforce an sql design which might be slow for a future query that the sql design was not optimized for and it is nearly impossible to optimize it in this stage of the development. Factory floor results accumulate fast and in a matter of 5 years, it will be hard for the sql query to want to run given the timeout and optimization you set when you designed the system. A kibana recipe tailored for a mongodb that is in harmony with the software design will be fast even over huge datasets.
  18. 1 point
    And yet all they're using is plain black lines connecting the nodes. In this thread? Really?
  19. 1 point
    To badly paraphrase... Some people, when confronted with a problem, think “I know, I'll use packed libraries.” Now they have two problems.
  20. 1 point
    Here is the problem. When displaying in a Hex format, the update value while typing cannot be activated. Since the value is updated only when you click somewhere else on the front panel, if the first click is on the button COM Write, the value is updated after the Event mouse down is fired. Benoit
  21. 1 point
    Hey, sorry, just saw this. I'll see if i can change SouthPaw to Bryan. The Wiki admin stuff is not as sophisticated as the one here on LAVA and they are not connected either. Let me see what I can do.
  22. 1 point
    Loving this central location of organized and searchable LabVIEW knowledge! (Just like LAVA.😁) I've made a couple of small contributions to this so far. Mostly clicking on "Random Article" and reviewing it for typos and broken links. I set somewhat of a personal goal of trying to do this at least once per workday. Every little bit helps, right? Granted, they're not contributions on a grand scale yet, (i.e I'm not creating articles, etc.) but maybe I'll get there. This is my first time contributing to a Wiki of any kind, so I'm a n00b at it.
  23. 1 point
    Killer feature: new hardware only supported on NXG 🤦‍♂️
  24. 1 point

    Version 1.0.0


    Hi everyone, Since GRBL standard is open source, I decided to post my Library that I used in LabVIEW to interface a standard GRBL version 1.1 controller. Not all GRBL function has been integrated, but this is a very good start. Enjoy and let me know your comments. Benoit
  25. 1 point
    Note: JSONtext is now on the LabVIEW Tools network.


Important Information

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