Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 09/21/2020 in Posts

  1. “There was this fence where we pressed our faces and felt the wind turn warm and held to the fence and forgot who we were or where we came from but dreamed of who we might be and where we might go...” -- Opening lines of “R is for Rocket” by Ray Bradbury I spent 20 years building this G language of ours. It’s time for me to go enjoy the fruits of that labor as a user! I will still be employed by NI, but I will be working full time for Blue Origin. As part of the NI “Engineer in Residence” program, I will be on loan to Blue Origin to revise their engine and support test systems. They
    10 points
  2. I want to remind once again that all this information is just to have fun playing with LabVIEW and not intended for real projects use. I believe you all understand that. 🙂 Not that a big opening here and even not an opening for some ones, but I found this interesting enough to make a thread. As you may already know, when some library is being called using CLF Node, LabVIEW enters ExtFuncWrapper first to do some guard checks to prevent itself from a silent crash and output some error message to the user instead. I've always considered that wrapper boring enough to study, thus never looked
    3 points
  3. I have made public a document detailing an old internal feature of LabVIEW that will be of great interest to those of you deploying Packed Project Libraries. Until recent conversations with a customer, I never considered that this would have much utility. The problem this solves: First, you build a packed project library (PPL) from source. Then, you write a VI that calls that PPL. It works fine. But now you load the caller VI under a different target in your project. The caller VI breaks because it tries to load the PPL, and the PPL refuses because it isn't built for the new target. Packe
    3 points
  4. I am trying to shift discussion of Messenger Library to a group at NI, as this conversation is at 12 pages and is hard to follow. New post about a beta feature for TCP that I am working on: https://forums.ni.com/t5/JDP-Science-Tools/New-Beta-feature-Reconnecting-TCP-Messenger/gpm-p/4092514#M5 Here's the image. The idea is to have a persistent TCP Client connection that will try and reestablish itself if broken.
    2 points
  5. It's documented in the DEV Template. I use a feedback timeout that is default 0 ms from every case but the Timeout case (which feeds back -1). This makes the Timeout case execute exactly once after the event queue is empty. Use a "Display needs update" boolean flag to record if the display needs updating in the timeout case. One can do this with Queues as well. With this one is able to look at all incoming data, but do expensive display operations only as often as possible (but as quickly as possible). So you could, for example, have information coming in a 100 a second, a
    2 points
  6. I've submitted a new version to the Tools Network.
    2 points
  7. From what we have discussed so far, the Messenger Library certainly seems to be a perfect fit. It'll provide you with the infrastructure to run any number (and type) of workers and communicate with them in a command-like fashion. It is, however, a much more advanced framework than the simple message handler from my examples. As such, it will take more time to learn and use properly. As someone who enjoys the company of technicians who get scared by things like "classes" (not to mention inheritance 🙄), I strongly suggest to evaluate the skill levels of your maintainers before going too
    2 points
  8. Remember that you are a User, and you only look at User Interface. When you "open a class" a cluster UI widget is loaded to represent the class data. But that widget is not the actual cluster. When you "open a subVI", the corresponding front panel is loaded with UI widgets to correspond to the block diagram terminals. But for most subVIs, that front panel is never loaded if it is not opened. This is unfortunately counter intuitive, as every subVI has a User Interface (Front Panel) a new programmer will think that is significant, while an experienced LabVIEW programmer will intuitivel
    2 points
  9. LabVIEW's built-in XNode editing tools are enabled using a license file, rather than a simple INI toggle. Presumably they do this for stronger discouragement from unofficial use, as hacking one's way past that feels a lot more "shady" than just adding a line to a config file. But what about the Linux and Mac versions? They don't have a license manager, so how is XNode development enabled there? One might guess that those features simply aren't compiled into the released builds of those versions, but there is actually precedent to suggest otherwise. VI Scripting used to be similarly restri
    2 points
  10. It's a compromise between convenience and security and partially solves the "trust" issue by having really, really trustworthy organisations There have been other alternatives proposed but the "trust" issue has never really been solved adequately, to date. I trust me so my certificates are great (for me). The problem with that is then distribution. SSH. which is arguably the progenitor of modern TLS, got a lot of things very right. We haven't really moved on from that model except to make a whole new business sector for the key management.
    1 point
  11. You're right, this needs an example. How you describe it sounds correct. I've had as many as four update Booleans, I think.
    1 point
  12. You can use the Flush Event Queue function to clear out old events.
    1 point
  13. A Notifier is only usable is you only have one type of message coming in, and your display doesn't include any history, like a chart. Personally, I keep the data transfer lossless, but just make the actual front panel display update lossy.
    1 point
  14. RAM is virtually free these days. As much as I love and absolutely strive for efficiency there is just no point in sweating about several MB of memory. There is no silver bullet, if I need to do multiple things with a piece of data it is often so much easier to just make a copy and forget about it after that (so multiple Queues, multiple consumers of a User Event, whatever). It is not uncommon for a PC to have 32 GB of RAM, and even assuming we are using only 32 bit Windows that still means nearly 3 GB of RAM available for your application which is actually an insane amount.
    1 point
  15. I have only one project that uses multiple DVRs to keep large chunks of data in memory, which are accessed by multiple concurrent processes for various reasons. It works, but it is very difficult to follow the data flow without a chart that explains how the application works. In many cases there are good alternatives that don't require DVRs and which are easier to maintain in the long run. The final decision is yours, of course. I'm not saying that they won't work, you should just be aware of the limitations and feel comfortable using and maintaining them. For sure I'll not encourage you
    1 point
  16. They way you're using DVRs here, pulling the full data out of the in-place structure, forces a lot of copying. You have to do the work inside the event structure if you wish to prevent copying.
    1 point
  17. I exclusively use events for messages and data,even for super high rate data. The trick is to have multiple events so that processes can listen to just those they care about.
    1 point
  18. This fix is on the Tools Network now. JDP Science Common Utilities 1.2.1.12
    1 point
  19. You have to install at least the LabVIEW Runtime Environment for your particular version of LabVIEW and any dependencies. Otherwise you'll receive many error messages. The best way to go about it is to add a build specification for an installer to your LabVIEW project, with which you can distribute your application and any dependencies in one package. It will produce an installer for your application. Here is a KB article that explains the process: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019PV6SAM Additionally, you can include MAX configurations from your machine
    1 point
  20. It could make sense if the PostgreSQL DLLs were compiled with Microsoft Studio 2010 or 2012 or similar (not sure which Visual Studio version is used for compilation of LabVIEW 2015) and set to use dynamic linked MS C Runtime library. It is old enough to not be standard on a recent Windows 10 installation and not new enough to not be tightly coupled with a specific Microsoft Visual C runtime version. Since about Microsoft Studio 2015, the Visual C runtime has stayed at version 14.x and doesnt with each new version require a new runtime. It's still possible that a newer Visual Studio application
    1 point
  21. I think CallInstrument() is more promising although the documenttion I found seems to indicate that it is an old function that is superseded by something called C Interface in LabVIEW. But I haven't found any information about that new interface. /* Legacy C function access to call a VI. Newer code should consider upgrading to use the C Interface to LabVIEW. */ /* Flags to influence window behavior when calling a VI synchronously via CallInstrument* functions. The following flags offer a refinement to how the former 'modal' input to CallInstrument* functions works. For compatibility,
    1 point
  22. @Steve Drouilhet No problem. I believe it was this toolkit: https://github.com/Indie-Energy/AWS-IoT-RESTful and the license is pretty wide open I believe. If I have a chance I'll see if I can pack it up and contribute to the project on the github. I'm also using the WireFlow toolkit (paid) for some MQTT projects with a broker that I've set up. I was initially drawn to the Indie-Energy one even though I have a WF toolkit license since it was more plug and play for AWS. I do think now after learning more about the AWS IoT stuff that either will work, but also that I don't want to work
    1 point
  23. If you use Ctrl+Shift+D,|, it will enable logging DPrintf messages. Then you can do Ctrl+Shift+D,P to display a list with most of them: LabVIEW internal debug keys - Ctrl + Shift + D + one of the following | toggle DPrintfs. Currently on. : print global font table A check app heap B print TD dictionary stats D PrintDSStats E toggle QElement checking G toggle StripChart scroll/copybits H show/hide heap peek. I print heap text info J rebuild all malleable instance VIs in current VI's context L prints linker graph viz info M toggle memory checking. N show Ned, the f
    1 point
  24. Another thing I did with the aforementioned was to add TCPIP (a later version). It meant you could launch a VI and then communicate with it via strings sent from Test stand - even on remote machines. The wrapper was only slightly more complex than the pure launcher but it meant you could configure the devices on-the-fly, abort or reset devices and query state information with simple strings from Test Stand (I used SCPI-like commands). Anyway. I diverge. You've probably guessed by now that the choice you had was to have an instance per device which you control and sequence from TS, wh
    1 point
  25. All my applications are developed with a package I wrote several years ago called "Messenger Library": https://labviewwiki.org/wiki/Messenger_Library There are a few YouTube videos linked from that wiki that go through an actual example application. It's motivated by the Actor Model, and so I take inspiration from frameworks like Erlang, Akka or the C++ Actor Framework. The core concept is "messaging" to gain the benefits you list.
    1 point
  26. You do use the same "normal" controls in the class private data as you would in your GUI. This is 100% ok and you can use whatever you like as they will never be visible at runtime, they are just a visual representation of your data types. What you choose to show on the GUI is totally unrelated to what data you choose to have in the classes.
    1 point
  27. Didn't not read the full conversation, but thought I'd point out to the OP that it is a common mistake for programmers coming into LabVIEW to mistakenly identify LabVIEW's UI Widgets (Controls/Indicators) as being "variables", and Control References (actually references to the UI widgets) as being "data references". They also confuse the UI Widgets with the data that the Widget is acting as a UI for (which I suspect the OP has done when they talked about having many data copies in using "Arrays" and "Clusters"). Performant data-handling code will not utilize the User Interface at all, an
    1 point
  28. It took a while to code it, but here it is finally. 😉 I have found a way to retrieve the object's pointer soon after the last post in this thread, but had to debug and test everything. Refnum_to_Pointer.rar How it works: As we don't have any public or private API to obtain Base Cookie Jar (BCJ) pointer (that is a LabVIEW global variable), the only way is to examine some function, which uses it, find the place with this global and save the pointer. Actually, this is how we're getting our BCJ. To clarify, it's for Object References only, not for any other references out there.
    1 point
  29. It's available on Web Archive as well.
    1 point
  30. Note: you can also do this (using the JSONpath for all array elements) because here one is specifying the element of the array (with default) rather that an empty array:
    1 point
  31. I will complete the survey but wanted to add here as well. I use EtherCAT primarily with 3rd party slaves and only use NI hardware\software. I have limited time resources and prefer to stay within one environment, so I choose NI software whenever I can. I just don't have time to learn all the 3rd party tools. Maybe others can help me here. if anything, at least this thread has brought other ECAT experts to the surface, I can DM for help 😉. I have come across a few limitations but I have been able to work around them because I have no choice. One thing that is frustrating is there is no wa
    1 point
  32. Hi Zofia, In short NI's implementation of EtherCAT functionality is not on par with other NI tools as I've experienced. I'll try to explain on this as best I can. NI only Supports CoE, CANOpen over EtherCAT. This is just fine as I (perhaps most devs ) has CAN/CANOpen experience. This is not an issue as I stated but I thought to add just so we know that we are talking only about CoE in following points below. NI's Server implementation is not ready for Non-NI hardware. It seems the server was solely designed with other NI-Slaves in mind. Connecti
    1 point
  33. Same story here. We've just started to standarize on Beckhoff. EtherCAT is nice medium for realizing distributed systems. We use EP boxes for distributed IO (just as your case - a great way to reduce wiring; add IO-Link sensors and actuators to the mix and you save A LOT of work with the system assembly and testing and gaining unlimited flexibility). EL terminals for the control cabinet - you can basically build any system capabilities you like, and add anything any time in case you'd forgot. Also, you get safety-rated terminals and boxes (and you can build distributed system with that, no nee
    1 point
  34. Hi Zofia we talked before but I'll all add my bit here to see if anyone else has comments. EtherCAT is very powerful but so many of those features are held back by the NI EtherCAT master. For example you can get diagnostics on each individual link slave to slave but NI doesn't show that. No official support for topologies other than line or ring. I have gotten it to work with an EtherCAT junction but nothing displays correctly in the project. No hot-connect groups like with TwinCAT. Configuring slaves with CoE is difficult. I use TwinCAT for that. Just the bare minimum is there in the master t
    1 point
  35. NI Week was a blast and while there I got to mention a few things I was trying that I'd like to share with the community. One of them is this thing I'm calling a Multi Panel Interface (MPI). The code is rough around the edges, very rough. This is probably the least polished code I've posted in a long time but this code has been sitting in a half working state for a while, and if I took the time to clean it up, it might never be ready. So please be gentle, there's room for improvement but I think the basics are there. Now with that out of the way here's what I got. I wanted to
    1 point
  36. You can edit that wiki if you have more info. or write your comments in "Discussion" page if you're unsure about editing it directly. I created a whole category of articles there: https://labviewwiki.org/wiki/Category:LabVIEW_internals
    1 point
  37. Okay for the heck of it here is my interpretation. I read that as OP trying to remove the last few characters from each string in an array. (also I read "few" as 3). Also snippets might not be working so attached is a VI in 2018. Remove Strings Test.vi
    1 point
  38. So I wanted to make a VIM that was essentially "Convert input into 1D string array". If you passed it a 1D array of anything it would convert each element to strings (similar to the debug VIM that ships), but passing in any scalar would do assorted things depending on the scalar (single item array for things like numerics, but a Path would split into each component, and different methods for other types). I thought it would be a good idea to have an option that if an enum is passed it, the array passed out would be the list of all of the options converted to strings. They way to get thi
    1 point
  39. I had no idea this existed. I will look into it.
    1 point
  40. I made the Server a Client of itself, in order to get events when true Clients changed things. A bit weird.
    1 point
  41. There is an undocumented, unsupported API for scripting FPGA nodes. Take a look in this folder and see what you can find: [LabVIEW 20xx]\vi.lib\rvi\ClientSDK
    1 point
  42. . Graph_Problem - Fixed.LV82.vi
    1 point


×
×
  • Create New...

Important Information

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