Jump to content

All Activity

This stream auto-updates     

  1. Past hour
  2. Hi Friends, I am facing issue in labview programming. My vi read csv file in a folder and plot it in waveform graph. Initially i have twenty csv file in that folder, while runnning my vi some more csv files will be added to that folder. The problem is only twenty csv file initially placed got read, later added csv files were not read by labview. Condition: Once my vi starts running, the files will be automatically added to that folder. Because i am running an experiment which stores data in the form of csv file to that folder. How to keep on read the csv files continuosly while my experiments stores series of csv files.
  3. Today
  4. I browsed through all the properties and methods of Call Library object and didn't find such scripting analogue. Seems like VI Server doesn't expose that specific property. Yes, like any other option, I mentioned above. Tried to open my DbgPrintf sample VI from another machine and all the parameters are in place. If you don't have extFuncGenNoWrapperEnabled=True and extFuncShowMagic=True in your .ini, then the option is "invisible" in the menu or on BD, but it's there. 🙂
  5. I'm seeing A LOT of these when re-creating Block Diagrams. It's like LV has no error support at all. If you enable 'dprintf' options in 'LabVIEW.ini', you can at least get some information about reason of the failure.
  6. No need. I will explore this. From experience; a misconfigured CLFN usually results in LabVIEW disappearing without a whimper (either immediately or at some random moment) so i don't see much of a reason to have error checking and wrappers enabled at all. Especially if there is a performance benfit, no matter how minute. It doesn't seem to have a scripting counterpart. Is that correct, or have I just missed it? Is the setting sticky, or does distributed source code require the INI setting too?
  7. No need to assign ill intent. We screwed that up, and we fixed it in LabVIEW 2020.
  8. So you understand the gcc source code? Wow! Just wow!
  9. Isn't that common knowledge in our field? When I attended Technical University, that was one of mandatory classes. In case of LabVIEW, the compiler is LLVM. Meaning anyone who looked into clang also looked into that. The amount of developers who looked into CLang or GCC isn't as small as you suggest. This is actually quite common, if a job requires that. I used LLVM as well at some point, ie. I worked on optimizations performed on Intermediate Language tree. And it so happens that in "Heap Peek", you can look at that IL for any VI.
  10. Are you really wanting to tell me that you understand how a C compiler works? Because that would be impressive!
  11. 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
  12. 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.
  13. 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?
  14. Yesterday
  15. Interesting. How does this feature compare with disabling the error checking on the Error Checking tab?
  16. 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
  17. Last week
  18. 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.
  19. 0_o

    VIWeek 2020

    Thanks for a delightful event
  20. 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?..
  21. 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. 👍
  22. 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.
  23. 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.
  24. 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.
  25. None of the NI devs come here, this is LAVA after all. (/ducks)
  26. 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:
  27. @Bryan Which link are you referring to? I just checked all of them and they seem to be working for me.
  28. All the videos for VIWeek are live: https://labviewwiki.org/wiki/VIWeek
  29. 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.
  1. Load more activity
×
×
  • Create New...

Important Information

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