Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Today
  3. I work 5 years as labview 'developer' and when someone from other technologies asks me how this compiles and really works my answer is i ve no idea. When on the other side open technologies give much deeper ride and control. It might be due to my limited understanding of LV but detailed information is not there on official NI forums. I guess it is up to discussion if You need low level understanding how LV or other technology works. In my case as sw engineer I always want to know how things work, and the longer i work as engineer i realize i ve no idea how 90% of things work
  4. Even when Error Checking is set to Disabled, LabVIEW still enters ExtFuncWrapper to do some basic checks before the target function is called. A few internal functions, such as _clearfp and _controlfp, are being called also. Thereby disabling "Generate Wrapper" option should make CLFN a little faster, than disabling Error Checking. You can take it like you're calling a built-in yellow node (not taking into account the called function's own speed, of course). I did not do concrete benchmarking to compare these two options. If there's an interest, I could check this out.
  5. It's like moving the Expression Node back in some subpalette of the Mathematics functions that is not existing in the Base LabVIEW version (https://forums.ni.com/t5/LabVIEW/Expression-Node/td-p/3974820). Completely uncalled for, but, hey, AQ doesn't think that text-based mathematics should even be allowed in LV, so what do we know?
  6. Yesterday
  7. Interesting. How does this feature compare with disabling the error checking on the Error Checking tab?
  8. Hello I am quite new to labview and I have some questions regarding labview. We have came up with a simulation build in labview as shown in the folder. However, we will be making use of Myrio to connect current and voltage sensors to send the data to labview when labview is running. We are currently having difficulties trying to search if it is possible to send the wave files and the popout messages ( messagebox.vi and Player2Wins.vi) to NI Dashboard for Labview in Ipad by using myrio. Is it possible for myrio to store wave files and the additional VIs and sending these to NI Dashboard for Labview? Otherwise, it is possible for Labview to send the entire program.vi, messagebox.vi and Player2Wins.vi to cloud and people are able to see the GUI in program.vi remotely? ( We have found information like Labview web services etc. We hope that people are able to view our GUI and press the " Press start" button as well as closing the popout messages in a website not from our local network). I sincerely apologize if what I am asking does not make sense to people who are reading this. I hope that someone will help me with this as it is very difficult for me to do and I need some guidance from people who are familiar with these. Thanks for taking your time to read and your reply. Simulation_Build_(3).zip Pop-up_Message.vi Player2Wins.vi
  9. Last week
  10. I didn't mean to indicate that you had to wire the return value. I actually never even tried that as it seemed so out of touch with anything. What I do believe to remember however is that LabVIEW required you to wire the left side of parameters. However that's 20 years ago and it could just as well have been the CIN node. Much of the object handling for the CLN was inherited from the CIN node and there you don't have a return value. In fact I'm pretty certain that the return value of the CLN is basically simply a parameter as far as the node object is concerned, in order to be able to reuse much of the CIN node object handling. The fact that the first parameter is specifically reserved for the function return value is most likely mostly a special casing for the configuration object method and the run object method of the CLN. Most other methods it simply inherits from the common object ancestor for the CIN and the CLN.
  11. 0_o

    VIWeek 2020

    Thanks for a delightful event
  12. I checked that in LabVIEW 3.1.1 and it doesn't require the Return input terminal to be connected to some constant. I also tried LabVIEW 3.0 and 2.5 but I don't see CLF Node there, only CIN, so can't check there. Got the same in LabVIEW 4.0 (in fact it's a demo version, but DLLs are callable). I still think, there's some sort of a bug, because in LabVIEW 7.1 and 8.0 when you created that unnecessary constant on the left, connected it to CLFN and changed the Return type back to void, the VI's Run arrow becomes broken. The same applies to the wire from the constant to CLFN. But in LabVIEW 2009 and higher the Run arrow is fine and LabVIEW allows to run the VI despite oddity with the CLFN (look at the image above). This is the screenshot from LV 8.0: Might be an omission when porting to the new managers interface?..
  13. Aspiring to be the World's 2nd Fastest LabVIEW Programmer is indeed a noble goal. One of the things that makes me fast is the fact that I know exactly what the first three menu options will be, 100% of the time, whenever I right-click on any data type (terminal or wire) on a diagram. 👍
  14. I see it similar to how a car works. I know how to operate it and the traffic rules and similar but I really do not plan on learning how to take it apart and put it back together again. Some people do, but if you try that with a modern car you are pretty quickly limited by the sheer complexity of the whole thing.
  15. Are you completely sure about narrowing what is 'productive' in this way? That excludes a lot. I have specific goals in my research, though this is side project of a side project now. Knowing exactly how LV works should be one of a main goals of healthy community around the project. Unless there is no real community, and everyone is here only due to business ties.
  16. Sure a few are here who even respond to various posts. But to respond to this type of topic could easily be construed as violating non disclosure agreements you nowaday have to sign anywhere when starting a job and as such could be an immediate reason for terminating their job and even liability claims. They know better than to risk such things. Besides this type of archeological digging may be fun to do in your free time, but it leads basically nowhere in terms of productivity. It's up to you what you do with your free time, and if this gives you a fuzzy feeling somehow, then I suppose it is not a bad thing. But don't expect that there are many more out there who feel the same.
  17. None of the NI devs come here, this is LAVA after all. (/ducks)
  18. Oh, I see. From the knowledge I've seen shared, I assumed devs are here. So to explain my road to here: Many parts of the VI file revolve around definitions of Data Types, called TypeDesc or TD in code. TypeDesc defines kind of each type (can be Cluster, RepeatedBlock, various types of ints and floats, etc.) and any additional properties of the type (ie. Array has dimensions, and RepeatedBlock has number of repeats). The TypeDescs in LV>7 are stored in VCTP (VI Consolidated Types) block, then subset of the types creates Data Space - this subset is defined and given flags (tmFlags) by TM80 block. In older versions of LV, there is DSTM (Data Space Type Map) block instead of TM80, and TypeDescs are defined directly there instead of pointing to VCTP. So it looks like types were consolidated in LV8 - before, each type was defined in the place where it was needed; after - all types were moved to VCTP, and other places just point to specific TypeId in consolidated list. Now for the Data Space - part of it is filled by values stored is DFDS (Default Fill of Data Space), the rest is just initialized by default values, ie. zeros. But in DFDS, the values are serialized (LV calls this Flattened), so they don't exactly match the look they have in the final Data Space created when the VI is being loaded. Actually, the structure of the Data Space when it's loaded is such that offset of data for each TypeDesc is invariant - so if there is any data of dynamic size (meaning it can change size without TypeDesc change), the Data Space stores it as a pointer. And this is how we come to the Offsets I was asking about - these are Invariant Offsets (because they don't move as long as TypeDescs doesn't change) pointing to where the items are in the unflattened Data Space. To visualize all that, this is how the Data Space looks in Heap Peek; marked values are tmFlags:
  19. @Bryan Which link are you referring to? I just checked all of them and they seem to be working for me.
  20. All the videos for VIWeek are live: https://labviewwiki.org/wiki/VIWeek
  21. That's easy to answer. You lost everybody including me already quite some time ago. The only ones who could answer your questions are people with access to the LabVIEW source code and they can't and won't answer here. The rest have never gone that far into LabVIEW interna and likely have much much more important things to do.
  22. I successfully used oglib_lvzip-4.1.0-b3 from this post, enhanced for 64-bit LV by Rolf. It always worked good for me.
  23. The main reason is that NI does not want to document the API for these functions. Not so much because it is secret but because once they are documented they can't change it anymore. Without having them documented (and an open VI diagram with the according CLN configuration is a sort of documentation too) they can't just go and change it easily as someone might have relied on this API and created his own VIs. With locked diagram they are free to change the API at any time and only have to update the according VIs that are shipped with LabVIEW and all is fine. If you sneaked into the diagram anyhow and used it, that is all your own fault. 😀
  24. These ZIP VIs that come with LabVIEW are all single CLNs that call directly into LabVIEW, as NI has basically included ZLIB and the according old style ZIP file functions that come in the contributed folder of the ZLIB distribution and which were developed by Gilles Vollant. OpenG ZIP Library uses the same code, just likely a newer version. The LabVIEW inlcuded code does not allow to query the implementation version of the library so it's hard to say how up to date it is.
  25. There are several levels in a ZIP file. A ZIP file is an archive format with things like directory entries, and stream headers. The directory entry contains records for every stream inside the archive (a stream is pretty much a single file entry in the archive) and each stream has its own header. The individual streams are compressed using the ZLIB algortithme with a small header in front. So while the ZIP file does use ZLIB to compress the individual streams it is anything but a ZLIB compressed stream in itself. GZ is closer to a single ZLIB stream but needs an additional header that tells the decomprosser about how to configure the decompression, so the file content is not a ZLIB stream but a bit more than that. The OpenG ZIP library is mainly an implementation of a ZIP archive reader and writer but uses at its core the zlib library for the compression and decompression, just as the ZIP library does that is included in LabVIEW. While the LabVIEW provided ZIP library only exports a few high level functions to be accessed, the OpenG version goes a lot further and basically exports a lower level API on which the whole ZIP archive handling is implemented. And in addition it also exports the according ZLIB inflate and deflate functions that allow you to implement any compression that is based on the ZLIB compression method. It would be possible to implement GZ and similar formats on top of this without a lot of effort, by simply implementing a LabVIEW library on top of these ZLIB methods and some LAbVIEW file IO methods.
  26. Actually, the nipkg.ini is in \ProgramData\National Instruments\NI Package Manager\Settings\nipkg.ini
  1. Load more activity
  • Create New...

Important Information

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