Jump to content

ShaunR

Members
  • Content Count

    4,191
  • Joined

  • Days Won

    218

ShaunR last won the day on January 25

ShaunR had the most liked content!

Community Reputation

852

About ShaunR

  • Rank
    LabVIEW Archetype

Profile Information

  • Gender
    Male

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    1994

Recent Profile Visitors

20,666 profile views
  1. 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 .
  2. 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
  3. 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.
  4. I think you've either wandered into the wrong forum or are advertising motherboards. Which is it?
  5. Nice. IMO demodulation and using the sound VI's was harder than writing the interface VI's
  6. OS and CPU are defined within a project. You've created a new VI outside of a project.
  7. 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
  8. 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
  9. 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,
  10. 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.
  11. 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
  12. 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.
  13. 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
  14. 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
×
×
  • Create New...

Important Information

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