Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 08/25/2021 in all areas

  1. So I managed to find the underlying issue and at least one solution to it - sharing the information here. The Icon editor enumerates the font list in linux with command 'fc-list'. With OpenSUSE 43.2 / LV 2016 combo the fontlist looks like this: The listed fonts are essentially a list of the font files with full paths, and that does not work well with the font tool LV uses. If this list looks similar to yours and the fonts are not looking pretty, I have a solution for you - read on. To fix this a command 'fc-list : family' should be used instead, to come up with a list like this: There are two solutions (and I'm sure there are more) - you can decide which one to pursue depending on your expertise. As the Icon Editor in LV2016 (starting with LV2011 I think) is in packed library for execution optimizing purposes, the Icon Editor code can't directly be altered to fix this. One can come up with a solution where the command 'fc-list' is overridden in linux so it will always use the (proper for LabVIEW) format 'fc-list : family'. This may have some unwanted side effects if other programs use the command in similar fashion, so this may not be the best solution. It would be pretty easy to use for assessing whether this could be your problem also. There are multiple trivial ways of implementing this, so I won't be giving an exact solution - here is a list of them: https://lmgtfy.app/?q=override+command+in+linux Darren Nattinger has provided the source code for Enhanced Icon editor in https://forums.ni.com/t5/Enhanced-Icon-Editor/Icon-Editor-Source-Files-for-LabVIEW-2016/m-p/3538808 - You can replace the packed library LabVIEW uses as editor with this source. There are easy 3 step instructions on the site - even I managed to do that. Please give kudos to Darren should you go this way. When you have the shipped Icon Editor replaced with the source, you can directly edit the file in /usr/local/natinst/LabVIEW-2016/resource/plugins/NIIconEditor/Miscellaneous/Font/Linux.vi so it uses the correct form, like this:
    5 points
  2. I like resizable UIs, and that often means custom code to handle some of the operations in the UI. One such feature I like is a vertical array, that shows more rows, as the window size gets larger and can show more. I've used code like this a few times and figured the community might like it too. When doing this there are times when I want a user to be able to add more rows, and some times that it needs to either be static, or set by some other outside variable. So in this demo is also a way to link a vertical scrollbar that is a separate control, and have it move, and get set, so that it looks like it is linked to the array control. But this will coerce, and not allow more rows to be seen, than the number of elements in the array. At the moment this only supports 1D arrays, and only in the vertical direction. Code is saved in 2020. Array Resize and Scrollbar Link.zip
    3 points
  3. Or even better: Replace "Write To Text file"/"Read From Text File" with "Write To Binary File"/"Read From Binary File". The output of "Flatten to String" is not text. (String != Text)
    3 points
  4. Right-Click on the "Read From Text File" method and unselect "Convert EOL". The number "13" (0xD or Carriage Return) gives it away. If you look at the HEX representation of what you save and what you read from file, you'll notice the 0xD gets converted to 0xA unless you uncheck that box. Tip: If you deal exclusively with HEX/binary data, you might want to save it using byte arrays instead. The result will be the same in your file, but you won't get bitten by hidden config parameters in your node...
    3 points
  5. LabVIEW Software Engineers, here's your opportunity to work with us at SpaceX! I'm hiring for a Sr. Software Engineer on the Ground Software team. We build control and monitoring systems running the Falcon launchpads, mission systems launching astronauts to the International Space Station onboard Dragon, and a fleet of sea-faring recovery vessels bringing spacecraft and rockets back to shore. The screens you see in Mission Control are the UIs we build. Read more about the role and apply here: https://boards.greenhouse.io/spacex/jobs/5480997002?gh_jid=5480997002
    3 points
  6. I just have to add this fun vim using your (@drjdpowell) SQLite library. It's LINQ for LabVIEW (I only spent 20 minutes on it so it's a bit rough) LcArray_LINQ.vim
    2 points
  7. New in LabVIEW 2020: C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\picture\PNG\Draw Flattened Blended Pixmap.vi I didn't create this one. It is not in the palettes. I have asked that it be added in a future version.
    2 points
  8. Hi Lavans I'm working on releasing our Medulla ViPER Dependency Injection Framework to the community as an open source project. ViPER has been a labor of love that I have been working on for close to 8 years. The motivation to develop ViPER was to reduce the cost, time and frustration involved in deploying test systems in highly regulated industries such as medical device manufacturing. The big problem that ViPER solves is that change does not require you to perform a full top to bottom verification of the system, only the new or changed component needs to be verified. We used ViPER at Cochlear to test implants and sound processors and is the standard architecture used within the enterprise. ViPER was also used to develop a system to parallel test up to 100 Trophon 2 units simultaneously for Nanosonics by implementing a Test Server running on an NI Industrial Controller. HMI Clients were implemented on tablets for operators, engineers and admins. Although ViPER is useful for test its not used just for test systems, you can build any system with ViPER. ViPER is a plugin architecture, it implements a recursive factory creator that injects pre-built (and verified) components into a system at runtime defined by a Object Definition Document. ViPER can build rich and deep object hierarchies, even inject into ancestors as well. Components include soft front panels and attribute and configuration viewer and are built on GDS4 class architecture. ViPER systems are also slim and efficient because they are not carrying around redundant classes in their builds that may or may not be needed. ViPER includes an Object Editor that allows you to create or edit the Object Definition Document but is also a useful engineering tool allowing you to navigate the object hierarchy, configure and launch Soft Front Panels for any sub objects. Included is a Project template that allows you to create your own ViPER Components. I presented ViPER the GLA Summit last year and to the Sydney LabVIEW User Group, I've posted the Video of the presentation on LinkedIn, I'm keen to find a few gurus to have play with it before I release it. ViPER: A Dependency Injection Framework for LabVIEW Cheers Kurt
    2 points
  9. Fortunately Dataflow G have released this toolkit - dataflowg/g-audio: An audio library for LabVIEW. (github.com) It satisfies all the requirements ๐Ÿคฉ!!!
    2 points
  10. New version with sequence Init -> Update -> Final. P.S. I tried EVP interface but is in stuck with EVP_MD_CTX structure definition in LV. https://github.com/theos/headers/blob/master/openssl/evp.h MD5_my5.vi
    2 points
  11. Another option... Use a third party installer. InnoSetup works really well.
    2 points
  12. This is expected behavior: Ensure That Event Structures Handle Events whenever Events Occur - LabVIEW 2018 Help - National Instruments (ni.com) You are probably right about compiler optimization for unreachable code. Changing the compiler optimization level most likely has no effect because it is still unreachable and therefore not included.
    2 points
  13. I came across this topic whilst trying to figure out the text width for UTF-16 strings - the solution we used was to write the text/font to the caption of a string control with 'size to text' enabled and then read the Caption.Area Width property: I think the only issue is that LabVIEW adds a few pixels of spacing around the caption - but I think this will be a constant that can be removed.
    2 points
  14. I take it you don't have a dedicated connection between the two devices. Things that can break the system that come to mind is the routing and if there are duplicate IP addresses on the network.
    2 points
  15. I don't quite have a working example but the logic for allocation and deallocation is pretty much as explained by JKSH already. But that is not where it would be very useful really. What he does is simply calculating the time difference between when the VI hierarchy containing the CLFN was started until it was terminated. Not that useful really. ๐Ÿ˜€ The usefulness is in the third function AbortCallback() and the actual CLFN function itself. // Our data structure to manage the asynchronous management typedef struct { time_t time; int state; LStrHandle buff; } MyManagedStruct; // These are the CLFN Callback functions. You could either have multiple sets of Callback functions each operating on their own data // structure as InstanceDataPtr for one or more functions or one set for an entire library. Using the same data structure for all. In // the latter case these functions will need to be a bit smarter to determine differences for different functions or function sets // based on extra info in the data structure but it is a lot easier to manage, since you don't have different Callback functions for // different CLFNs. MgErr LibXYZReserve(InstanceDataPtr *data) { // LabVIEW wants us to initialize our instance data pointer. If everything fits into a pointer // we could just use it, otherwise we allocate a memory buffer and assign its pointer to // the instanceDataPtr MyManagedStruct *myData; if (!*data) { // We got a NULL pointer, allocate our struct. This should be the standard unless the VI was run before and we forgot to // assign the Unreserve function or didn't deallocate or clear the InstanceDataPtr in there. *data = (InstanceDataPtr)malloc(sizeof(MyManagedStruct)); if (!*data) return mFullErr; memset(*data, 0, sizeof(MyManagedStruct)); } myData = (MyManagedStruct*)*data; myData->time = time(NULL); myData->state = Idle; return noErr; } MgErr LibXYZUnreserve(InstanceDataPtr *data) { // LabVIEW wants us to deallocate a instance data pointer if (*data) { MyManagedStruct *myData = (MyManagedStruct*)*data; // We could check if there is still something active and signal to abort and wait for it // to have aborted but it's better to do that in the Abort callback ....... // Deallocate all resources if (myData->buff) DSDisposeHandle(myData->buff); // Deallocate our memory buffer and assign NULL to the InstanceDataPointer free(*data) *data = NULL; } return noErr; } MgErr LibXYZAbort(InstanceDataPtr *data) { // LabVIEW wants us to abort a pending operation if (*data) { MyManagedStruct *myData = (MyManagedStruct*)*data; // In a real application we do probably want to first check that there is actually something to abort and // if so signal an abort and then wait for the function to actually have aborted. // This here is very simple and not fully thread safe. Better would be to use an Event or Notifier // or whatever or at least use atomic memory access functions with semaphores or similar. myData->state = Abort; } return noErr; } // This is the actual function that is called by the Call Library Node MgErr LibXYZBlockingFunc1(........, InstanceDataPtr *data) { if (*data) { MyManagedStruct *myData = (MyManagedStruct*)*data; myData->state = Running; // keep looping until abort is set to true while (myData->state != Abort) { if (LongOperationFinished(myData)) break; } myData->state = Idle; } else { // Shouldn't happen but maybe we can operate synchronous and risk locking the // machine when the user tries to abort us. } return noErr; } When you now configure a CLFN, you can assign an extra parameter as InstanceDataPtr. This terminal will be greyed out as you can not connect anything to it on the diagram. But LabVIEW will pass it the InstanceDataPtr that you have created in the ReserveCallback() function configuration for that CLFN. And each CLFN on a diagram has its own InstanceDataPtr that is only valid for that specific CLFN. And if your VI is set reentrant LabVIEW will maintain an InstanceDataPtr per CLFN per reentrant instance!
    1 point
  16. @Rolf Kalbermatter has the answer, as usual: The parameter type is a pointer-to-InstanceDataPtr (i.e. a pointer-to-a-pointer, or a Handle in LabVIEW terms). LabVIEW owns the handle, you own the data pointer: You allocate the data in Reserve and you can access that same data in Unreserve/Abort. LabVIEW can't free your pointer since it doesn't know the type/size of your data. // C++ example #include <ctime> MgErr reserveCallback(InstanceDataPtr* instanceState) { if (*instanceState == nullptr) { time_t* start = new time_t; *start = time(nullptr); *instanceState = start; } else { // We should never reach this point, unless the InstanceDataPtr was not cleared after the last run } return 0; } MgErr unreserveCallback(InstanceDataPtr* instanceState) { time_t end = time(nullptr); time_t* start = static_cast<time_t*>(*instanceState); // Calculate how much time has passed between reserving and unreserving double elapsedSecs = difftime(end, *start); // Note: The handle must be explicitly cleared, otherwise the LabVIEW IDE will pass the old pointer // to reserveCallback() when the VI is re-run delete start; *instanceState = nullptr; return 0; }
    1 point
  17. This is how I include the RTE as part of an installer. Note: outside of the scope of the installer I manually unpack the relevant NI distributed RTE
    1 point
  18. I would definitely not use a Swap Values here as it just makes the code confusing. Of the three I think the top is the most natural (but there is something about the inner dequeue which does not sit well with me).
    1 point
  19. Is it ever conceivable that there will be more than two Queues to monitor? If so then the last one would scale up better. That being said it isn't the one I'd find myself using, just because the other two are much more readable. I'd probably go with the first one. Swap values is pretty handy when you actually need to swap two values. Here you aren't really using one of the values. From a memory or speed perspective I bet you can't measure the small amount of difference (if any) that is taking place.
    1 point
  20. Well, if you have the source code for the GenericDevice_DLL_DEMODlg program you may be able to verify that which function pointer is assigned which DLL function. Without that it is simply assuming and things and there is "ass" in the word assuming, which is where assumptions usually bite you in! ๐Ÿ˜€
    1 point
  21. Here is a helper routine that I wrote yesterday based on the other VI. It's the world's most inefficient way to draw a rectangle but it works, and if you're trying to do some sort of animation fade effect, you can do it with this by putting in decreasing opacity. Draw Blended Rectangle.vi
    1 point
  22. 1 point
  23. I would investigate cosmos. I haven't migrated a complete project to it yet but I'm implementing data collection, storage and telemetry GUIs to it for a new project working with python and FPGA programmers. A lot of the python programmers use python and it as a replacement for LabVIEW/TestStand. I haven't used their Script-Runner (TestStand-ish stuff) but the current version is highly capable for data collection, saving, presentation, limit checking. They are working on cosmos 5 which will run in a docker container and have web based gui's
    1 point
  24. Oh this is a great idea and something I was able to do pretty quickly in XMouse Control. So previously I had mine configured so that the middle click would invoke <CTRL><Space> so that I could middle click and bring up the quick drop. I also have it so that if you press the back and forward buttons on your mouse, it will cycle through the cases of an event structure, or case structure. But this was a pretty easy thing to change the middle mouse to perform a pan instead. Attached is my config but it personally won't be helpful for me since I am a non-auto tool guy, and it requires auto-tool to be on. Just go download the X Mouse utility and use this config which should only get enabled when LabVIEW.exe is the active application. And if you are interested in the Middle click invoking QuickDrop go checkout the config I posted on the dark side. EDIT: Oh another thing I noticed is this only works if you use the middle click when on blank space. If you try to pan on an object it will copy it. LabVIEW Pan and Case Turn.xmbcs
    1 point
  25. Here is my minor contribution. Following a thread on the NI forums it seems Open SSL support when installed (through MAX as an optional software package) the compatible binary is libeay32.so. So I updated the code to remove the Get/Set file positions, and specify the file path using a conditional disable structure. I tested it this morning on my RT VM and it worked great. The same 1.4GB file took 20s using native G and only 2.2s using the Open SSL version. MD5_my8.vi
    1 point
  26. Thanks a lot, guys! EVP is working now! md4 md5 sha1 sha224 sha256 sha384 sha512 can be calculated. Quite convinient and fast utility for file integrity check can be created in this way. Should we point NI to this (hash calc through EVP interface) via Idea Exchange ? MD5_my7.vi
    1 point
  27. Since you don't access the internal elements in the struct at all from LabVIEW you just can treat it all as a pointer sized integer. In fact since OpenSSL 1.0.0 all those structs are considered opaque in terms of external users of the API and should never be referenced in any way other than through published OpenSSL functions. In terms of an external API user these contexts are meant to be simply a handle (a pointer to private data whose contents is unknown). EVP_MD_CTX_create() creates the context -> just configure it to return a pointer sized integer. Then pass this to all other EVP functions again as pointer sized integer. And of course don't forget to call the EVP_MD_CTX_free() function at the end to avoid memory leaks.
    1 point
  28. It's essentially the same as what QueueYueue posted. And it has the same problem, it won't work at runtime. "LVClass.Open" is not available in Runtime and Realtime (Library: Get Ref by Qualified Name is available but not remote executable, but typecasting to LVClass won't work since the Runtime and Realtime does not support that VI server class). "ChildrenInMemory" is not available in Runtime and Realtime All LVClass properties and methods are not available in Runtime and Realtime
    1 point
  29. ShaunR, thanks for the idea sharing! Hoovah, code is attached (was deleted because of memory error with large >1GB files, use new version (MD5_my5.vi) posted in message below).
    1 point
  30. Well. the output of the python hmac is a byte array and the output of the LV hmac is a hex string so I expect you have to convert the LV hmac output into a byte array before passing it to the encode like this: Generate Signature.vi By the way. None of your sources (message or key) are base64 encoded so you may run into errors when trying to b64decode normal text.
    1 point
  31. There are some primitives but not easy to get to, so here they are. UTF8 LV80.vi
    1 point
  32. At a guess I expect it's because you are decoding with UTF-8 in your python. I checked the HMAC library you are using and it produces the correct hashes for test vectors.
    1 point
  33. As Shaun already more or less explained it is a multilayered problem. 1) The LabVIEW path control has internally following limitations: - a path element (single directory level or filename) can be at most 255 characters. - the path can have at most 65535 levels The only practical limit that is even remotely ever reachable is the 255 character limit per path level, but I think we all agree that if you get that long path level names you have probably other problems to tackle first. ๐Ÿ˜€ (such as getting out of the straightjacket they for sure have put you in already). 2) Traditionally Windows only supported long path names when you used the Widechar file IO functions and also only when you prepended the path string with a special character sequence. LabVIEWs lack of native support for Unicode made that basically impossible. Long path names are limited to 32000 something characters. 3) Somewhere along the line of Windows versions (7, 8?) the requirement for the special character sequence prepending seems to have relaxed. 4) Since Windows 10 you can enable a registry setting that also allows the ANSI functions to support long path names. So while theoretically there is now a way to support long path names in LabVIEW on Windows 10 this is hampered by a tiny little snag. The path conversion routines between LabVIEW paths and native paths never had to deal with such names since Windows until recently didn't support it for the ANSI functions, and there are some assumptions that paths can't get more than MAX_PATH name characters. This is simply for performance. With a maximum fixed size you don't need to preflight the path to determine a maximum size to allocate a dynamic buffer for, that you then have to properly deallocate afterwards. Instead you simply declare a buffer on the stack, which is basically nothing more than a constant offset added to the stack pointer and all is well. Very fast and very limiting! This is where it is currently still going wrong. Now reviewing the path manager code paths to all properly use dynamically allocated buffers would be possible but quite tedious. And it doesn't really solve the problem fully since you still need to go and change an obscure registry setting to enable it to work on a specific computer. And it doesn't solve another big problem, that of localized path names. Any character outside the standard 7-bit ASCII code will NOT transfer well between systems with different locales. To solve this LabVIEW will need some more involved path manager changes. First the path needs to support Unicode. That is actually doable since the Path data type is a private data type so how LabVIEW stores path data inside the handle is completely private and it could easily change that format to use whatever is the native prefered Unicode char for the current platform. On Windows this would be a 16 bit WCHAR, on other platforms it would be either a wchar or an UTF8 char. It wouldn't really matter since the only other relevant platforms are all Linux or Mac BSD based and use by default UTF8 for filenames. When the path needs to be externalized (LabVIEW speak is flattened) it always would be converted to and from UTF8 to the native format. Now LabVIEW can convert its Path to whatever is the native path type (WCHAR string on Windows, UTF8 string on other platforms) and it support long path names and international paths all in one go. The UTF8 format of externalized paths wouldn't be strictly compatible with the current paths, but for all practical purposes it would be not really worse than it is now. The only special case would be when saving VIs for previous versions where it would have to change paths from UTF8 to ASCII at a certain version. I kind of did attempt to do something like that for the OpenG ZIP library but it is hacky and error prone since I can't really go and change the LabVIEW internal data types, so I had to define my own data type that represents a Unicode capable path and then create functions for every single file function that I wanted to use to use this new path, basically rewriting a large part of the LabVIEW Path and File Manager component. It's ugly and really took away most of my motivation to work on that package anymore. I have another private library that I used in a grey past to create the LLB Viewer File Explorer extension before NI made one themselves, and I have modified that to support this type of file paths. Works quite well in fact but it is all very legacy by now. But it did have long file name and local independent file name support some 15 years ago already with an API that looked almost exactly like the LabVIEW File and Path Managers.
    1 point
  34. Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.
    1 point
  35. And also, its not silent. Creating a file or writing to a file with too long path name will give you error 6.
    1 point
  36. Here is a Labview program that I found very useful. I made minor modifications to make it more useful to me. Its core is LIBSVM by Chih-Jeh Lin and Kiwoong Kim. Since writing these, I developed some further advancements but I haven't wrapped those in a neat package yet. Let me know if you're interested. Labview4LIBSVM Folder.zip
    1 point
  37. I am involved in 2 different community events coming up soon and I just wanted to get the word out. The first is an in-person conference and that is GDevCon N.A. This is following in the footsteps of the original GDevCon in Europe, except it is going to take place in Boulder CO on Oct 20,21. We have a speaker lineup with a lot of the usual suspects. You'll recognize most of them, but there are a few newcomers as well. We also have some workshops going on. You can get more information and purchase tickets at https://gdevconna.org We are also still accepting sponsorships if anyone is interested. I realize a lot of people either aren't able or are hesitant to travel to GDevCon N A. If so, you are in luck. There is virtual event coming up on Nov 15/16 and that is the GLA Summit. It sprouted up last year in response to NI cancelling the CLA Summit due to COVID. It promises some great presentations and is open to all LabVIEW and TestStand Enthusiasts. It is a fully online event that lasts for 24 hours. We are still looking for presenters. You can register or a submit a presentation at https://glasummit.org Hope to see you all at one or both of these. If you have any questions on either, post them here and I'll try to get you some answers. Sam
    1 point
  38. 1 point
  39. Would you be willing to post what the solution was?
    1 point
  40. SOLVED. Thank you guys for your usful comments.
    1 point
  41. You could probably take a look at this: https://forums.ni.com/t5/Machine-Vision/Convert-JPEG-image-in-memory-to-Imaq-Image/m-p/3786705#M51129 For PNGs there are already native PNG Data to LV Image VI and LV Image to PNG Data VI.
    1 point
  42. View File BlueSerialization Serialize and deserialize LabVIEW classes using either JSONtext or TOML Official documentation: https://github.com/justiceb/BlueSerialization Submitter bjustice Submitted 08/05/2021 Category General LabVIEW Version 2018 License Type BSD (Most common)  
    1 point
  43. I would suggest moving this into another thread. The title of this thread is about an Open Source test executive, and you clearly state that you have no plans to ever open source it.
    1 point
  44. If you are a student, I'm pretty sure there are boring tasks that can be automated. Something that's special so you are not likely to find existing tools. But since you are a student, simply reinventing something, cloning a board game you like (I make minesweeper in pretty much any programming languages I work with), remaking msPaint is not a "stupid" decision as it would be as a pro. For example for work, I did a picture manager program. Pictures can drag+drop sorted, comments can be assigned, picture entries can be colored (for marking purposes), images can be cropped with arbitrary angled rectangles. And all pictures can be inserted into a Word document using the report generation toolkit and some VB scripting. This is just a small tool but it can be extended infinitely and has lot of areas that you can practice. And doesn't need any hardware (measurement or controller devices). Just a computer. EDIT: in general, Labview is a pretty productive language for GUI heavy applications. Graphs are very typical Labview things and they can be customized beyond a mere measurement plotting widget. So for a student project I would prefer something that involves graphs in some ways, usual or unusual ways (like some task scheduler or fancy calendar-thing, just throwing ideas). Another idea is making some cellular automata, like Conway's game of life. You could and controls to it, maybe even drawing the initial filled cells (you have to solve the rendering of the field: table?/graph?/picture? and you have to handle mouse clicks) and add some additional graphs that plot some interesting data vs. time diagrams. Like the percentage of alive cells, or whatever. Maybe you could also make some overlay heat map on the field to see if there are places that alive cells are more common. You could add a menu to switch between different automatas. Maybe adding an option of hexagonal field. Man, now I want to make it ๐Ÿ˜ฃ
    1 point
  45. Here is one that involves a nice mix of small challenges: My first assignment after being hired as an engineer back in 1998 was to write a multiplexer and demultiplexer. In that case we had 8 instruments outputting readings as an ASCII string every second (fixed length message containing a numeric value: "AA 2500BB\r\n"), and all those strings had to be read from 8 separate serial ports, tagged with a channel (c1, c2, c3 etc..) and then sent on through a single serial link (because we physically only had two wires available) to another PC where the signals would be split into the original 8 live values...Unless you are already familiar with serial IO you might want to simulate the physical parts at first to finish the downstream logic, then you can add the physical / serial communication bits at the end (in case you end up spending too much time on that to finish everything).
    1 point
  46. You can also use Quick Drop Replace to replace multiple items at once. Select all the controls you want to replace > Ctrl-Space > Type name of new item > Ctrl-P to replace them all.
    1 point
  47. More info here: https://forums.jki.net/topic/2679-vipm-2017-for-linux-is-here/
    1 point
  48. This is a recorded webcast from Trevor Christman, a member of LV R&D on the Language Team with me. In this webcast, Trevor lays out the basic ideas behind OOP, explains how these are implemented in LabVIEW, and shows off parts of the LabVIEW user interface. This is an excellent presentation, and may help those of you who don't enjoy reading documentation learn the power of LVOOP. I fielded questions during the presentation, which you can see scrolling past in the chat window. http://zone.ni.com/w...oc/p/id/wv-1766 [EDIT] There is a sequel presentation now: http://zone.ni.com/wv/app/doc/p/id/wv-2003
    1 point
  49. There appeared to be an issue in the posted version of the library. I sent secr1973 the latest version and it is working for him. I have attached the latest version of the library. snmp communication.llb
    1 point
×
×
  • Create New...

Important Information

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