Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 02/03/2022 in all areas

  1. To all things there is a season. Jeff Kodosky helped found National Instruments and invented LabVIEW. He inspired hundreds of us who shapes its code across four decades. But Jeff says it is time to change his focus. Today, NI announced Jeff’s retirement. He will probably always be noodling around on LabVIEW concepts and will remain open to future feature discussions. But his time as a developer is done. Maybe you didn’t know that? Jeff still slings code, from big features to small bugs. He’s been a developer most of the years, happy to have others manage the release and delivery of his software. I spent over two decades working at his side. He taught me to look for what customers needed that they weren’t asking for, to understand what problems they didn’t talk about because they thought the problems were unsolvable. And he built a team culture that made us all collaborators instead of competitors. Thank you, Jeff, for decades of brilliant ideas and staying the course to see those develop into reality. Your work will continue on as one of the key tools on humanity’s expansion to Mars.
    11 points
  2. June 3 will be my last working day at NI. After almost 22 years, I'm stepping away from the company. Why? I found a G programming job in a field I love. Starting June 20, I'm going to be working at SpaceX on ground control for Falcon and Dragon. This news went public with customers at NI Connect this week. I figured I should post to the wider LabVIEW community here on LAVA. I want to thank you all for being amazing customers and letting me participate vicariously in so many cool engineering projects over the years. I'm still going to be a part of the LabVIEW community, but I'm not going to be making quite such an impact on G users going forward... until the day that they start needing developers on Mars -- remote desktop with a multi-minute delay between mouse clicks is such a pain! 🙂
    11 points
  3. How Software Companies Die – Orson Scott Card The environment that nurtures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it. Beekeeping - Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their fathers' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Jeez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money. Out of Control - Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say. Smoked Out - The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it. Originally from Windows Sources: The Magazine for Windows Experts, March 1995
    11 points
  4. Nice! While you are there please convince Elon to buy NI and turn it back into an engineering company 🤣
    9 points
  5. 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
  6. I've been surprised today with one of the LabVIEW's most useful functions (imo) which I use all the time. After so many years and only now seeing this behavior/feature. I thought I share it 🙂 I've always used an empty array of N-Dim for my desired type input. only to accidently find out today that I can also use a scalar for the type. ha!
    7 points
  7. 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
  8. My new motto No more comments in my LabVIEW code. No icon customization. All VIs named 'untitled<n>.vi'
    6 points
  9. 6 points
  10. The conference went well. We got lots of good video, but it will take a while to edit. I don't have an exact timeframe, but they should be posted within the next month or so. We had an extra cameraman and better lighting and angles this year, so the videos should be even better than last year.
    6 points
  11. 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
  12. With a slightly snarky tone, I want to ask if this is part of the 100 year business plan NI has. On a personal level I just hope LabVIEW can stay relevant until retirement. I do still have a perpetual license to 2022 Q3, which supports Windows 11. So even if NI goes away I'll be able to be in my language of choice until 11 is no longer supported. LabVIEW has changed the way I think about programming in such a way that I think it is hard to go to other languages. My brain thinks in parallel paths, and data dependence, not lines of code and single instructions. Whenever I develop in C++ I can't help but feel how linear it is. I'm sure higher level languages are better, but at the same time I don't really want to change. As long as I can work at a place that needs test applications, and doesn't care how they are developed, I'll be happy pushing LabVIEW. The fog of the future is hard to see though. The next year or two looks very uncertain in my career. But looking at the past, working in LabVIEW has felt like winning the lottery. Thinking about this helps me stay positive.
    5 points
  13. Hello! For a company conference I'm arranging a LabVIEW quiz like the TV-show Family Feud and I would very much appreciate your help to gather response material. If you haven't seen the show, this is how it works in short: Before the show, 100 people are asked a bunch of questions, like "Name a fruit" The 100 people might then have answered: Apple: 43 Orange: 22 Pineapple: 21 Banana: 14 On the show the team then have to guess what people answered. If they guess "Apple", they get 43 points etc. I'm now looking for 100 people (or as many as I can find ) and have made a Google forms with 12 questions. The idea is not to think long and hard about the answers but write the first thing you think of and it might take about 3-5 minutes to answer all of them. If you would take some time to answer the questions I would very much appreciate it! https://forms.gle/QAnjTETdGGoXkyA79 If anyone is interested I can share the results later on. Thank you in advance!
    5 points
  14. As if there were no such personalities on NI forums...
    5 points
  15. Found the issue. The cRIO and PC were connected via a router which was blocking the port used for firmware updates. NI MAX should display a message where the "Updated Firmware" button should be indicating that the port (with port number) is being blocked.
    5 points
  16. I don't have a use case for this but I love that the API uses plymorphic VI's-a vastly underused feature IMO. If you want to organise the functions instead of having a huge linear list, you can group them by separating the menu item with a colon ":".
    5 points
  17. Good Read here, a bit depressing https://nihistory.com/nis-commitment-to-labview/
    4 points
  18. 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
  19. @Rolf Kalbermatter I know you did not mean this, but I love it!
    4 points
  20. 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
  21. 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
  22. (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
  23. 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
  24. 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
  25. 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
  26. 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
  27. They introduced a token for smooth lines: SmoothLineDrawing=False
    4 points
  28. They are trying their best to snap NI at a bargain price, knowing full well that the picture will completely change when LabVIEW 2023 Q4 will be released, instantly doubling the value of NI share price.
    4 points
  29. Today I told NI, that I am not willing to join a subcription program, in which NI can increase the pices as they want or to shutdown my software and that LabVIEW 2022 will be my last version. I just can encourage all other guys to do the same and to not accept such a pricing model.
    4 points
  30. It's probably my limited command of the English language, but for me this sounds about as intelligible as a dissertation about the n-th dimensional entanglement of virtual particles between different universes.
    4 points
  31. I don't know about you guys but I hate writing strings. There's just too many ways to mess it up and, in this case, it might just be to tedious. So, I wanted to create a way to make SQLite create and insert statements based on a cluster. The type infrencing code was based on JDP Science's SQLite Library. Thanks! create and insert from cluster.vi
    4 points
  32. 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
  33. 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
  34. 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
  35. 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
  36. Interesting Demo at NI Connect today. Link starts at NIgel demo.
    3 points
  37. And the saga continues... https://www.reuters.com/markets/deals/national-instruments-picks-fortive-keysight-challengers-emersons-bid-sources-2023-03-03/
    3 points
  38. Hello, LAVA. My team at SpaceX is looking for LabVIEW developers. We have two job reqs open, one for entry-level developer and one for senior. Ground Software is the mission control software for all Falcon and Dragon flights. Every screen you see in the image below is running LabVIEW. Our G code takes signals off of the vehicles, correlates it for displays across all our mission control centers and remote viewers at our customer sites and NASA. It's the software used for flight controllers to issue commands to the vehicles. This is the software that flies the most profitable rockets in the world, and we're going to be flying a lot next year and in the years to come. If you'd like to get involved with a massively distributed application with some serious network requirements, please apply. You can help us build a global communications platform, support science research, and be one of the stairsteps to Mars. Entry level: https://boards.greenhouse.io/spacex/jobs/6436532002?gh_jid=6436532002 Senior level: https://boards.greenhouse.io/spacex/jobs/6488107002?gh_jid=6488107002
    3 points
  39. I can't right now work on that. But I have plans to do that in the coming months. The story behind it is that I did a little more than just to make it 64-bits. - The file IO operations where all rewritten to be part of the library itself rather than relying on LabVIEW file IO. While LabVIEW 8.0 and newer supports reading and writing files that are bigger than 2GB, it still has the awful habit to use internally old OS file IOs that are naturally limited to only supporting characters in file names that are part of your current local and they also normally are limited to 260 character long path names. If your drive is formatted in FAT32, that is all the drive can do for you anyhow, but except for USB thumb drives, you would be hard pressured to find any FAT formatted drives anymore. So having these limitations in the library feels very bad. These two things are specially a problem on Windows. Mac is slightly less problematic and Linux has long ago pretty much solved it all internally in the kernel and surrounding system libraries. - Modern ZIP files support things like symbolic links and I wanted a way to support them. For Linux and Mac that is a piece of cake. For Windows I may for now not be able to seamlessly support that as creating symlinks under Windows is a privileged action, so the user has to either be elevated or you have to set an obscure Developer flag in Windows that allows all users to create symlinks. So in summary there was a lot of work to be done, most of it actually for Windows. Most of that is done but testing all that is a very frustrating job. And the non-Windows targets will then also take some more time for additional testing and making things that were modified for Windows compile again properly. So yes, it's still on my to-do list and I'm planning to work on it again, but right now I have another project that requires my attention. Because of the significant changes in the underlying shared library and internal organization of the VIs it will be almost certainly version 5.0. The official library API (those nice VIs with a green gift box in them) should remain compatible but if you want to make use of the new path name feature to fully support long path names with full character support, you may have to change to the new API, with the library specific path type, although if you use high level library functions, internal long path names will be ok, you just won't be able to access them with the normal LabVIEW file functions if they contain non local ANSI characters or are to long! It's the best I could come up with without the ability to actually changing the LabVIEW source code itself to add that feature into the internal Path Manager in LabVIEW. 😀 The according File Utilities Manager functions in the library will also be available for the user in a separate palette.
    3 points
  40. TDF team is proud to propose for free download the scikit-learn library adapted for LabVIEW in open source. LabVIEW developer can now use our library for free as simple and efficient tools for predictive data analysis, accessible to everybody, and reusable in various contexts. It features various classification, regression and clustering algorithms including support vector machines, random forests, gradient boosting, k-means and DBSCAN, and is designed to interoperate with the Python numerical and scientific libraries NumPy and SciPy from the famous scikit-learn Python library. Coming soon, our team is working on the « HAIBAL Project », deep learning library written in native LabVIEW, full compatible CUDA and NI FPGA. But why deprive ourselves of the power of ALL the FPGA boards ? No reason, that's why we are working on our own compilator to make HAIBAL full compatible with all Xilinx and Intel Altera FPGA boards. HAIBAL will propose more than 100 different layers, 22 initialisators, 15 activation type, 7 optimizors, 17 looses. As we like AI Facebook and Google products, we will of course make HAIBAL natively full compatible with PyTorch and Keras. Sources are available now on our GitHub for free : https://www.technologies-france.com/?page_id=487
    3 points
  41. Realized I never closed the loop on this. It turns out it was a combination of things: intermittent faults in the fiber<->ethernet adapter due to a bad power supply intermittent latency caused by some heavy/spurious network traffic through a switch that was slowing down the TCP traffic throughput After fixing issue number 1, we eventually tracked down number 2 and unfortunately were unable to address as it was related to a separate critical system. Eventually I made some network changes to the cRIO found on this random page from 2009 regarding increasing the TCP buffer size. We've had zero issues in the last 5 months of operation. It feels like a hollow victory though because the LabVIEW TCP calls never threw any errors and my poor attempt at trying to use the system exec VI to monitor the socket memory for increases didn't show anything out of the ordinary, nor did any of the Linux system log/event files. Oh well, at least I sleep better at night now.
    3 points
  42. sounds like they were too busy updating NI Logo and colors to implement VISA. Oh well.
    3 points
  43. As daddreamer pointed out, quite a bit of those functions are actually documented and always have been. The first multiplatform version of LabVIEW shipped with about 15 cm of printed manuals and reached at its top probably 25 cm. One of the many manuals was called the Code Interface Reference Manual. And while the name might have seemed to only be useful in Code Interface Nodes, those functions were always also available in shared libraries too since LabVIEW added official support for calling them. The information in that manual is for most of it also contained in daddreamers link, without the CIN specifics, which are nowadays useless and really have no advantage to shared libraries since about LabVIEW 7.1 but many disadvantages (and the 64-bit versions of LabVIEW do not support them anymore. Yes I'm aware that someone tried to hack them anyways into LabVIEW 64-bit and was partially successful. But it's an exercise in vain as it really has no advantages whatsoever to shared libraries). This is the Code Interface Reference Manual from around LabVIEW 3.1 (Release September 1994). It is 16mm thick and there were about 6 or 7 other manuals like that, some of them more than double as thick than this one. Lot's and lots of trees being cut down for all those LabVIEW manuals! It's for the most part the same as is also in daddreamers link, but there the CIN part is removed and few extra functions are documented that were added since then Some of the undocumented functions could be useful sometimes but being undocumented, it is a bit of a problem as they could change at anytime or completely disappear, which has happened to many of them over the course of LabVIEW development. Some were exported in the past for the compiler to be able to create code to access them directly but are useless to be called from your own external code as you lack access to internal data that needs to be passed to those functions to be useful. Some are still there as a placeholder but simply return a notImplemented error as they were moved to other parts of LabVIEW and only the export remained to make external code that depended on them in the past not load up broken but instead return a runtime error. CINs that didn't load really could throw LabVIEW into a fit. There are various additional managers to the documented Memory, File and Support manager functions in that manual but most are not really helpful. Things I have experimented with in that past and I would have liked to have more official access too, were the MagicCookie handler (all LabVIEW refnums are under the hood MagicCookies), UserDataSession (a more functional wrapper around MagicCookies), (which with the help of something called ObjectManager allows to add special crafted shared libraries through a descriptive text file, directly into the LabVIEW refnum system and access the shared library functions through property and method nodes), Thread, Mutex and Event manager (which basically offers a common interface to the underlying platform threads, mutexes and events), and it even has a Window manager, which abstracts the underlying OS windows into its own window API. But that Window manager is for modern requirements with multi monitor virtual desktops a bit arcane and one of the reasons that LabVIEW isn't that great on such setups. But it is very involved and hairy in some parts to make the various windowing systems such as Mac Quickdraw, Mac Cocoa, Windows GDI and Unix XWindows all map into the same common API. That makes any attempt to change something on one platform a really taunting exercise as it has a great chance to break one of the other platforms. There are also things like a Text manager (a VERY arcane attempt to abstract fonts and text handling into a set of functions), a Dialog manager, which allows to create dialogs in C code that use a LabVIEW VI front panel as resource for the user facing GUI but the entire handling is done in a compiled function from C(++). A Resource manager handles all the binary file formats in LabVIEW that are very much modeled around the old Macintosh resource file format. These are all things that were mostly present in LabVIEW 3 or 4 already, with the exception of the Thread, Mutex and Event manager, which was added in LabVIEW 5 when LabVIEW got true OS supported multithreading, and the UserDataRefnums which were around LabVIEW 7. I have very little knowledge about the interna of things that were added after around LabVIEW 7.1, as that was when I stopped to really dig into the LabVIEW internals. There is an extensive LVVariant interface that gets also exported since around LabVIEW 8.0 and which would allow to also work with Variants in external code, if it was documented. There was some header file downloadable in the past as part of the CUDA toolkit that contained some of these declarations and with it it would be possible to do some experimentation, but without real documentation it is rather cumbersome. Now before you start and scream that NI has kept all these nice cookies from you, consider that most users even struggle with the documented functions already and that are the more simple APIs. Much of what I described above would require several centimeters of printed manuals for each of them! It would also mean that these APIs are absolutely carved in stone and never ever can be changed again, which is something NI has kept to in all this time, unless there was an obvious bug in one of the documented functions. The undocumented functions allowed a much more lenient handling when something needed to be changed. The only people going to scream and show up with a rocket launcher because something broke, were either NI internal people or someone bold enough to hack around undocumented functions, where the LabVIEW developers simply could say: Bad luck! You were not supposed to play with those rusty nails!
    3 points
  44. Here are a bunch of other web resources for colors & UI Design: Data Visualization Since LabVIEW tends to get used a lot in industrial, scientific, and academic settings, it's pretty common that we need to display data in a clear & understandable way. There are a bunch of resources for picking color schemes to represent data to improve contrast, readability, and accessibility (such as colorblind safe palette). Color Brewer: A useful website with a variety of color schemes for displaying data. Has options for sequential datasets, diverging, and qualitative. As well, it shows whether the selected color set is colorblind friendly, print friendly, or photocopy friendly. matplotlib colourmaps: Technically a python resource, but colors are colors. matplotlib is one of the most widely used python libraries for data visualization in python, and they've put a ton of effort into designing good color schemes. There's another library called seaborn that is based on matplotlib that has some more color palettes. Tristen's HCL Picker: A color palette picker which lets you choose colors that are evenly spaced in hue, chroma, or in lightness. This tool is really useful for generating palettes with good contrast. Fundamentals of Data Visualization: A book with lots of useful information on data visualization, from colors to plot styles and more. Design Palettes Making data readable isn't the only thing that matters, sometimes you want to have pretty UIs too. Some handy resources are: Adobe Color Tools: Has a color wheel for designing your own palettes. A tool to extract color themes & gradients from an image (drag/drop a clients logo in there to get a palette based on their company colors), and a tool for checking color contrast for readability. coolors.co: A website with a ton of color palettes to pick from. Material Design Color System: Material Design is primarily meant for mobile & web apps, but the design principles can apply to any application really. The Material Design guidelines have good tips on making intuitive UIs, and provides a palette of nice looking colors. Material Design Palette: To go along with the above. Select your primary & accent colors, and this website returns a palette. colormind.io: A neat website that procedurally generates color palettes. Lock in one or two colors and let the website pick the rest of the palette. mycolor.space: Similar to colormind.io, this auto-generates a palette. ColorSpace takes in a single color and returns several matching palettes. Icons Lastly, good icons can be a great finishing touch. Maybe it's just because I've been using LabVIEW for so long, but I find LabVIEWs icons to be a bit dated. Material Design Icons: A website with a ton of free icons, able to be downloaded as pngs. Adds a nice touch to UI elements. FontAwesome: Has about 1700 free icons. With a subscription, has almost 15k. icons8: Has something like 875,000 icons. Free to use as long as you credit & link to icons8 in an 'About' page.
    3 points
  45. Noting down this mainly for self reference since it occurred to me time and again, in case it helps others too. I have several recent versions of LV installed on Ubuntu 20.04 (with alien). The nice thing is that somehow a NI deb package stream became known to the system, and some package upgrades are found automatically. However there is one caveat: each time the kernel is upgraded, several NI dkms kernel modules need to be recompiled. Usually that is automatically done, but sometimes stumbles on a missing config/modversions.h file. It seems that not every kernel headers package includes it. Missing that, LV crashes as soon as anything needing one such modules is loaded. E.g., as an easy test occurrence, when putting a new VISA control on an empty FP. The solution is trivial: if the (usually empty) file is missing, create it with sudo touch /usr/src/linux-headers-XX.YY.ZZ-generic/include/config/modversions.h where XX.YY.ZZ is the kernel du jour version (e.g. 5.13.0-28 as of today). sudo apt reinstall ni-kal and a reboot then fix the crash.
    3 points
×
×
  • Create New...

Important Information

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