Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 08/20/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. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Fortunately Dataflow G have released this toolkit - dataflowg/g-audio: An audio library for LabVIEW. (github.com) It satisfies all the requirements 🤩!!!
    2 points
  8. 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
  9. 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
  10. 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
  11. 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
  12. Don't forget versions, updates and patches, particularly in operating systems. For example... had a customer call me with a station that was down after a couple years of running. It looked like a UDP communication issue between two PCs. Wireshark showed the UDP message showing up at the port, but the application didn't receive it. Eventually this was tracked down to the build of Windows 7 (1609, if I recall right) can randomly turn off a setting that UDP needed to work. The "fix" involved a registry edit, but it's waiting to happen again.
    2 points
  13. 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
  14. 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
  15. 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
  16. 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
  17. We’re looking at making our Medulla ViPER test executive open source. I presented the ViPER architecture and test executive to the Sydney LabVIEW User Group. You can view the presentation in the link below ViPER Test Executive Presentation I’m hoping to have this released before the end of the year but I’d be keen to have some early adopters.
    1 point
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. There are some primitives but not easy to get to, so here they are. UTF8 LV80.vi
    1 point
  24. 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
  25. 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
  26. Another option... Use a third party installer. InnoSetup works really well.
    1 point
  27. 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
  28. 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
  29. 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
  30. 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
  31. 1 point
  32. Would you be willing to post what the solution was?
    1 point
  33. SOLVED. Thank you guys for your usful comments.
    1 point
  34. 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
  35. Most relaxing Q&A session of all... 15 minutes of background music. That was necessary to let the breadth and depth of the new features which were crammed within the first 30 min sink in. I was actually quite impressed that NI finally was on the right track as to what an autowire tool is supposed to do. Not that I am planning to turn it on, but pleasantly surprised nonetheless. The important link is this: https://www.ni.com/en-us/support/documentation/bugs/21/labview-2021-known-issues.html 1135156 is nasty... 1555422 is sort of amusing for that new functionality. But I guess that is what happens when the feature is not advertised in the public beta site (https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/LabVIEW-2021-Beta-Now-Available/td-p/4144143) I believe the "Final Time issued" section is new?
    1 point
  36. No it's not. A .Net DLL is not supposed to change location in build applications. .Net itself only knows really two locations by default where it will search for assemblies: - The directory in which the current executable file is located - The GAC Anything else is extra, such as an non-default AppDomain with its custom ApplicationBase. LabVIEW adds to this the option to reference Assemblies by full path (which the application builder adjusts to the location you configured the assembly to be installed to) but that path is embedded in the compiled VI and not accessible just as you can't change the path of subVIs in a compiled executable either.
    1 point
  37. So normally I would start thinking about what had changed in the whole environment so that it will not work anymore. Were there an IT Firewall update?? Some Anti-Virus Software Updates? Have you or someone else changed the code? The hardware? The connection? Normally an Application does not behave different if nothing changes.
    1 point
  38. 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
  39. 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
  40. 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
  41. VISA is ok but not everyone uses it so...
    1 point
  42. 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
  43. How about something with the File IO? Maybe copy all files and folders from one location to another and list the files that were new or overwritten? Maybe open a text file with times and values in it then graph it? Maybe import a text file into a table and color the values that are greater than some value red, and lower than some value green?
    1 point
  44. Finally here it is. Refnum_to_Pointer-Linux.zip Refnum_to_Pointer-MacOS.zip Tested in LV 2020 on Ubuntu 20.10 and macOS Big Sur. It's assumed to work in 64-bit editions of LabVIEW only.
    1 point
  45. I have checked the LabView version and it was the full version not the pro version. After installing the pro version appbuilder works just fine. Here is how i installed it using alien and dpkg. mount lv2020pro-linux.iso /media/cdrom0 cd /media/cdrom0/ sudo mkdir /home/ll/Downloads/Software/labviewpro sudo cp -r * /home/ll/Downloads/Software/labviewpro/ cd /home/ll/Downloads/Software/labviewpro/ sudo rm ni*i386.rpm sudo alien -k -c *.rpm sudo -s dpkg -i labview-2020-core_20.0.0-1_amd64.deb dpkg -i labview-2020-desktop_20.0.0-1_amd64.deb dpkg -i labview-2020-exe_20.0.0-1_amd64.deb dpkg -i labview-2020-pro_20.0.0-1_amd64.deb dpkg -i labview-2020-ref_20.0.0-1_amd64.deb dpkg -i labview-2020-rte_20.0.0-1_amd64.deb dpkg -i labview-2020-help_20.0.0-1_amd64.deb dpkg -i labview-2020-examples_20.0.0-1_amd64.deb dpkg -i labview-2020-appbuild_20.0.0-1_amd64.deb dpkg -i lvsupport2020-vianalyzer_20.0.0-f32_amd64.deb dpkg -i ni*.deb I want to thank everyone for their replys.
    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. 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.