Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 07/01/2021 in Posts

  1. Two questions about this: 1. Does something like this already exist? 2. Is this something that could be useful? Every once in a while I need dynamic UI components that can be generated at runtime. One nice thing to use for this is a picture control; however it doesn't lend itself as well to keeping other pieces of function such as mouse click events and such. I put together a mini library of UI functions for this that has the ability to be extended. The UI can be generated dynamically at runtime and be any picture thing that you can draw. Using Standard layout techniques that you might find in other GUI libraries. The hierarchy generation can always be simplified by using some type of templating string. Example1.vi Front Panel on Pgui2.lvproj_My Computer _ 2021-07-02 14-03-54.mp4
    5 points
  2. I don't understand this website. They are pushing this whole "chat with other attendees", but there are no chatrooms? You have to search for someone by name?
    2 points
  3. Tom McQuillan offers a tool that helps with updating VI descriptions and icons: https://github.com/TomsLabVIEWExtensions/Documentation-Tool AntiDoc by wovalab (Olivier Jourdan) generates very nice and extensive documentation for DQMH modules, LV classes and .lvlibs. Here's an example PDF of our open-source application template.
    2 points
  4. https://meh.com/forum/topics/building-the-plane-on-the-way-up tl;dr the ground based decoder for some of the comms on Voyager was built *after* the craft was launched, and it still to this day reliably receives data. Wow!
    2 points
  5. We've been calling 3.9 with LabVIEW 2019 without a glitch. Not exactly sure what "support" means in this context. _ _ _ Different topic... If the statement below were a regular expression, wouldn't a "?" be more appropriate? It would stand a better chance of matching at least one element 😉
    1 point
  6. I'm attaching some of Rolf's VIs from years ago. They do include code for writing an image to the clipboard (see the example in clipbrd.llb and look at the control or panel buttons). This would probably require adapting if you're on 64 bit LV. Clipboard - RolfK.zip
    1 point
  7. Maybe not a new feature, but somewhere in the talk they mentioned a 2021 LabVIEW license would give you access to Windows, Linux, and Mac versions, no separate purchases required.
    1 point
  8. Not checking the signature seems like a potential security risk as someone could swap in a tampered PLL and potentially the caller wouldn't notice and that "hack" could go undetected. https://en.wikipedia.org/wiki/Arbitrary_code_execution Also I noticed the PPL can use VI server to monitor/manipulate it's caller. Here's an example VI that could be injected into a PPL VI. It seems to me that a PPL shouldn't get access to its caller.
    1 point
  9. And it will be the highest numbered icon to date.
    1 point
  10. Better GIT integration is fine, I use TortoiseGIT and have had LVCompare integrated for several years. Shame LVCompare is only available to those with a Professional license, LVCompare should be available on all licenses, to encourage use of SCC.
    1 point
  11. There is support for Sets and Maps in the latest version; I wouldn't want such things require any kind of "hook".
    1 point
  12. A paean to the utility of JSONText.
    1 point
  13. Alternative (6): all attributes are returned as JSON values. Rather than get the attribute as the actual type, the User would get the attribute as a string, then use From JSON to convert to type. One could make VIMs that combine these two steps, and these VIMs might possibly be made to work with non-JSON attributes as well.
    1 point
  14. I think AQ is enjoying this role as the end user instead of the LV programmer 🤣 I do appreciate following these edge cases though. I use this tool widely and it is fantastic.
    1 point
  15. Then you are already more advanced than the average programmer. What you will see? Or how long it will take to make it right? Sub VI, sub VI, sub VI. Look for reuse. Take a very small section and make it a sub VI (only one click). Clean it up. Nibbling old code from spaghetti to sub VI's has huge benefits. Don't do it all at once. A little clean up goes a long way. Do a sub VI every week or month. I can guarantee you've rewritten the same behaviors and data manipulations many times in the past; probably even within the same application. As you create the sub VI's you will start to notice some of them are very similar. Look to see if you can make them identical. This is a heuristic way of creating code reuse. Then you can start looking for old code that you have turned into a sub VI that look similar to your current project. Your old code is a test harness for your code snippets. It's been proven to work, right? Once you have it working correctly in both old and new; fill out the documentation, icon etc if you haven't already and put comments in it. Then stick it in your special toolbox for reuse. You don't need to publish the modified old code but as you gain confidence in your toolkit, you will merge the reuse code into it. If you change the reuse code, run the old software to make sure it still works correctly. This is called Black Box Testing. Old code is very useful. It's proven code that works. Cleaning it up and sub VI'ing it will benefit your current and future projects too. You will eventually be able to spot reuse code candidates as you create new VI's - the patterns will jump out at you. You will look like you were a master from day one when other people look at your old code. Only you and your source control system will know the truth .
    1 point
  16. The code underneath is definitely NOT thread safe. It's concerning the Text Manager, another subsystem of the LabVIEW GUI system and the entire GUI API is UI_THREAD since the Windows GDI interface, which these functions all call ultimately weren't thread safe either back then and may in various ways still not be. Windows has some very old legacy burdens that it carries with it that Microsoft tried to work around with the Windows NT GDI system but there are a few areas where you simply can't do certain things or all kind of hell breaks loose. Now I happen to know pretty much how this function is implemented (it simply calls a few other lower level undocumented LabVIEW Text Manager functions) and incidentally they are all still exported from the LabVIEW kernel too. When you use a user font it calls TNewFont() to create a font description, then it basically calls TTextSize() to calculate the Point describing the extend of the surrounding box and afterwards it calls TDisposeFont() to dispose the font again if it created it in the first place. For the predifined fonts it skips the font creation and disposal and uses preallocated fonts stored in some app internal global. So there would be a possibility to cut down on the repeated execution time of GetTextRect() call for user defined fonts by only creating the font once and storing it in some variable until you don't need it anymore. No joy however about reducing TTextSize() execution time itself. That function is pretty hairy and complex and does quite a bit of GDI calls, drawing the text into hidden display contexts, to determine its extend.
    1 point
  17. Looks like that info was taken from this link: https://forums.ni.com/t5/NI-Linux-Real-Time-Documents/Touch-Screen-Troubleshooting-NI-TSM-1015/ta-p/3537931?profile.language=en
    1 point
  18. Hi Neil, The TSM-101x calibration issues have caused me no end of problems. It'll lose calibration if the USB cable is unplugged and plugged in while the cRIO is on. It'll lose calibration if you run the calibration utility twice in a row. It was impossible to calibrate at all running on an older version of CompactRIO drivers (I think 18.0 didn't work, but 19.0+ does). I've raised all these issues previously but only get back the same set of KB articles, and they don't solve anything - manual edits to the 99-calibration.conf file don't work, or simply cause the screen to go black. The only reliable solution I've found was from distributor support (not direct NI support - that doesn't exist any more). It uses a different calibration program called gCal. Again it's very command line based, but at least it works. Copied and pasted from the support email: Software stack: NI CompactRIO 20.0 Reference: Touch Screen Troubleshooting - NI TSM-1015 Pre-work: (login with SSH and run the commands below) Remove xinput_calibrator opkg remove --nodeps xinput-calibrator Install bzip2 opkg update opkg install bzip2 Install Penmount 6000 USB Drive for Linux (X11): (login with SSH and run the commands below) Check the X.Org version export DISPLAY=:0 xdpyinfo | grep version X.Org Version should be 1.19.6 in 20.0 stack Install Driver wget https://www.salt.com.tw/tw/wp-content/uploads/sites/2/2017/10/PenMount-Debian-9_32-64bit_driver-v4.5.7_R6.tar.bz2 tar -xjf PenMount-Debian-9_32-64bit_driver-v4.5.7_R6.tar.bz2 cp pmLinux-Debian9/x86_64/24.1/penmount_drv.so /usr/lib/xorg/modules/input/ chmod +x pmLinux-Debian9/x86_64/* cp pmLinux-Debian9/x86_64/* /usr/sbin/ pm-setup -s Reboot the cRIO Start calibration export DISPLAY=:0 gCal 4 Another thing you might try is swapping the USB cable for a different one. This managed to fix up a calibration issue in one of our systems. Sorry for the rant at the start, but this has got to be one of NI's most poorly supported products (except for maybe the Functional Safety Editor - that's built on the bones of NXG, and we know how that turned out).
    1 point
  19. Note: latest version supports comments. https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39
    1 point
  20. Ah, this can be illustrated with this image: JSONtext does not follow the common error rule of returning default value on any error. Instead, it returns best-efforts, with only sub-elements that produce errors being returned as the supplied default. Here it is only the "B" element, requested as a Float but a String in the JSON, that is returned as default (as explained in the error message). Thus we are doing the Variant-to-Data even on error, in order to get this partial conversion of JSON to Data.
    1 point
  21. Down here, you can't really hire a good LabVIEW programmer; all 10 of them have jobs they don't want to leave, so you'll just have to make your own. That's often easiest if that person has no LV experience. In that case you know they haven't been poisoned by "that uni course" they did where most certainly single-vi spaghetti with lots of local variables for "storing data" was the result. Candidate must have good understanding of generic concepts and not make a face when quizzed about graphical programming
    1 point
  22. Interesting idea, I've made a quick implementation of it just for fun. This might actually be usefull on touch screen GUIs, I need to explore that. DragNumeric.vi
    1 point
  23. I should have put a smiley at the end of my sentence 😅
    1 point
  24. I am not *that* paranoid, but certainly I like to push my work at the end of each day. I am not actually anti-git, it is just taking me a while to get used to its best practices and nuances.
    1 point
  25. Depends on what the server's role is, right? If the server is my cloud backup, then yes I should push all local branches to the server all the time. If the server is hosting a large open-source project that I'm contributing to, then I'm usually not allowed to push my changes to the server until I've finished everything. If the server is hosting my public project releases, then I keep my WIPs and experiments local, and I only push "polished" (possibly squashed/amended) commits. That last scenario minimizes low-quality commits like "Fix typo in previous commit" that make commit history difficult to read and bloat the repository size -- this is especially important with LabVIEW, where each VI change could potentially increase the repo size by 100s of KB, leading to multi-GB repositories very quickly.
    1 point
  26. I added what I have to https://github.com/taylorh140/Pgui. It's only right since I copied the enabling technology right from this forum. I don't know if ill have a huge amount of time to work on this but ill defiantly try and improve it when I can. There is still a lot of things that would be nice to develop for this.
    1 point
  27. Looks Cool Maybe we should make a public framework for this and a big open source library of UI components. FYI you don't need to wire an empty class constant to the create methods 🙂
    1 point
  28. FYI to anyone using Bean's VIs. I was successfully using them in an application, but they had a peculiar side effect. Whenever another application on the system (G-Force) was in full-screen mode, the LabVIEW application windows were non-responsive to mouse clicks. If I switched G-Force out of full-screen mode, the LabVIEW windows started behaving properly again. It took me a while, but I figured out that in order to fix the issue, I needed to add another call to 'AttachThreadInput' at the end of Bean's code IF AttachThreadInput had been called earlier. In Bean's code, the 'fAttach' parameter is set to '1' to attach the thread. If you do this, you then need to call AttachThreadInput again at the end of the code, but with an 'fAttach' value of '0' to detach the thread. When I made this change, my application remained responsive to mouse clicks even when G-Force was in full-screen mode.
    1 point
  29. I am not sure I understand the reasoning. The DMC image display control is just a cosmetic modification of the original control. It doesn't change anything to the underlying coding. It seems to become a consensus that checking that box sounded like a good idea, but turned out to be a very bad one in some cases. I have stopped checking it when releasing a standalone app, as I don't have the bandwidth for testing all corner cases. Again, as long as nobody reports the issue with NI, nothing is going to be done about it. I won't because of the above sentence, but someone making his or her living from products developed with these tools might want to send a wake up message to NI. You can't engineer ambitiously if you dread every single checkbox in the application builder.
    1 point
  30. No there isn't such a driver (that I would know off and is openly available). There might be in some closed source environment for a particular project (not LabVIEW related, Pharlap ETS was used in various embedded devices such as robot controllers, etc) that used Pharlap ETS in the past but nothing that is official. There are several problems with supporting this: 1) FTDI uses a proprietary protocol and not the official USB-CDC class profile for their devices and they have not documented it publically. You only can get it under NDA. 2) Pharlap ETS is a special system and requires special drivers written in C and you need the Pharlap ETS SDK in order for this. This was a very expensive software development suite. WAS, because Interval Zero discontinued Pharlap ETS ~2012 and since then only sells licenses to existing customers with an active support contract but doesn't accept new customers for it. Now there is an unofficial (from the point of view from FTDI) Linux Open Source driver for the FTDI standard devices (not every chip provides exactly the same FT232 protocol interface but almost all of the chips that support predominantly the RS-232, 422, or 485 modes do have the same interface) and I have in the past spend some time researching that and trying to implement it on top of VISA-USBRAW. But with the advent of Windows 7 and its requirements to use signed drivers even for a pure INF style driver like the VISA-USBRAW driver, this got pretty much useless. This signing problem doesn't exist on the Pharlap ETS system, but development and debugging there is very impractical so when Interval Zero announced the demise of Pharlap ETS, I considered this project dead too. There was both no easy platform to develop the code on as well as no useful target where this still could be helpful. All major OSes support both the USB-CDC as well as USB-FTDI devices pretty much out of the box nowadays. This includes the NI-cRIO that are based on NI Linux RT. The only two beasts that won't are the Pharlap ETS and VxWorks based NI realtime targets, both of them are in legacy state for years and getting sacked this or next year for good. So while it would be theoretically possible to write such a driver on top of NI-VISA, the effort for that is quite considerable and it's low level tinkering for sure. The cost would be enormous for just the few last Mohicans that still want to use it on an old and obsolete Pharlap ETS or VxWorks cRIO controller. As to if there is a device that can convert your USB-FTDI device back into a real RS-232 device, devices based on the FTDI chip VNC1L-1A can implement this, here is an example as a daughter board. You would have to create a carrier with an additional TTL to RS-232 converter and the according DB-9 connector for this or if you are already busy building a PCB anyhow, just integrate the VNC1L-1A chip directly on it. The most "easy" and cheap solution would be to use something like a Raspberry Pi. That can definitely talk to your FTDI device with minor tinkering of some Linux boot script in the worst case. Then you need an application on the Raspi that connects to that virtual COMM port and acts as proxy between this and an RS-232 port (or a TCP/IP socket) on the Raspi that you then can connect to from your LabVIEW Pharlap ETS program.
    1 point
  31. For a final Case. Sadly there isn't any non-depreciated Items to replace that vi. Which makes this work for Clusterzilla. ArrayToCluster.vim
    1 point
  32. Someone reported a similar issue on the dark side. Are you using typedefs? https://forums.ni.com/t5/LabVIEW/chm-help-file-and-executable/m-p/2703303#M802558
    1 point
  33. You probably have javascript disabled or an addon blocking the javascript. 2 people have registered today so the site is working correctly.
    1 point
  34. enableSecretPopups - I put this token into LabVIEW 2011 for Silver control development, as a quick-and-dirty way to make low-level control edits. I've been giving it out to people on a very limited basis, but I guess since it's out here I'll widen the audience. I show a screenshot of the new menu items in https://decibel.ni.com/content/docs/DOC-17431 Once this token is enabled, you'll be able to see the settings on parts of the Silver controls to get an idea what they do. eg "Left Move" means the part will move left when its "master" part changes size via moving its left edge. "Left Grow" means the part will scale in that situation. Setting both the left and right move options will make the part stay centered. There are clearly combinations that don't make any sense and I suspect LabVIEW will behave badly if you use them. I recommend that you disable the token when you're not using the Control Editor, because it also enables other menu items that are not ready for prime time and you might use them later without realizing they're only there because of this INI token.
    1 point


×
×
  • Create New...

Important Information

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