Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. Today
  3. Yesterday
  4. Hello, I discovered a solution just today evening (around 20 of local time, now here is 22:28). Use EIOPlaceDownEIONode.vi to make an empty EIO Node; then use EIONode_ScriptAddChannel.vi to add channel(s); if there is one channel only, use also EIONode_ScriptModifyChannel.vi to set the channel - after the Add the terminal has Void data type, the Modify causes it to get the correct data type. When more than one channel is Add-ed, the Modify is unnecessary - the data type is set correctly for all channels. I hasn't investigate this in detail: seems "direction" can be specified as "none" unless more than one direction is valid (as for e.g. Digital Out signals); and possibly using Add (without specifying channel parameters) to add as many channels as needed, then Modify to set their parameters can be used, too. I attempted to find a way to delete a channel from EIO Node (by "Delete" Invoke Node on a terminal), no success.
  5. Good to know, I had missed this one. If I do find the time to look into it I'll report back, I've used Derrick's TinyTCP package and loved it.
  6. I don't know exactly how your collection looks like and in what the NI Web Server as it is fills in, but as for linux and serving http I have been positively impressed by this: https://github.com/illuminated-g/lv-http-server In fact I did some preliminary evaluation of it some time ago, and I was planning to build on it for a project which has been delayed. If you look into, I'd be interested in hearing your opinion as well.
  7. Hi all, I'm planning to expose metrics for Prometheus to collect (scrap) them. I saw the PromVIEW VIP on GitHub and vipm.io which works in the default Prometheus way : your app runs an HTTP server and Prometheus is configured to connect to it to collect your metrics. My issue is that I run my app on Linux (Ubuntu) and the NI Web Server is not supported on Linux. I've seen that Prometheus can also be configured to collect metrics from a file as long as we follow the correct format, so I will most probably follow this path. As anyone done this or anything similar?
  8. Can you please tell me how to implement this kind of control with transfer function in FPGA module? I can't find any function about transfer function in FPGA! Thanks a lot guys!
  9. Last week
  10. It's the example from MDI Toolkit for LabVIEW
  11. If you put a Call By Reference Node in the case you've reinvented Dynamic Dispatch with extra steps.
  12. I have watched several of the videos online regarding building PPLs and a plugin architecture, and some of the build issues that have been encountered. One thing that I havent seen is how to handle both 32 and 64 bit PPLs. Currently, we have both the 32 and 64 bit versions of LabVIEW on the same PC, and I am running into an issue of how to properly deal with the PPL plugins. We distribute the reuse PPLs via VIPM. The install process for this is typically: - When built, Package both bitness into the same VIP file - Unpack to a temp folder - Determine the bitness and move the desired bitness PPL to the install folder (Ex: C:\ProgramData\PPL\DB Base\DB Base.lvlibp) - Delete the temp folder with the "incorrect" bitness. This works when we only have one version of LabVIEW on a PC. But there may be times when we need both the 32 and 64 bit on a machine, depending on the programs installed. An example being a test software that needs 64 bit and we would also want another tool that we developed and is in 32 bit, and they both need to use the DB Base.lvlibp. Having both try to access the same file (C:\ProgramData\PPL\DB Base\DB Base.lvlibp) wont work for one of the bitness'. Is it better to append the bitness to the file name? (Ex: C:\ProgramData\PPL\DB Base\DB Base 32 bit.lvlibp) Or to the folder? (Ex: C:\ProgramData\PPL\DB Base 32 bit\DB Base.lvlibp) In either case, I can see my build process getting more complicated for the plugin module (DB Plugin), which inherits from the DB Base PPL.... - Do I have a 32 bit project (DB Plugin 32 bit.lvproj) that points to the C:\ProgramData\PPL\DB Base\DB Base 32 bit.lvlibp and a 64 bit project that points to the 64 bit base PPL (or folder)?
  13. Wow this thread is a blast from the past. I have actually used LapDog in a project many years ago! And Steve called it: I remember reading this thread and totally glossing over this idea, which I now 100% support.
  14. Here's a new take Here's slightly different take on that idea >> LabVIEW Idea: Enumerated Variant << It works with, but is not limited to, classes. It's inspired by languages like Rust (enums) and Zig (tagged unions)
  15. Hmm, not trying to criticize you but having 100 (or even 25) little windows that all display data and allow control too, seems to me to be a pretty difficult UX. It's definitely not something I would immediately turn to. Probably would have more like a list box that shows the information for each device, possibly in a tree structure, and letting the user select one and then make the controls for that available in a separate section of the screen where the control will be specific to the selected device. Shaun's example, while nice technically, shows the difficulty of that approach very well even without much of user control. The graph in there is pretty much way to small for any usable feedback.
  16. That would be a viable option if I was only displaying information, but it also controls the equipment. I know you do not know my system and are only offering help and I greatly appreciate it. Thank you and I always learn new things when I post on here.
  17. That seems like a lot of work just to put everything that the VI shown in a subpanel can do. There are several controls and indicators on the VI that is in the Sub panel. Could you show me an example of what you are suggesting?
  18. I would likely use a Table or MultiColumn List Control.
  19. How else would you suggest to show the information needed at 1 time on the main front panel? I use the DQMH framework and clone the VI and put that VI in subpanel on the main UI. I have been doing it this way for a long time now and have tested it up to 200 and have seen any issues. Updates coming in are really slow as the cameras send out status updates every minute. Realistically it is around 25 panels but it depends on how many cameras need to be monitored and controlled. But lets not get caught up in that, in general I would just like to learn to use Francois tool to programmatically align controls and indicators in a grid pattern based on screen size. Similar to what Shaun is showing above. (Nice VI by the way, mind sharing?)
  20. I believe it is related to having the Embedded UI enabled. I turned off the embedded UI and ran the system for a few days without the problem. I did not see this issue with LabVIEW 2020 with the app I am running, so I believe to be a new issue introduced since then (I updated the system to LV 2023 Q3)
  21. Did you figure out this crash @smarlow?
  22. The whole ADS library overhead in an application adds about 0.0something seconds to the whole build time of any project. As long as you have a linear hierarchy in object class dependencies, there is virtually no overhead at all beyond what you would have for the involved number of VIs anyhow. Once you happen to create circular dependencies the app builder will go into making overtime to resolve everything properly and your build times start to grow into the sky. At some point you can get all kinds of weird build errors that are sometimes almost impossible to understand. Untangling class hierarchies is in that case a very good (and usually also extremely time intensive) refactoring step to get everything to build nicely again.
  23. Booh with bells on. Hello 7 hr build time.
  24. For this type of functionality it is absolutely not Booh. 😀 It is OOP in the sense that it uses LabVIEW classes as an easy means of instantiating different driver implementations at runtime. One interface (or a thin interface class in pre LabVIEW 2020) and then a child implementation to call the DLL, one to call VISA USB Raw and possibly others. On top of that one driver as a class to do MPSSE I2C and another for MPSSE SPI. That way it is very easy to plugin a different low level driver depending what interface you want to use. D2XX DLL interface on Windows, D2XX so interface or D2XX VISA USB Raw on Linux and LabVIEW RT. With a little extra effort in the Base Class implementation for a proper factory pattern implementation, the choice which actual driver to load can be easily done at runtime. I did the same with other interfaces such as Beckhoff ADS, one driver using LabVIEW native TCP, another interfacing the Beckhoff ADS DLL, one for Beckhoff ADS .Net and one for Beckhoff ADS ActiveX, although the ActiveX one has a bug in the type library that tells LabVIEW to use a single reference byte as data buffer for the read function and there is no way to overwrite the type lib information except patching the ActiveX DLL itself. The Typelib should declare that as an array datatype but instead simply declares it as a byte passed by reference. The same thing for a C compiler but two very different things for a high level type description. The base class implements the runtime instantiation of the desired driver and the common higher level functionality to enumerate resources and read and write data IO elements using the low level driver implementation. For platforms that don't support a specific "plugin" you simply don't install that class.
  25. Agreed. Even just 100 and UI updates become a bit flakey.
  26. USB Raw will of course require your LabVIEW code to use the right USB control endpoints, pipes and binary bit patterns and if the new chip is not 100% upwards compatible with the old, that means a different driver (or one with conditional code based on the chip as detected at communication initialization). Without a detailed specification of the low level USB protocol for the new chip that is not gonna work. Using the FTDI provided D2XX driver should fix that as that driver somehow makes sure to talk to each chip as needed, as long as FTDI supports that chip with this driver. Some of the FTDI chips need a different driver such as D3XX. It's definitely easier than trying to do USB Raw communication but requires a bit of C programming knowledge to be able to figure out the proper Call Library Node configuration for each function. The existing LabVIEW wrapper as provided from FTDI is outdated and only supports 32-bit, possibly even with a bug or two even in 32-bit, but it is a starting point.With a little love it can definitely be made to work for modern LabVIEW in 32-bit and 64-bit and for Windows and Linux. I may revisit my earlier attempts of writing a fully LabVIEW OOP based solution for this with pluggable low level driver using USB Raw or FTDI D2XX and a pluggable high level driver for the I2C and SPI MPSSEE modes of the chips that have such an engine build in, but I haven't currently a use case for this and that tends to push this project always towards the end of the "projects that are nice to develop" queue.
  27. Earlier
  28. It may be possible, but a few 100 subpanels somehow makes my alarm nerve tingle quite strongly! Sub Panels are not the light weight thing like Windows windows, where they made each control in a classic Win32 application its own sub-window. And they moved away from that idea with more modern UI frameworks too, and likely for some reason. You really may be stressing LabVIEW's window management capabilities beyond reasonable borders with so many subpanels present at the same time.
  29. WebRing is down. I moved the page to GitHub: GitHub - Zou-LV1990/PropertyPages: Customize LabVIEW Property Pages
  1. Load more activity
×
×
  • Create New...

Important Information

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