Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 03/28/2023 in all areas

  1. Usual disclaimer. Method described below is strictly experimental and not recommended to use in real production. N.B. This is based on .NET, therefore Windows only. This text is sorta lengthy, but no good TL;DR was invented. You may scroll down to the example, if you don't want to read it all. One day I was stalking around NI forums and looking at how folks implement their callback libraries to call them from LabVIEW. After some time I came across something interesting: How to deal with the callback when I invoke a C++ dll using CLF? There someone has figured out how to make LabVIEW give us a .NET delegate using a dummy event. This technique is different from classic way of interfacing to callbacks, because it allows to implement the callback logic inside a VI (not inside a DLL), but still it requires writing some small assembly to export the event. Even though Rolf said there that it's not elegant, I decided to study these samples better. Well, it was, yeah, simple (no wonder it was called SimpleProxy/SimpleDemo/SimpleCallBack) and very instructive at the same time. It worked very well in both 32- and 64-bit LabVIEW, so I had fun to play around and learn some new things about .NET events and C#. After all I started to think, whether we really need this dummy assembly to obtain a delegate... Initially I was looking for a way to create a .NET event at the run-time with Reflection.Emit or with Expression Trees or somehow else, but after googling for few days and trying many things in both C# and F# I came to a conclusion that it's impossible. One just can create event handlers and attach them to already existing events, not create events on their own. Okay. First I decided to know how exactly LV native Register Event Callback node works. Looking ahead I'll say it was a dead end, but interesting. Ok, the Register Event Callback node in fact consists of two internal functions - DynEventAllocRegInfo and DynEventRegister - with the RegInfo structure filling between them. The first one creates and returns a new RegInfo with a Reg Event Callback reference, the second one actually registers the RegInfo and the reference in the VI Data Space (the prototypes and the struct fields are more or less figured out). But when I started to play with the CLFN's to replace the Register Event Callback node, I ran into few pitfalls. To work properly the DynEventRegister function needs one of the RegInfo's fields to be a type index of (hidden) upper left terminal of the Constructor node. This index is stored in the VI's Data Space Type Map (DSTM) and determined at the compile time. I did not find a reliable way to pull it out of the DSTM. Moreover the RegInfo struct doesn't have a field for the VI Entry Point or anything like that. Instead LabVIEW stores the EP in some internal tables and it's rather complicated to get it from there. For these reasons I have given up studying the Register Event Callback node. Second I turned my attention to the delegate call by its pointer. I soon found out that LabVIEW generates some middle layer (by means of .NET) to convert the parameters and other stuff of the native call to the VI call. That conversion was performed by NationalInstruments.LabVIEW###.dll in the resource folder (a hidden gem!). This assembly has almost everything that we need: the CallbackInfo and CallbackHandler classes, and the latter has two nice methods: CallLabView and CreateCallbackHandlerDelegate. Referring to the SimpleDemo/SimpleCallBack example, when we call the delegate by its pointer, LabVIEW calls this chain: CallLabView -> EventCallbackVICall internal function -> VI EP. All that was left to do was to try it on the diagram with .NET nodes, but... there was another obstacle. Sure that you'll connect the inputs right? You will not. These parameters are not what they seem (at least, one of them). The viref is not a VI reference, but a VI Entry Point pointer. It's not a classic function EP pointer, but a pointer to a LabVIEW internal struct, which eases the VI calls (it's called "Vepp" in the debug info). The userParam is a pointer to the User Parameter as for the Register Event Callback node. The cookie is a pointer to the .NET object refnum from the Constructor node (luckily NULL can be passed). And the type and flags are 0 and 0x80000000 for standard .NET callbacks. Now how and where could we get that VI EPP? Good question. There is a function inside LabVIEW, that receives a VI ref and returns an allocated VI EPP. But sadly it's not exported at all. Of course, this ain't stoppin' us. I used a technique to find the function by a string constant reference in the memory of a process. It's known to be not very reliable between different versions of the application, therefore many tests were made on many versions of LabVIEW. After finding the function address, it's possible to call it using this method (kind of a hack as well, so beware). Is this all enough to run .NET nodes now? For the CallLabView yes. It's simplier than CreateCallbackHandlerDelegate, but doesn't provide a delegate. It passes the parameters to the VI, calls it and returns. The return and parameters could be utilized onwards, of course, but nothing more. To obtain a delegate it's necessary to call the CreateCallbackHandlerDelegate. This method wants the handlerType input wired and to be valid in .NET terms, so proper type must be made. Initially I tried to use .NET native generic delegates: Action, Predicate and Func. Everything went fine except the GetFunctionPointerForDelegate, which didn't want to work with such delegates and complained. The solution was in applying some obscure MakeNewCustomDelegate method as proposed here. Now the GetFunctionPointerForDelegate was happy to provide a pointer to the delegate and I successfully called the callback VI both "manually" and by means of Windows API. So finally the troubles were over, so I could wrap everything into SubVI's and make a basic example. I chose EnumWindows function from WinAPI, because it's first that came to my mind (not the best choice as I think now). It's a simple function: it's called once with a callback pointer and then it starts looping through OS windows, calling a callback on each iteration and passing a HWND to it. This is top-level diagram of the example: I won't be showing the SubVI's diagrams here as they are rather bulky. You may take a look at them on your own. I'll make one exception though - this is the BD of the callback VI. As you could know, EnumWindowsProc function must return TRUE (1) to continue windows enumeration. How do we return something from a callback VI? Well, it's vaguely described here, I clearly focus on this. You must supply first parameter as a return value in both Event Data clusters and assign these two to the conpane. On the diagram you set the return as you need. These are the versions on which I tested this example (from top to bottom). Some nuances do exist, but generally everything works well. LabVIEW 2023 Q3 32 & 64 (IDE & RTE) LabVIEW 2022 Q3 32 & 64 (IDE & RTE) LabVIEW 2021 32 & 64 (IDE & RTE) LabVIEW 2020 32 & 64 (IDE & RTE) LabVIEW 2019 32 & 64 (IDE & RTE) // 32b - on one machine RTE worked only w/ "Allow future versions of the LabVIEW Runtime to run this application" disabled (?), 64b - OK LabVIEW 2018 32 & 64 (IDE & RTE) LabVIEW 2017 32 & 64 (IDE & RTE) // CallbackInfo& lvCbkInfo, not ptr LabVIEW 2016 32 & 64 (IDE & RTE) // same LabVIEW 2015 32 & 64 (IDE & RTE) // same LabVIEW 2014 32 & 64 (IDE & RTE) // same LabVIEW 2013 SP1 32 & 64 (IDE & RTE) // same + another string ref + 64b: "lea r8" (4C 8D 05) instead of "lea rdx" (48 8D 15) LabVIEW 2013 32 & 64 (IDE & RTE) // same + no ReleaseEntryPointForCallback, CreateCallbackHandler instead of CreateCallbackHandlerDelegate LabVIEW 2012 32 & 64 (IDE & RTE) // same + forced .NET 4.0 LabVIEW 2011 32 & 64 (IDE & RTE) // same LabVIEW 2010 32 & 64 (IDE & RTE) // same LabVIEW 2009 32 & 64 (IDE & RTE) // same EnumWindows (LV2013).rar EnumWindows (LV2009).rar How to run: Select the appropriate archive according to your LV version: for LV 2013 SP1 and above download "2013" archive, for LV 2009 to 2013 download "2009" archive. Open EnumWindows32.vi or EnumWindows64.vi according to the bitness of your LV. When opened LV will probably ask for NationalInstruments.LabVIEW###.dll location - point to it going to the resource folder of your LV. Next open Create Callback Handler Delegate.vi diagram (has a suitcase icon) and explicitly choose/load NationalInstruments.LabVIEW###.dll for these nodes marked red: It's only required once as long as you stay on the same LV version. For the constant it may be easier to create a fresh one with RMB click on the lvCbkInfo terminal and choosing "Create Constant" entry. Now save everything and you're ready to run the main VI. Remarks / cons: no magic wand for you as for the Register Event Callback node, you create a callback VI on your own; the parameters and their types must be in clear correspondence to those of the delegate; obviously .NET callbacks are X times slower than pure C/C++ (or any other unmanaged code) DLL; search for CreateVIEntryPoint function address takes time (about several seconds usually); on 64 bits it lasts longer due to indirect ref addressing; no good way to deallocate VI EPP's; the ReleaseEntryPointForCallback function destroys AppDomain when called (after such a call the VI must be reopened to get .NET working) - usually not a problem for EXE's. Conclusion. Although it's a kind of miracle to see a callback VI called from 'outside', I doubt I will use it anywhere except home. Besides its slowness it involves so many hacks on all possible levels (WinAPI, .NET, LabVIEW) that it's simply dangerous to push such an application to real life. Likely this thread is more of a detailed reference for the future idea in NI Idea Exchange section.
    7 points
  2. I'm excited to release ViPER ViPER is an Object Oriented design Framework that supports dependency injection and recursive object creation. Systems are assembled at runtime from a collection of pre-built components defined by an Object Definition Document. Please visit the project on GitHub https://github.com/kurtafriday/ViPER I've presented this framework at several GLA Conferences, for an overview and guidance please view. GLA 2021 https://labviewwiki.org/wiki/GLA_Summit_2021/Open_Source_ViPER GLA 2020 https://labviewwiki.org/wiki/GLA_Summit_2020/ViPER_-_A_LabVIEW_Dependency_Injection_Framework This branch of ViPER has been used by us to develop systems in regulated industries for several years, it's solid and reliable, however its windows only. I'm working on ViPER_WinRT which is compatible with Windows and RT and we have already used it for several systems. I'll be releasing ViPER_WinRT in the coming months. I'll work to get ViPER onto the VIPM Tools Network soon. I'm looking forward to the feedback and I hope you enjoy and get value from this framework. Ping me if you have any questions. kurt@medulla.net
    6 points
  3. My new motto No more comments in my LabVIEW code. No icon customization. All VIs named 'untitled<n>.vi'
    6 points
  4. How about halfway happy. Which is more happy then I'd be with nothing. I enjoy a community that shares code. Sharing is caring. I'm agree that stuff on VIPM.IO should have a bit more polish. But a random forum post doesn't require the test and rigor of a commercial product.
    5 points
  5. Good Read here, a bit depressing https://nihistory.com/nis-commitment-to-labview/
    4 points
  6. Test Stand is a test sequencer so what you have now isn't even in the same paradigm. In terms of LabVIEW, you have some limited block functionality that could be compared to Express VI's (which we don't use). From what I can tell, It seems to be the Python version of Node Red (Javascript). It has a place but people are very quickly going to be dropped into text coding for anything more than hobbyist applications. Many people on this forum (not me) are also adept Python Developers already and I expect they will weigh in sooner or later. If you are going to target the LabVIEW community, I would suggest you work on your videos. From what I can tell, they are pretty much: Plug in some wires Magic happens Trust me bro, the pretty pictures are because of the magic".
    4 points
  7. @Rolf Kalbermatter I know you did not mean this, but I love it!
    4 points
  8. As a workaround, what about using the .NET control's own events? Mouse Event over .NET Controls.vi MouseDown CB.vi MouseMove CB.vi
    4 points
  9. I think there were 182. Everything was video recorded and after editing will be posted on YouTube. Expect something in about six weeks.
    4 points
  10. (Disclaimer: I am not an NI insider, and I have no inside knowledge of the pending Emerson acquisition) I think we're all sort of in a holding pattern waiting to see how the Emerson acquisition plays out. Emerson's outward messaging seems very positive towards LabVIEW, which I find encouraging.
    4 points
  11. This video may not look like it, but for us it represents an enormous amount of effort, difficulty, sacrifice and financial means. It is with special emotion that we proudly unveil the upcoming major update for HAIBAL, the LabVIEW deep learning toolkit by Graiphic. In a few weeks, we will introduce a significant enhancement to our deep learning toolkit for LabVIEW. This update takes our tool to a new dimension by integrating a range of reinforcement learning algorithms: 𝐃𝐐𝐍, 𝐃𝐃𝐐𝐍, 𝐃𝐮𝐚𝐥 𝐃𝐐𝐍, 𝐃𝐮𝐚𝐥 𝐃𝐃𝐐𝐍, 𝐃𝐏𝐆, 𝐏𝐏𝐎, 𝐀𝟐𝐂, 𝐀𝟑𝐂, 𝐒𝐀𝐂, 𝐃𝐃𝐏𝐆 𝐚𝐧𝐝 𝐓𝐃𝟑. Naturally, this update will include practical, easy-to-use examples such as DOOM, MARIO, Ataris games and many more surprises will come along. (starcraft or not starcraft?) 👉🏼 Visit us now www.graiphic.io 👉🏼 Get started with TIGR vision toolkit https://lnkd.in/dssB-MS4 👉🏼 Get started with HAIBAL deep learning toolkit https://lnkd.in/e6cPn4Fq
    4 points
  12. Well, the whole NI=>Emerson transaction seems to go as follows: 1) Shareholders from Emerson have approved the deal 2) Emerson created a wholly owned subsidiary in Deleware called Emersub CXIV, Inc for the whole purpose of merging with NI 3) Shareholders from NI approved the merger on June 29, 2023 4) After all the legalities have been dealt with National Instruments and Emersub CXIV, Inc will merge into a new company under the name of National Instruments, and Emersub CXIV, Inc will cease to exist. The end result is that National Instruments for a large part will most likely simply operate as is and be a fully owned subsidiary of Emerson Electric but for a lot of things simply keep operating as it did so far. If and what technical cross contamination will eventually happen will have to be seen. You could probably compare it to how National Instruments dealt with Digilent and MCC when they took them over. They both still operate under their own name and serve their specific target audience and for a large part were unaffected by the actual change in ownership. There were of course optimizations such as that most of the MCC boards where eventually actually manufactured and shipped from the same factory that also produces NI hardware. Digilent also has eventually taken over some of the products from NI that were mainly meant for the educational market such as myDAQ but also the Virtual Bench device which they sell under a different name but it is 100% the NI Virtual Bench device and also works with the same drivers.
    4 points
  13. Hi I found two original floppies with a Demo version of 2.5.1 from 1992. I hope NI won't mind I share them. They were handouts to prospective buyers of LV back then. LV crashed immediately with a divide by zero in WfW 3.11. LV also caused a Win386 error in Win 95, which could be ignored. So here is the glorious screen image : The computer is from 2000. The CPU is a Pentium Pro. Regards LVD251D1.zip LVD251D2.zip
    4 points
  14. I exclusively use the bundle/unbundle, unless I am not able to for example if accessing a field in a parent class. Accessors should be, in my opinion, only for when you want to get access to the data from outside the class, and even then you should really think about if this is strictly necessary. Often you can get rid of accessors by having a better designed API (methods). Lots of sets/gets is a code smell to me.
    4 points
  15. After making someone's day on the NI forums last fall for yet another CRC variation, I decided to go look for a fully-implemented LabVIEW reuse library I could just link to for the next such request. I really couldn't find one. Hence, the attached. It's intended to be a user.lib reuse library (although the attached zip includes a small demo project with a test VI). There's really only about two genuine VIs in the library, both are malleable to adapt to the poly/init integer sizes. One is the CRC computation VIM and the other is a lookup table builder; you have the option of pay-as-you-go (eight shifts/tests and conditional XORs, aka "brute force"), or you can take the computational hit upfront once and build a lookup table. Outputs are tested correct for the lengthy list of "well-known" CRCs (included in the library as some handy typedef'd cluster constants), when tested against some reputable online calculators. What is NOT done: I haven't made any serious attempts at benchmarking performance, brute force vs. lookup table. I'd be happy to have the LAVA community beat this up and suggest improvements in: speed, code elegance, style, whatever. Dave CRC.zip
    3 points
  16. All I know is that if they don't do something to make it a more powerful language, it will be difficult to keep it going in the long run. It was, in the past always a powerful choice for cross-platform compatibility. With the macOS deprecating (and eventually completely removing) support for OpenGL/OpenCL, we see the demise of the original LabVIEW platform. I for one would like to see a much heavier support for Linux and Linux RT. Maybe provide an option to order PXI hardware with an Ubuntu OS, and make the installers easier to use (NI Package Manager for Linux, etc.). They could make the Linux version of the Package Manager available from the Ubuntu app store. I know they say the market for Linux isn't that big, but I believe it would be much bigger if they made it easier to use. I know my IT department and test system hardware managers would love to get rid of Windows entirely. Our mission control software all runs in Linux, but LabVIEW still has good value in rapid application development and instrument bus controls, etc. So we end up running hybrid systems that run Linux in a VM to operate the test executive software, and LabVIEW in Windows to control all our instruments and data buses. Allowing users the option to port the RT Linux OS to lower-cost hardware, they way did for the Phar Lap OS would certainly help out, also. BTW, is it too much to ask to make all the low-cost FPGA hardware from Digilent LabVIEW compatible? I can see IOT boards like the Arduino Portenta, with its 16-bit analog I/O seriously eating their lunch in the near future. ChatGPT is pretty good at churning out Arduino and RaspberryPi code that's not too bad. All of our younger staff uses Digilent boards for embedded stuff, programming it in C and VHDL using Vivado. The LabVIEW old-timers are losing work because the FPGA hardware is too expensive. We used to get by in the old days buying myRIOs for simpler apps on the bench. But that device has not been updated for a decade, and it's twice the price of the ZYBO. Who has 10K to spend on an FPGA card anymore, not to mention the $20K PXI computer to run it. Don't get me wrong, the PXI and CompactRIO (can we get a faster DIO module for the cRIO, please?), are still great choices for high performance and rugged environments. But not every job needs all that. Sometimes you need something inexpensive to fill the gaps. It seems as if NI has been willing to let all that go, and keep LabVIEW the role of selling their very expensive high-end hardware. But as low-cost hardware gets more and more powerful (see the Digilent ECLYPSE Z7), and high-end LV-compatible hardware gets more and more expensive, LabVIEW fades more and more I used to teach LabVIEW in a classroom setting many years ago. NI always had a few "propaganda" slides at the beginning of Basics I extolling the virtues of LabVIEW to the beginners. One of these slides touted "LabVIEW Everywhere" as the roadmap for the language, complete with pictures of everything from iOT hardware to appliances. The reality of that effort became the very expensive "LabVIEW Embedded" product that was vastly over-priced, bug-filled (never really worked), and only compatible with certain (Blackfin?) eval boards that were just plain terrible. It came and went in a flash, and the whole idea of "LabVIEW Everywhere" went with it. We had the sbRIOs, but their pricing and marketing (vastly over-priced, and targeted at the high-volume market) ensured they would not be widely adopted for one-off bench applications. Lower-cost FPGA evaluation hardware and the free Vivado WebPack has nearly killed LabVIEW FPGA. LabVIEW should be dominating. Instead you get this:
    3 points
  17. It is actually much faster on my machine. Here are a few results: @Łukasz Fast solution: ~30 µs @cordm Case 1 (really slow): ~403 µs Case 2 (good performance and readability): ~54 µs -- output is wrong, see below. Case 3 (): ~235 µs Case 4 (original solution): ~30 µs Case 5 (LV200000_BLASLAPACK.dll): ~14 µs Case 6 (LVBLAS.dll:BLASCopyVectorH): ~16 µs -- Windows 11, LabVIEW 2020 SP1 (32-bit) This code actually truncates the last value because the length of the source array becomes odd. Here are two possible fixes. The second one is slightly faster for me. 1) Append the final element: ~60 µs. (slightly slower than before) 2) Rotate the string before conversion: ~42 µs.
    3 points
  18. Is the frame size 16 bytes? In the first you use 14, in the second 16. This is slightly faster: The biggest hurdle is converting the endianness, I do not think you can get much faster with conversion. I tried to be clever using BLAS dcopy for copying out the relevant part, but the conversion kills the performance gain. decode-frame-cm.vi
    3 points
  19. Change the limit to 65535 instead of 10000 in the Windows Registry I have a file named: Max GDI Objects.reg With this content: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows] "GDIProcessHandleQuota"=dword:0000ffff
    3 points
  20. The issue was reported to LV R&D as Bug 2317159. It was introduced in LabVIEW 2022 Q3 and fixed in LabVIEW 2023 Q3. The Error 13 occurs when the LabVIEW Class private data includes certain types of .NET references, or a reference to a .chm help file. More details: LabVIEW 2022 Q3 included a "fix" to how linkages to .NET assemblies are adjusted in a build output. Unfortunately this "fix" caused the issue you're seeing. LabVIEW 2023 Q3 uses a new mechanism for app builder caching under the hood, which removed the codepath that was causing the Error 13 altogether.
    3 points
  21. Adding a link to this new tool: TOML Edit LabVIEW it is a thin wrapper around a popular Rust library that supports preservation of formatting and comments.
    3 points
  22. I created the following VI for myself, but re-sharing here to be helpful. I've aggregated all the controls/decorations into a single file, which acts as a bit of a large palette. Some of the DSC controls are super cool. They're not just vector resizing, but procedurally resized. The segmented pipe control, in particular, feels like a really cool tech demo for what the PICC format/LabVIEW can do. Makes me really wish we were able to make our own. DSC toolkit controls (taken from another NI forum post - so I assume it's ok to be sharing these across the forums?) DSC toolkit hidden controls (Some of these were included with DSC, but not placed on the palette. Not sure why.) All the decorations that dadreamer collected All the decorations from the modern/silver palettes All decorations.vi
    3 points
  23. If it was hard to write, it should be hard to read.
    3 points
  24. It should also automagically install Visual Studio, write the callback wrapper, compile it into a DLL and connect it to the VI with a CLFN. Moreover it would be nice to have a .NET translator from textual code to G code, as the current way of calling .NET assemblies is too awkward. It may take 10 minutes to find a good combination of Assembly -> Constructor -> Method/Property, especially when dealing with the OS native API.
    3 points
  25. Interesting Demo at NI Connect today. Link starts at NIgel demo.
    3 points
  26. I posted my Image Manipulation code over on VIPM.IO https://www.vipm.io/package/hooovahh_image_manipulation/ Here is a video demonstrating some of its functionality, including loading an image into a picture box and manipulating it.
    3 points
  27. There's also a little known feature in the top method where you can right click the Wait On Asynchronous Call and can set a timeout. This will then wait some amount of time for the VI to finish and will generate an error if it isn't completed yet. There are better ways to handle knowing when the VI is done, but it is good for a quick and dirty solution to wait a few ms for it to finish, and if it isn't done, go service something like the UI and come back again later. I submitted that as an idea on the Idea Exchange, then AQ said why it was a bad idea. Only for years later it to be implemented anyway.
    2 points
  28. Here is some info on what changes there are in the new release. https://www.ni.com/docs/en-US/bundle/upgrading-labview/page/labview-2024q1-changes.html This is not the major release of the year so there isn't too much to talk about. As for fixing the build issue I wouldn't hold your breath. I've already seen someone mention that the build for an lvlibp failed with error 1502. Cannot save a bad VI without its block diagram. But turning on debugging allowed it to build properly.
    2 points
  29. I had a girlfriend like that. It turned out that her father used mix metaphors for comic effect but she didn't realise and thought it was the correct metaphor. When she said "everyone says it like that" what she meant was "my family says it like that"
    2 points
  30. Hi All, I'm writing (what I hope is nice) modular code, trying to modularise functions and UIs etc accross the applications we're developing to keep things nice and flexible. But I'm struggling to keep individual modules "uncoupled" - or rather not all interdependent on each other. Example - I have module for communicating with an oscilloscope to capture waveforms. I create a typedef in that module for passing out those waveforms and related information to another module, which sends them on to a storage module and a waveform processing module (where I do various things to the raw waveform) and then finally out to a waveform display module... So my question becomes "who should own the waveform data typedef" - the easiest thing to do is make sure the input side of any module's API accepts the output of the API producing the data... so if it sits in the acquisition module library at the "source" of the data, then assuming I dont keep translating to different data types, all of my other modules end up dependent back to there too - e.g. my waveform processing and display modules now depend on the acquisition module - but I might want to write a post processing and display application that needs to know how to process waveforms, but I dont want to have to include the waveform acquisition module with that as it wont be acquiring anything... I'm sure there's lots of options, and this post is really to try and find some I havent thought of yet! I know I could create the typedef in it's own library or even outside of any library, then the users of that typdef are not dependent on each other (I think that's basically a form of dependency inversion?). But then that gets hard to manage and leads to the idea of a "common data types" library, which can quickly grow to lots of other things and more types of coupling in a way. I could translate the typedef as it passes through a chain of modules so that each module defines the way it expects to receive the data, and then a tree type module hierarchy limits the coupling... but that always feels somewhat inefficient - and I want one waveform data type, not 4 depending on where I am in the application. My situation is marginally complicated as well since we're using PPLs and some of my data types are now classes, so they need to be inside a PPL somewhere and then used from there (and its a pain we cant build a packed class without first wrapping it in a project library...) So yes - how do you all manage your typedefs and classes that get used across module boundaries to minimise those dependency issues!? Thanks in advance, sorry for the slightly rambly post!
    2 points
  31. Well. C++ is just as old and C is 10 years older - so go figure! The whole software discipline hasn't really moved on in the last 60 years (check this out!) and while I do see AI changing that, it's probably not in the way you think. If AI is to be instrumental to programming it must come up with a new way of programming that obsoletes all current languages-not automate existing languages. Software needs it's Einstein vs Newton moment and I've seen no sign of that coming from the industry itself. Instead we get more and more recycled and tweaked ideas which I like to call Potemkin Programming or Potemkin languages. I disagree. LabVIEW, so far, has been immune to AI but it has also been trapped in the Potemkin Programming paradigm (ooooh. PPP ). It needs another "Events" breakpoint (when they introduced the event structure and changed how we program). Of all the languages, LabVIEW has the potential to break out of the quagmire that all the other languages have languished in. What we don't need is imports from other languages making it just as bad as all the others. We need innovators (like the guy that invented malleable VI's for funsies) only in their 20's and 30's - not 70's.
    2 points
  32. I landed over https://www.emerson.com/en-us/esg/environmental-sustainability "Greening Of. Greening By. Greening With"🤣
    2 points
  33. Okay new release 3.1.0.16 should fix the issues I mentioned.
    2 points
  34. I have uploaded the new release to vipm.io We are now at release v3.0.0 since this is a breaking change. I also started some documentation: LV-muParser User Guide.pdf
    2 points
  35. Linux only huh? No mention of fallocate? Why do people keep posting junk from ChatGPT? At this point I consider it spam.
    2 points
  36. There is a KB article about this: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7OGSA0&l=en-GB We also had this problem when building a large application. You could see the GDI object counter hit the limit in task manager and soon after LabVIEW would crash. After upgrading to LabVIEW 2020 SP1 it went away, though I have not explicitly heard that this problem was fixed.
    2 points
  37. As I wrote in an earlier post I'm missing bit-operations and some more. Since I had some time left, I downloaded the latest LabView-muParser code and added the missing functions: ~ Binary-Not (flip all bits) & Binary And | Binary Or |^ Binary XOr << Bit-Shift left >> Bit-Shift right % Modulo Operator (also for floating point values) Support of values given as hex (0x1A2c) and binary (0b101101) My question to you Porter: Are you interested in integrating it into your project? Then everybody could use it. The modifications are only in one file (muParserDLL.cpp).
    2 points
  38. Okay it looks like you'll get an Out of Memory error on building. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019No1SAE&l=en-US
    2 points
  39. 2018. also fixed the typo All decorations.vi
    2 points
  40. Aside from what is in the Help, I don't know how the Threads option works. From what I can tell, it does not seem to have much (any?) effect inside a parallel loop. I tend to use it for large 3D arrays, so it makes a substantial difference.
    2 points
  41. SNDCSDLM.dll depends on cvirte.dll. You can check it's deployed on the target machine with Dependency Walker. It's always deployed on development machines so maybe that's the issue. Something easy to check and eliminate.
    2 points
  42. You clearly have not much C programming experience. Which of course is a very bad starting point to try to write C code that should then interoperate with LabVIEW. First this: // +++++ I try to add this, Gues this will not work .. see extcode.h LStrHandle textString[TEXT_STRING_SIZE]; }structSample; You are basically defining a fixed size array of TEXT_STRING_SIZE LabVIEW string handles, not a LabVIEW string handle of TEXT_STRING_SIZE length. LabVIEW string handles are never fixed size but instead dynamically allocated memory blocks with an extra pointer reference to it. And that dynamic allocation (and deallocation) ABSOLUTELY and SURELY must be done by using the LabVIEW memory manager functions. Anything else is nothing more than a crash site. What you have built there as datatype would look like an array of structs and each of these structs would contain three integers followed by 256 LabVIEW string handles, which is not only pretty weird but absolutely NOT compatible with any possible LabVIEW structure. And after allocating all these things you eventually only send the actual string handle to the event and leak everything else and the handle itself too! typedef struct { int32_t firstInt; int32_t secondInt; int32_t thirdInt; LStrHandle lvString; } MyStruct, *MyStructPtr; MgErr CreateStringHandle(LStrHandle *lvStringHandle, char* stringData) { MgErr err; size_t len = strlen(stringData); if (*lvStringHandle) { err = DSSetHandleSize(*lvStringHandle, sizeof(int32_t) + len); } else { *lvStringHandle = DSNewHandle(sizeof(int32_t) + len); if (!*lvStringHandle) err = mFullErr; } if (!err) { MoveBlock(stringData, LStrBuf(**lvStringHandle), len); LStrLen(**lvStringHandle) = (int32_t)len; } return err; } MgErr SendStringInSructToLV(LVUserEventRef *userEvent) { MyStruct structure = {1, 2, 3, NULL); MgErr err = CreateStringHandle(&structure.lvString, "Some C String!"); if (!err) { err = PostLVUserEvent(*userEvent, &structure); DSDisposeHandle(structure.lvString); } return err; }
    2 points
  43. Thanks Hooovahh! I don't have time to turn this into a polished Qcontrol or anything like that at the moment. However, I did make a small improvement to the code: You can now use the horizontal and vertical table scrollbars, and the rotated header will update accordingly. related note: I discovered that ActiveCellPosLeft will return a 0 if the active cell is not visible. That's so lame. Fortunately, it's still possible to calculate offscreen CellPos by reading cell width (which apparently still works for offscreen cells), and then doing math from the nearest visible cell's position. RotatedColumnHeader_scrollbar.zip
    2 points
  44. I ran into a situation where I really needed a rotated column header for a table due to having long column header names and not enough space. After doing a bunch of looking around, it didn't really seem like this capability existed anywhere for LabVIEW, so I'm sharing a little piece of code that I created for this here. LabVIEW doesn't natively support rotated strings, so that wasn't an option. LabVIEW 2D picture controls would theoretically let you write, and then rotate text. But LabVIEW 2D picture controls don't support aliasing, so I didn't perceive this to be an option. @hooovahh recently posted a fun .NET picture control library to VIPM, and that inspired me to go down the .NET picture control rabbit hole. Having to deal with opening and closing all the .NET references is a bit of a hassle, but I'm surprised by how much capability exists with the .NET picture control. High complexity ceiling. Looking back, I wonder if I should have tried the LabVIEW 3D picture control instead. Anyways, this demo provides the following capability: - rotated column headers by specified angle - anti-aliased text - column headers size to table column width/positions RotatedColumnHeader.zip
    2 points
  45. One of my past managers said, "This isn't a laboratory so why are we using LabVIEW?" I'm sure he didn't capitalize it correctly when he said it, but I'm glad he (and his colleagues) aren't here anymore. :shakesfist:
    2 points
  46. I personally dislike the attached infographic. It seems to send a bad message, like "NI portfolio is not well suited for production".
    2 points
  47. One could argue that LabVIEW has reached such a state of complete perfection that all is left to do is to sort out the kinks and that those minuscule fixes are what there is left to discuss! 😄
    2 points
  48. Those original scripts will no longer work with new versions of Git. In newer versions the 2 files being diffed will have the same file name. The script needs to account for that condition and rename the remote file. I have a created a similar bash script here that accounts for that. https://gitlab.com/sas-blog/LVCompare-Merge-Setup
    2 points
×
×
  • Create New...

Important Information

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