Jump to content

ShaunR

Members
  • Content Count

    4,194
  • Joined

  • Days Won

    219

Everything posted by ShaunR

  1. My tuppence ... choose one, LabVIEW or Python. You can create services which interact through TCPIP or REST API's but keep them separate. If you have 20 python devs and one or two LabVIEW developers then you are on a hiding to nothing. Python won the war a long time ago and it's time to learn Python. Not the answer you were probably looking for but you'll end up mostly doing IT and configuration trying to get your LabVIEW python stuff to work anywhere except your dev machine.
  2. That's because it's hard-coded to return a simple Boolean when compiled. int PQisthreadsafe(void) { #ifdef ENABLE_THREAD_SAFETY return true; #else return false; #endif }
  3. Another SVN user. Meh. The lesser of evils. Not forced. Use it through choice. Pro's: Straight forward workflow. Works from windows context menu's (Tortoise SVN). Use it as a versioned restorable backup with no major hassle. Cons: Same as any other SCC with LabVIEW - merging - but workflow can help (use Branches. Partition work packages to reduce merging. Trunk gate-keeper). Almost never but when it happens, it's always on the merge to trunk - Gatekeepers problem but can recover easily .
  4. No idea. If you save files external to the DB then it mainly depends on the disk speed and the resolution/format you are saving it with. You've only given a rough resulting file size and a framerate. No indication of how many seconds worth that is in order to calculate the MB/frame/sec. Streaming to disk is orders of magnitude faster than to a DB though and the faster the disk, the faster you can stream. If you just want the convenience of a single file for offline post processing then you save them to a directory and zip it all up at the end along with the DB metadata. If you want t
  5. Save the images as files and just index them in the database and any meta data you need. As a rule of thumb, you only save data that is searchable in databases. Images are not searchable data, only their names are. Doing it this way also enables you to process multiple images simultaneously, in parallel, and just update the meta data in the DB as you process them.
  6. I think you've either wandered into the wrong forum or are advertising motherboards. Which is it?
  7. Nice. IMO demodulation and using the sound VI's was harder than writing the interface VI's
  8. OS and CPU are defined within a project. You've created a new VI outside of a project.
  9. Do something you are actually interested in and will be able to use beyond the mere task of learning to program. If you have a hobby, then program something to solve an annoying aspect of the hobby, Perhaps it's that you have to keep printing out user manuals. Perhaps you have to keep calculating something over and over. Identify an issue and solve it programmatically in a way that will actually be useful to you. If you are a gamer, then maybe something to do with how the game operates. For example. Maybe damage output is dependent on a number of aspects such as weapons or various s
  10. I have a whole directory in my toolkit called "Windows Specific" which is for VI's that call the Win32API. But unarguably THE most useful for me is the Win Utils I originally wrote in LabVIEW 5 and still use today. Windows API Utils 8.6.zip
  11. I don't have access LV2020 right now for sets but I maybe have a solution for the arrays which should be much faster and accommodate any number of dimensions,
  12. Maybe make the DLL import wizard actually useful. Not sure why they are doing this though. .NET was supposed to be the next generation of Win32 API's. I guess they got fed up of migrating the functionality. I used to have a program for Windows WMI queries that did something similar. It wasn't one that I wrote but was a tool intended for Borland languages that meant you could query the WMI database live and create the queries in C++ and Delphi prototype snipits. This looks similar for Win32 API's.
  13. Are you suggesting we should grab a sword for the next visit to the sales and marketing dept.? I can see some merit in the idea
  14. Nah. That's just one of those vague marketing place-holders like "synergy" or "convergent" that is deliberately obtuse so that the customer interprets it in their own context.
  15. It depends how it is compiled. There seems to be a function to determine whether the binary is thread safe, yielding 1 if it is and zero if it isn't. int PQisthreadsafe(); Source
  16. I don't know how VI manager does it but here are the things I do know. A fresh install has no tcp settings in the LabVIEW.ini. If you change the VI Server settings then the following settings are added to the LabVIEW ini depending on what you change from the defaults - the prominent ones are: server.tcp.enabled= server.tcp.port= server.tcp.access= There are also property nodes that relate to those settings. Access via these nodes (externally) requires that the VI server is available (i.e enabled). You can turn it off, but not on. In 2020? a new va
  17. I colour my VI's occasionally for 2 reasons. To tell the difference between 32 and 64 bit. Both for LabVIEW version and when using conditional disables for 32/64 and OS's-especially with CLFN's). To mark sections of VI's that have problems or need revisiting. To mark VI's that are incomplete that i must come back to.
  18. Bearing in mind Antoine's comment with which I wholeheartedly agree with, I would suggest upgrading to 2020 now and plan for deliverables with SP1 or later as and when they arrive. You can have multiple versions installed side-by-side on a machine and you want time to find any upgrade issues with your current codebase and gradually migrate with fallback to your current version if things go wrong. Reasoning for 2020 is that that it supports HTTPS - which none of the previous versions do out-of-the-box and is essential nowadays. 2020 is, by now, a known entity in terms of issues and work-ar
  19. /usr/bin/ldd or /usr/sbin/ldd depending on the distro. But the fact that it isn't in your environment path maybe a clue to the problem.
  20. If yo think it's a linking problem then ldd will give you the dependencies.
  21. That's not very American. Where's the guns?
  22. The DLL I used didn't have this feature exposed and I only got as far as identifying the board info before I lost access to the HackRF that I was using. However. From the hackrf library, it seems you call hackrf_init_sweep then hackrf_start_rx_sweep. I guess the problem you are having is that the results are returned in a callback which we cannot do in LabVIEW. So. There are two options. Implement your own sweep function in LabVIEW or write a dll wrapper in <insert favourite language here> that can create a callback and return the data in a form that LabVIEW can deal with. I ha
×
×
  • Create New...

Important Information

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