Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. These are purely stylistic issues. I'd personally prefer Boolean and subVI, but I'll follow the community guidelines (when they are produced). This one has ramifications for the ease of understanding of an article (especially for newcomers). I'm not sure what's best here. Perhaps we can let NI spearhead the effort to "normalize" the use of "G". We can stick to "LabVIEW" for now since it's more common, but switch over to "G" later when NI's efforts bear fruit. I'm with Rolf; same-page is much more useful in the forseeable future.
  4. This thread is about literature, not code. It's a question of finding a balance between practicality and professionalism. Side A can reasonably accuse Side B of being a Grammar Nazi while Side B can reasonably accuse Side A of being sloppy. My response would be "be consistent within a project". Feel free to have different conventions across different projects. So for the Wiki, we should at least be consistent within a single article or group of closely-related articles. Some might even argue that the whole Wiki is a single project. No, as long as you don't care when people write "LabView".
  5. Yesterday
  6. This is a historical "problem" due to compilers being case sensitive. This was one of the reasons that I went for Pascal compilers over C since Object/Open/Turbo Pascal is case insensitive and boolean or Boolean are synonymous (as a type). I've always maintained that there is no excuse for case sensitvity as it only introduces errors, obfusicates and increases foot-shooting but has zero benefits (unless you consider obfusication a benefit which is arguably a security risk). I've had many conversations with C/C++ programmers over capitalisation of types and function names (initial caps vs camel case vs lower case etc) and my response has always been "whatever". Do we really need to bring this problem to a wiki, of all things, about a language in which case is irrelevant?
  7. All very good points and good concerns. Personally I would capitalize Boolean, but I may forget occasionally. I would also prefer subVI as I've gotten used to the NI standard. I can see the confusion with LabVIEW and G, and often I go back to what the community at large uses. If I say "My programming language of choice is G" some may confuse this with GCode, or something else. If I say LabVIEW I think that conveys what I mean to the general public more. For this reason I default to "LabVIEW" but at times will say G. Public opinion may change, and that may mean updating the wiki. And if there are specifics I'd prefer separate pages for 20xx and NXG, but whatever. One thing you might not be aware of is that there is a place for page specific discussions on the Wiki Talk Page. You could make an edit, but leave a comment asking for direction or leave it open to preference. That being said I think the opinion of most moderators on the Wiki is more that getting something which is non-perfect, is better than having nothing. I'd encourage others to make pages and fill in what they can, even if they are unsure of how to handle some of these differences. Things can always be cleaned up and refined later.
  8. I agree with Rolf, I think most people are not as strict as you are. And while we're at it, what version of english should be used? American english or British english or any other flavour. I thought about this when I read capitalising spelt with "z" 😂
  9. Hello! Thank you for this Lib! It is very usefull and smart to use!
  10. Thanks for the replies! As usual, I did things wrong. This time it was with the testing. When I started I tried with the actual property names with the illegal characters. But the tested files (which were chosen randomly) were probably all files that was once re-saved with Diadem. Then I tried with the underscores, this time probably on totally different files which were never re-saved in DiAdem. Funny thing is that I tested multiple times with the underscore, seeminly always on non re-saved files... Anyways, Now I look for both the original property and the fixed property. Thanks Antoine for the illegal characters' list. I used it as the search+replace regex search string.
  11. While you bring up valid points here, I think there is no standard whatsoever in the community about this so far. Everybody does as he or she feels at that particular time of the day and may do it different the next day. So if you want to bring this up, it may be a good idea to document it somewhere in the wiki. Basically start some sort of recommended style guide there. Obviously not everyone will read it and even if someone does he won't be shot if he does not follow it. 😀 About your last point I would personally prefer to have different sections on the same page for now. I also don't see deprecation of pages going to happen anytime soon and definitely not as a separate task that anyone would take upon himself. If something will be deprecated in the future it will be likely as part of editing a page for other purposes such as adding information about new features or similar. And it is anyhow at least 7 years in the future as NI committed at some time to a support timeframe of 10 years for LabVIEW CG after the first NXG version was released. 😁 With the current progress of LabVIEW NXG that might be about the time it reaches feature dominance over LabVIEW CG. 😆
  12. Last week
  13. Yes, I meant get properties, and it didn't return those properties. I tried TDMS viewer, some 3rd party labview viewer and those didn't find my properties either Okay, I will try a few things next week (testing with proper property names). If it's successful, I'll rewrite my set properties code. I'll make two versions of the getter to deal with the old files with the illegal property names. Or something...
  14. If was written successfully, then it can be read too. The key is to find out what name was stored in the TDMS file. If you call TDMS Get Properties.vi without wiring the "property name" and "data type" input, you're meant to get an array of all available properties in the "property names" output. I presume you meant TDMS Get Properties.vi? If so, then that's very weird. My next guess would be you're opening different files in LabVIEW vs. DIAdem. Try calling TDMS Get Properties.vi without the name inputs immediately after you write the custom property.
  15. Well in that case the remark about the DLLs having to be compiled for ARM was really off. That is for Windows IoT installations on targets like the RPi and similar boards which all have an ARM CPU (and accordingly can't run Windows IoT Enterprise either which is a pure x86/x64 install). It all depends on which C compiler they used to create those DLLs. Until Visual C 2015 or so each Visual C version come with it's own specific C runtime library that had to be installed on every target on which you wanted to run an executable or DLL created with it. While many parts of Windows are compiled with Visual C too and therefore cause the Windows installation to come with the needed C runtime support already installed this can and will vary depending on the Windows version and the amount of extra tools and utilities that you install. Also any extra custom application you install such as LabVIEW also comes of course with the necessary C runtime support that gets installed if not already present on the system, but depending on all this a particular C runtime version may or may not be present on any particular system. Basically you should never copy DLLs to a target system but install them with the proper installer for them which hopefully takes care about installing the correct C runtime support too.
  16. Yes, correct Rolf. The target was the enterprise version & that's why it ran in the first place. Interestingly enough installing the exe on 3 other machines under Win10 resulted in the 2 working & the 3rd not finding the dll just like the Win10 IoT. With a new build it suddenly didn't find the dll on one that did work. With not having time to debug I created an installation and the program worked since even with new builds. On regular Win10 there shouldn't have been an issue... At this point I'll try and link the latest 64bit Postgres dll's & try that.
  17. Here is an answer by NI about why DIadem and Excel add-in do weird things with spaces. https://forums.ni.com/t5/DIAdem/Spaces-In-Property-Names/td-p/2831180 Basically its due to how it is indexed and put into a database. The standard LabVIEW TDMS API does allow writing and reading properties with spaces in them.
  18. I did realize earlier that I used "illegal" space character in the property name and I'm aware illegal characters are replaced with underscores in DiAdem. I think I have a theory which I can only try on Monday: set properties does accept the illegal characters "silently" without fixing but read property doesn't find properties with illegal characters (because my first read property try was with spaces and it was not successful. At set properties I don't get errors). I was deceived that set properties was okay because DiAdem and Excel importer do accept spaces but replaces them with underscore. Later I also tried read property with underscore without success. This implies that the illegal character fixing happens in DiAdem and not by set properties as I took it as given. So the question is: is it possible to read property names with illegal characters somehow (so that I can read old files too) in Labview, if it is possible in Diadem? Of course my first try will be to read with spaces, but only on Monday. I was too excited to wait with my posts...
  19. Hi, I am glad that I found your library but would you mind saving it for Labview 2014 please?
  20. If you want to run the VI in the IDE as a tool of some sort, save it into the "<LabVIEW>\project" subdirectory. Every VI in that directory gets automatically picked up and added to the Tools menu. The menu item gets its text from the display name of the VI, saved in VI Properties. When the menu item is chosen, your VI is run in an isolated application instance so it never interferes with running applications. App instance isolation is how all the G parts of the IDE execute, like the icon editor, the getting started window, or the right-click menus.
  21. maybe this thread can help you, at the end it give the list of forbidden characters.
  22. Does the Get Properties return an error? If so what is the error? Show your VI that does the reading and writing. Oh and what is the property names there are a few that NI reserves.
  23. I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree? When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example). Are there any particular conventions that the community has established that differ from NI standard practices? When discussing language features (as opposed to editor features), LabVIEW 20xx uses "LabVIEW"... LabVIEW NXG has moved to using "G" and uses "LabVIEW" to discuss the IDE. We find that this provides clarity in many documents, and it provides less of a mouthful when speaking (The NXG root class is "G Object" instead of "LabVIEW Object", for example). Does the wiki prefer "LabVIEW" or "G" when discussing language features? When behaviors diverge, what is the preferred way to document distinctions between LabVIEW 20xx and LabVIEW NXG? Should they be separate pages (so the former can be easily deprecated in the future) or do we prefer same-page-different-sections for easier side-by-side comparison?
  24. I tried to update this existing image with a new version of the PNG: https://labviewwiki.org/wiki/File:Screen_Shot_2019-06-27_at_1.50.14_AM.png#file I keep getting an error: [XSir2GJrsGEvUGpzBj7-DAAAAAQ] 2019-07-12 15:48:40: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" Anyone know what's wrong?
  25. Channel for both. And I checked the written files in diAdem, the property is porperly on the channel level. Also I managed to read "standard" properties from the channel in Labview which are only valid at channel level (displaytype for example) and it works, so there shoudln't be a mistake.
  26. What level of properties did you write? File, Group, or Channel? What level of properties are you trying to read? File, Group, or Channel?
  27. Hi all! I'm new to the forum and I have a strange issue with reading TDMS custom properties with Labview. Creating user properties is working fine using TDMS Set Properties.vi, but I can't read them with TDMS Get Properties.vi. I can read the "standard" properties, and also I do see the properties in DiAdem (dataportal and using script) and also in Excel when I use TDM(s) importer. The property names are not listed when calling TDMS Set Properties.vi without the property name and data type terminals connected. There is no simultaneous file reading or writing. I solved the problem with loading DiAdem and running a script, but that's very slow and also not all target machines have DiAdem installed (and no licence either, obviously). I also tried with property names such as User Properties\Device_ID, User_Properties/Device_ID in whatever combinations (I look for the property "Device_ID") without success. Thank you for any hints in advance!
  28. Our team is responsible for the design, implementation, testing, deployment, and maintenance of LabVIEW based data acquisition and controls systems that support rocket engine test stands, component testing and ground support equipment. You will share in the team’s impact on all aspects of component, vehicle subsystem, and engine testing. This position will directly impact the history of space exploration and will require your dedicated commitment and detailed attention towards safe and repeatable spaceflight. Do you love OOP, actor-framwork and real-time systems? If so this is your team. Position is for the Kent Washington office. Must be a U.S. citizen or national, U.S. permanent resident (current Green Card holder), or lawfully admitted into the U.S. as a refugee or granted asylum. https://blueorigin.wd5.myworkdayjobs.com/en-US/BlueOrigin/job/Kent-Washington/Data-Systems-Development-Engineer-lll_R538 https://blueorigin.wd5.myworkdayjobs.com/en-US/BlueOrigin/job/Kent-Washington/New-Glenn-Production---Data-Systems-and-Controls-Engineer_R-19-3626-1
  1. Load more activity
  • Create New...

Important Information

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