Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 10/28/2021 in all areas

  1. Try: apt install xfonts-75dpi xfonts-100dpi Then reboot.
    3 points
  2. 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
    2 points
  3. Well I started in April 1992, went to the US for 4 months in May and heard there that there was this big news about LabVIEW not being for Macintosh only anymore, but telling anyone outside of the company would be equivalent to asking to be terminated 😀. They were VERY secretive about this and nobody outside the company was supposed to know until the big release event. In fall of 1992 LabVIEW for Windows 3.1 was announced and the first version shipped was 2.5. It was quickly followed by 2.5.1 which ironed out some nasty bugs and then there was a 2.5.2 release later on that made everything more stable, before they went to go to release the 3.0 version which was the first one to be really multiplatform. 2.2.1 was the last Mac version before that and 2.5.2 was the Windows version. They could not read each others files. This was Windows 3.1 which was 16-bit and still just a graphical shell on top of DOS. LabVIEW used the DOS/4GW DOS Extender from Tenberry Software, that was part of the Watcom C development environment used to compile LabVIEW for Windows to provide a flat 32-bit memory model to the LabVIEW process, without nasty segment:offset memory addressing. It was also the reason that interfacing to Windows DLLs was quite a chore because of the difference in memory model between the LabVIEW environment and the underlying OS and DLLs. Only when LabVIEW was available for true 32-bit environments like Windows 95 and NT, did that barrier go away. NI was at that time still predominantly a GPIB hardware company. A significant part of support was for customers trying to get the various GPIB boards installed on their computers and you had at that time more very different computers architectures than you could count on both hands and feet. There was of course the Macintosh and the IBM compatible computers, with all of them running DOS which Windows computers still were. Then you had the "real" IBM computers who had abandoned the ISA bus in favor of their own, more closed down Microchannel bus and also were starting to run OS/2 rather than Windows and about a dozen different Unix based workstations all with their totally incompatible Unix variant. And then even more exotic beasts like DEC VAX computers with their own expansion slots. Supporting those things was often a nightmare as there was literally nobody knowing how these beasts worked except the software driver developer in Austin and the customers IT administrator. NI had just entered the data acquisition marked and was battling against more established manufacturers like Keithley, Data Translation, and some other small scale speciality market providers. The turning point was likely when NI started to create their own ASICS which allowed them to produce much smaller, cheaper and more performant hardware at the fraction of the cost their competitors had to pay to build their own products and still selling them at a premium as they also provided the full software support with drivers and everything for their own popular software solutions. With other manufacturers you usually had to buy the various drivers, especially for NI software, as an extra and some of them just had taken the blueprints of the hardware and copied them and blatantly told their customers to request the software drivers from their competitor as the hardware was register for register compatible with theirs. The NI ASICS made copying of hardware by others pretty much impossible so NI was never concerned about making their drivers available for free.
    2 points
  4. It's still the same. You can not have multiple tasks accessing the same DAQ card for Analog input. You need to combine the channels into one task and one scan rate and then pick out the data as needed and distribute it to the different subsystems as needed.
    1 point
  5. Here they come for 2019. For the little these require sets, i.e. only to find the common elements among two character arrays, I think that it would be pretty easy to reimplement them without, for earlier versions. StrikeAMatch.vi StringDigrams.vi
    1 point
  6. Regarding Levenshtein: Wladimir Levenshtein developed 1995 an algorithm for this. It is called the Levenshtein Distance. Some years ago I developed a VI to calculate the Levenshtein Distance. Here it is (LabVIEW 2016). Can you post your VIs in LV2020 or 2019, please. Levenshtein Distance.vi
    1 point
  7. Hi, this is my guide on how I install VIPM on Linux. In this case Ubuntu (conversion of rpm to deb is done via alien). Hope it helps. VI Package Manager is not yet available for LabVIEW 2020 Linux follow up here. This is a workaround that can be used to install VIPM 2017 and make it work with LV2020 on Ubuntu Server. Useful links, especially about softlinks and icons are taken from here and here Assuming that the vipm tar file is placed in a VIPM folder in home, extract them in the home tar -pxvf ~/VIPM/vipm-17.0.2018-linux.tar Add i386 architecture (for downloading packages i386 that are needed) sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install -y libxinerama1:i386 sudo apt-get install -y libgl1-mesa-glx:i386 sudo apt-get install -y xfonts-75dpi xfonts-100dpi Install dependencies: sudo apt-get install -y lib32stdc++6 sudo apt-get install -y lib32z1 Convert i386 into tgz and then back to deb (for alien to manage to convert 32bit packages in a 64bit system). Clean up and install LabVIEW 2015 cd ~/vipm-17.0.2018-linux/LabVIEW2015SP1RTE_Linux/ #sudo rm ni*.rpm sudo alien -ckt *i386.rpm sudo alien -ck *.tgz sudo rm *.tgz sudo rm *i386.rpm sudo alien -ck *.rpm sudo rm *.rpm sudo dpkg -i labview-2015-rte-32bit_15.0.1-1_all.deb Copy JKI folder, give proper permission and make links so that all libraries are found sudo cp -r ~/vipm-17.0.2018-linux/JKI /usr/local/ sudo chmod +x /usr/local/lib/LabVIEW-2015/liblvrt* sudo ln -sf "/usr/local/lib/LabVIEW-2015/" "/usr/lib/" sudo ln -sf "/usr/lib/LabVIEW-2015/liblvrtdark.so.15.0.1" "/usr/local/lib/liblvrtdark.so.15.0" sudo ln -sf "/usr/lib/LabVIEW-2015/liblvrt.so.15.0.1" "/usr/local/lib/liblvrt.so.15.0" Add VIPM in application launcher and make it start with sudo when clicking on it. I am attaching the vipm.policy, vipm.desktop and pkexec-vipm used below to this post. sudo cp -p "/usr/local/JKI/VIPM/icons/linux/VIPM 48x48 - 32bit.png" "/usr/share/pixmaps/VIPM_48x48_32bit.png" sudo cp ~/VIPM/vipm.policy /usr/share/polkit-1/actions/ sudo cp ~/VIPM/vipm.desktop /usr/share/applications/ sudo cp ~/VIPM/pkexec-vipm /usr/bin/ sudo chown root:root /usr/share/applications/vipm.desktop sudo chmod 644 /usr/share/applications/vipm.desktop sudo chown root:root /usr/share/polkit-1/actions/vipm.policy sudo chmod 644 /usr/share/polkit-1/actions/vipm.policy sudo chown root:root /usr/bin/pkexec-vipm sudo chmod 755 /usr/bin/pkexec-vipm pkexec-vipm vipm.desktop vipm.policy
    1 point
  8. It's not under Front Panel. It's under Tool Bar. If you find your mind again, ask it to tell mine that I need it now.
    1 point
  9. It calls a private internal method, yeah. NI policy is that VIs that call private properties/methods/events are password-protected.
    1 point
  10. We have had some similar issues. In general we could get in touch within a few days of pestering, but occasionally we escalated to the (3rd Party) sales rep as well. Support has certainly taken a noticeable hit in the last couple years.
    1 point
  11. If I'm not mistaken, the Upgrade Code is simply a GUID: https://stackoverflow.com/questions/4313422/generate-guid-in-windows-with-batch-file
    1 point
  12. Couple of years ago I was working with SREC files, but I only needed to import them. Initially I used LabVIEW but switch to C# as it was more suited. This is only the import part, maybe it can get you started (reverse the process?, idk). as Rolf said, my concern was only import and my project requirement and then switched to C# anyways, the only thing I tested was making sure both my LabVIEW and C# were doing the import the same way. Parse SREC File.vi
    1 point
  13. I think the UA_Server_run function may just write the boolean state to the running parameter (an out parm). Difficult to say with the info given but Pointer To Value for "running" might be all that's needed. The static volatile "running" variable is a red-herring in that it is an application variable that would be in LabVIEW as would the stopHandler. If the server is stopped and started by toggling the boolean, then there is a serious problem with either the DLL that exports UA_Server_run or the OP's understanding of how it works. I wouldn't be surprised if there is a UA_Server_stop which we haven't been shown.
    1 point
  14. It's pretty unclear what you really try to do. You mention CLNF and all that and have a DLL but you talk like you would like to implement everything in LabVIEW. My suspicion is that you still want to call UA_server_run(), but from LabVIEW and the bad news in that case is that you can't do what you try to do. LabVIEW is dataflow driven. While it allows to call C functions, it doesn't and can't implement the full C semantics. Once it passes control to the UA_server_run() function in the Call Library Node, this code executes on its own until it decides to return. But since LabVIEW is dataflow driven and doesn't know pointers like in C, you do not have access to the memory location the running boolean is stored at that you pass to the function. If you branch the wire, LabVIEW will very "helpfully" create a seperate copy of that variable, not just pass a pointer around, since passing pointers around would completely go against the entire dataflow paradigm. You will have to create a wrapper DLL that implements and exports the stopHandler() function as well as a function that calls UA_server_run(), passing it the DLL global "running".
    1 point
  15. If you export running global variable from your DLL, then you could get its memory address with GetProcAddress and pass it to your UA_Server_run function as the second argument. That should work, if I got your tactic right.
    1 point
  16. Sounds like a cool project, especially with a real 6502 thrown in. I remember seeing an open source Apple II emulator written in LabVIEW: https://sourceforge.net/projects/labviewapple2/ Not sure how well it runs, but might be interesting to compare notes.
    1 point
  17. Yeah. If you want a clean image at zoom you'll have to mask it. woopswee.vi
    1 point
  18. You can use the shortcut menu on a property node to select the .NET class. The one you are looking for is in the mscorlib assembly. System.Environment.vi
    1 point
  19. I typically use a second lvproj file, not for installers, but for the unit testing. The benefit is that I can segregate the dependency on the unit test framework (i.e. Caraya) from the source file that runs the build specs. Although, I don't know if that's super useful if you use a CI server to run both UTs and perform your builds...
    1 point
  20. Hello experts, I'd like to make a general assessment. I have been working with Labview for about 20 years and occasionally contact Ni to solve technical problems or to find out about and buy products. I have been observing the trend that service has been getting worse and worse over the years for years now. I have not seen any real new developments in labview over the last 10 years. with the termination of nxg and the associated waste of resources, I have the impression that ni has to save money at every corner to keep the shop running. of course this is at the expense of customer support. i wonder if ni is about to go bankrupt or what is the strategy behind it? slowly i am looking around for alternatives to labview as i can hardly see a future for labview after the current impression. how do you see it...? what is your impression? greetings, jim
    1 point
  21. Glad it helped. Is there a repository somewhere of these types of gifs? I'd love to have a library of controls or something. Like I mentioned a QControl can probably handle this well.
    1 point
  22. I thought this was an interesting exercise so here is my attempt. OpenG has some image tools and one of them is the ability to open a GIF, but for some reason it crapped out and died with your GIF even after resaving it to something much smaller. I did find some other GIF API over on the dark side and instead used that. Attached is a zip, extract it and run Demo Saving Button. It will show the first image. Then when you click the image it cycles through the first half of the GIF and waits for the simulated save process to complete. Once it is complete it rotates through the second half of the images, and then after a few seconds returns back to the first. Parsing of the GIF takes time so I put in the GIF images as a constant, along with the code to parse the GIF. I also set the pane to be the color of the (0,0) pixel in the hopes it will blend in better. Honestly this could be turned into a QControl and be made very seemless. Demo Saving Button Gif.zip
    1 point
  23. I promise I haven't been working on this for 5 years. But I thought I'd come back with something new that I think is a bit better in some ways and a bit worst in others. This method works a bit better when it comes to encapsulation. I wrote a single Image Grid class that can be created, updated, and destroyed. When creating it you specify the Subpanel that it should be inserted into. This means that we can likely turn this into an XControl one day. The previous method of having parent/child windows floating around that needed to be resized and moved, complicated that encapsulation and likely never could have been in an XControl. Resizing in my opinion is done better here too. Instead of generating a resize event, and then having to resize each window, we just let LabVIEW take care of it. LabVIEW is pretty good at resizing when using panes and having a single object fit to that pane. So when a resize occurs the only thing that is done is the optimal number of rows and columns are calculated and if there is no change then nothing else needs to happen in the G code. Minimum pane sizes are used so that hopefully things don't get too small if the subpanel is set to fit to the pane. Now the new limitations...this is limited to the number of subpanels I made and at the moment this is 20 rows, and 20 columns. It is possible I could have gotten creative and generated all the prime number of subpanels, and then used dynamic subpanel subpanel insertion to get an unlimited number but wow that sounded difficult. I figured how often will I need more than 20 rows or columns? Another limitation is at the moment you cannot add or remove images without closing the session and opening a new one. The properties of each image can be manipulated quickly by providing the index, and the new Caption, Disabled Status, Image Path, or Background color (alpha layers supported BTW). Also no way to modify the caption other than the text. I'd like to add a hide/show ability and a way to change font size. Anyway source is 2015, uses OpenG and here is a video. It is slightly smoother to resize than it looks in the video. https://www.screencast.com/t/qdZMxBuzprH Image Grid Subpanels Of Subpanels.zip
    1 point
  24. I've been using the Statechart module for a while now, and find it really useful. I haven't yet seen any discussion of how best to put statecharts into practice (please share a link if there is one). Some things to discuss: Synchronous or asynchronous? How do you call the statechart? What architecture to use? Passing data in and out of the statechart: Do you stick to the input/output wires, or use other methods like queues, or vi server? As for me, I have built a couple of really big data acquisition and control systems using synchronous statecharts only. I have a three loop top level VI which deals almost entirely with the user interface. The first is an event loop which deals with button pressing etc., and passes the input cluster to a queue which is read by the second loop. This calls the statechart VI every 100ms or so. It dequeues the input cluster, runs the statechart, and passes the outputs to a third loop using queues. The third loop updates the display. All of the actual action (DAQ, logging etc.) takes place inside the statechart. As well as using the inputs, I also am using queues to send commands into the statechart (for example to trigger a transition; the queue ensures the command is only carried out once.) Its possible this could be accomplished by using the inbuilt statechart triggers, but I have not tried that yet. I have found a few difficulties to do with synchronisation of what is going in inside and outside the statechart vi, but in general the Statechart module is incredibly handy. For interest here is an example of the statechart I am currently working on. (N.b. I'll be using LuaView as well to implement scripting! The lua commands will send a user event to the vi which calls the statechart.). One benefit of the statechart is that it allows you to do tasks in parallel, while communicating over (for example) a single serial port, while not worrying about communication clashes, as each state is executed in sequence. I'd be very interested to hear about other people's experiences. Alex
    1 point
  25. Not quote - if you pass the CLAD then you can ask for a present! :laugh:
    1 point
  26. Historically support is something I've said NI and Microsoft both have been done well. Lately I'm having a harder time lately singing NI's praises for support. NI used to have all new hires work support first before going to other departments. This in general made support a bit green, and you'd need to escalate a couple of times before getting what you needed. My career started as a co-op and so being thrown into the deep end of the pool certainly helped me learn quickly. And I liked the idea of NI people all starting out having to quickly get familiar with NI's offerings, and being close to the customer issues. I suspect NI has gotten feedback over the years that this model for support didn't work well and I heard NI was changing this policy.
    0 points
×
×
  • Create New...

Important Information

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