Jump to content

All Activity

This stream auto-updates

  1. Past hour
  2. You have the right idea. You can add the DLL to your exe build spec instead of your installer though.
  3. Today
  4. I don't think you're going to find an easy way to transfer this automagically to FPGA. You're going to have to break it down into developing your own nth order derivative and integral functions. Are you using compact RIO? If you don't need a crazy fast loop rate, you should be able to simulate your FPGA code as HIL running in RT which would make the development a little faster.
  5. Hello all, background A while ago I wrote a dll wrapper to get data from dedicated test-hardware. For this hardware there is a dll available. To use this dll you need to use an callback function. If you need to use a dll in Labview which needs a callback you need to write the callback in C code and use a Labview C lib to get the data into Labview, basically my dll takes care of this problem . Enhance the code and way of working more efficient The code I wrote code works fine. However I did not use / test it for hours on a row. And sometimes If I make a mistake when changing the code I run into problems. I was able to fix all the errors and problems however it was not the most efficient way of working. For instance If there is a serious error in the code the dll I need for the hardware can crash, it can make my wrapper crash, which will in return make Labview crash. This makes the way of coding inefficiënt and it will not enable me to read my C++ book etc etc. Example pseudo code I did try to extract some main points of intrest from the code, I did add some comment in the code. I hope someone can give me some general guideline or advice what to read. At this time I am reading: Unhandled C++ exceptions I think I might be able to use it, I did not use this before so advice would be welcome. Thank you all for the help ! // .. // This is a part of the code only intended to have a talk about how to catch errors // It is not complete and intended as Pseudo code // .. int __stdcall MyDriverLoads(const int NumberToInitialise,const bool enableAnotherOption , const char *const path , LVUserEventRef *rwer) { // loads the dll // Q -- I can check if (F_functionname !=0), if it is not 0 then I can proceed if the function returns 0 I can return an error to Labview Extern_dll = Load_Extern_dll(); // Get the functions I need from the dll p2_ExternDriver F_ExternDriver = (p2_ExternDriver)GetProcAddress(Extern_dll, "_ExternDriver"); p2_Initialise F_Initialise = (p2_Initialise)GetProcAddress(Extern_dll, "_Initialise"); p2_AdapterCount F_AdapterCount = (p2_AdapterCount)GetProcAddress(Extern_dll, "_AdapterCount"); p2_StartLogging F_StartLogging = (p2_StartLogging)GetProcAddress(Extern_dll, "_StartLogging"); p2_StopLogging F_StopLogging = (p2_StopLogging)GetProcAddress(Extern_dll, "_StopLogging"); // When there are adapters found I tell it in Labview adapterCount = F_AdapterCount(); // Get the callback function adress, if adress == 0 I can see something is wrong void(__stdcall *p2_CallbackFunction_t) (pt2Obj , const LogData & ) = &CallbackFunction; // Q -- I could use try {} and catch {} however I do not have acces to the source code of the dll so, // I do not know if they used // trow "The Blue error" , or // trow "The Red error" ret = F_ExternDriver(adapterCount, enableLogFile, path, *p2_CallbackFunction_t, pt2Obj); // This tels the dll to start logging before this command you will not receive data in Labview ret F_StartLogging(1,2,3); // Labview is receiving data thats great !!! return ret; // Q -- Labview has been receiving data for a hour what happens if the used extern dll crashes ?? // If the dll crashes when return is passed I can not use try() and catch anymore. // } extern void __stdcall CallbackFunction(pt2Obj , const LogData & ) { // There is a lot to do here // do stuff!! // I did not write everything here err = PostLVUserEvent(*event_ref, &tmpEvent); }
  6. Yesterday
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. 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!
  12. Last week
  13. It's the example from MDI Toolkit for LabVIEW
  14. If you put a Call By Reference Node in the case you've reinvented Dynamic Dispatch with extra steps.
  15. 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)?
  16. 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.
  17. 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)
  18. 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.
  19. 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.
  20. 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?
  21. I would likely use a Table or MultiColumn List Control.
  22. 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?)
  23. 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)
  24. Did you figure out this crash @smarlow?
  25. Earlier
  26. 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.
  27. Booh with bells on. Hello 7 hr build time.
  28. 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.
  29. Agreed. Even just 100 and UI updates become a bit flakey.
  1. Load more activity
×
×
  • Create New...

Important Information

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