hooovahh

Honestly I don't see any problem with just making a normal post asking for advice. Plenty of times someone will post a "This is how I did my CLD what do you think", or a "I'm new at LabVIEW how can I improve this" and as a collective we look over the code, post improvements and suggestions. I don't think it has ever been attempted with large projects so I don't know how it would go down. I think smaller programs work well because the effort from someone is small to open the code and say a few things. But for a large application I wonder if you won't get much contribution, because the time needed to understand the intent of the code, and then post solutions/suggestions might be larger.

Undocumented features causing LabVIEW to behave strangely? Inconceivable! But to be fair LabVIEW isn't bug free, and weird stuff like this can happen with normal features too.

I think that could be possible, if Windows supports multiple logins at the same time which it looks like over normal RDP you need the server edition. I'm not sure if other remote control programs allow for multiple logins at the same time. If they do then this shouldn't be a problem, as long as each user knows to only use their hardware. There maybe a LabVIEW solution in there, but personally I would rather use something simple that worked, rather than trying to roll my own method of hardware sharing over the internet. That problem has been solved by many companies already, just use one of theirs.

Wow that is some interesting results. I'm always interested in TDMS performance. Your timing function is a little flawed but the data is probably still close. UI elements in LabVIEW are updated asynchronously. So to get an accurate measure of how long a function takes to operate, you shouldn't be writing or reading to any UI elements, or using any property nodes in parallel with a timing test. Also it is generally a good idea to turn off Automatic Error handling, and Debugging because these can affect time measurements. That being said I don't think this changes your results much if any.

Well I found this help on the property. http://zone.ni.com/reference/en-XX/help/371361J-01/lvprop/lvclasslibrary_wire_pens/ I was thinking this was as simple as you forgetting to read the help but the help in this case isn't very...helpful.

Answering this seems far too dangerous. EDIT: Alright fine, just know breaking a NDA with NI is a very bad thing. Beta sign up.

A new technology developed by NI that has never been mentioned before? How many levels of management at NI did your post have to go through?

I remember a beta of one of the versions of LabVIEW had a bug where this wasn't true. A 5D array was bigger, and a 6D array was bigger with no limit. It was interesting to make a build array be huge and see the massive wire output like what you have here.

I almost believed you for a bit because FPGA code does do some weird things. I don't know if this is the case still or not, but at one point there were express VIs that you could open the block diagram of. If you kept drilling down into the VI you eventually found a subVI with no G code, only a single comment on the block diagram, and no objects on the front panel. The comment was a string of characters referencing the already compiled VHDL code to insert. I'm guessing the code just couldn't be easily represented in LabVIEW and NI just inserted some already compiled code to do the work. As for the XNode, add a breakpoint to one of the subVIs you think is drawing the icon, and save it. If that code does draw the node it should call it and break. Now why it gets called is a different question.

Well using the command line is the way to go, but I've never done it, I've just used tools that do it. Here is a quick link where you can get the revision with the command line. http://forums.ni.com/t5/LabVIEW/How-can-I-get-the-SVN-repository-version-in-my-VI/td-p/803586 I have yet to get the command to work for some reason not quite sure what I'm missing.

I mean the file on disk. Here is a document with some fun examples to run that describes it. https://decibel.ni.com/content/docs/DOC-20522 The way the file is written can influence fragmenatation. One way to avoid it is to use the TDMS write function as seldom as possible, where maybe you write all of the data types at once. Say you have 10 channels that are doubles and then 5 that are timestamps, and then 10 that are doubles. If you can force your code to write the 20 channels of doubles using one write function, instead of a write for doubles, then a write for timestamps, then a right for doubles, you will be better off. But even that is better than 10 writes one for each double channel, followed by 5 write one for each timestamp channel, followed by 10 writes one for each double channel. But even that is better than writing each sample for each channel one at a time.

So what you saw (I assume) is fragmentation. And as you said if the data is all in one big block getting the data is pretty quick. But if sections have to be grabbed and concatenated it takes more time. Because of this when I deal with large amounts of TDMS data, I will periodically defrag the file. This helps make the majority of the file one large block of data, with then fragmentation after that one block. This does take time, and during that the file can't really be accessed. I mean it can but I think the resource is locked, or the data you read could be corrupt. Writing the data in a way that performs the flush as seldom as possible will be the key. What this might mean for you is you have a circular buffer in memory, until it gets to a specific size, then flush it to the TDMS file. I like this idea and I've never tried using a TDMS file for this but given the fact that the offset and length can be specified on a read, I think it would work pretty well. All of my circular buffers could be held in memory at once so I never had a need for this type of thing. Post some code if you have an example of what you are thinking.

This is amazing this is fantastic...what is this? I know English isn't your first language but could you please try to elaborate on what a Plugin VI is and how it is useful? Also it crashed my LabVIEW not long after running it so there is that.

I enjoy posts like this. But with a moderator hat on it is difficult. We can't hide behind the fact that we are a forum of "advanced" developers. We are still a very public forum easily found. Searching "LabVIEW Password Crack" in Google results in the first hit being NI's forums, and the second being LAVA (thanks BTW flarn). There are topics we cannot talk about here, but then there are ones like this that are a grey area. I mean where would we be if the Super Secret INI key was never discussed? Would NI not have developed and released scripting as quickly, or at all? I am a man of few words...any questions?

This is pretty neat. One thing I noticed right away is that Auto-Tool has to be on. If you try tabbing through the tools your tab is intercepted by the front panel and your cursor moves from control to control. This also affects things like QuickDrop and the Clean-up shortcuts.

Why would you want to involve LabVIEW in this? I was going to suggest some kind of remote desktop solution, where users can login with their credentials and access the PC one at a time. But even if you were able to have 3 users all logged in at once, and all working at once, the hardware will be locked by one application by one user, and the other users, and other applications won't be able to access it.

They also enable some extra event types in an event structure, that you may use but not know it was private.

Yeah that's what I meant. There is no run-time penalty, because at development time is when the constant is made. Yup this is similar to the Variant Repository I posted. Not sure why that method is private either but I couldn't find a better way to make a constant. Your code does also fall short if there is no data associated with the sink yet. I know you said you didn't test it much so that's fine, but you don't handle if you wire the output to the tunnel of a case structure for example. The data becomes void, and you get an error popup. My implementation looks for error and defaults to a variant data type if one is seen in the process of finding the sink data type.

Thank you but please next time don't upload to some fly by night uploading site. Use this forum that's what it is here for. And the comment still stands that you have a false constant wired to the while loop so there is no hope to releasing the serial port resource. EDIT: That has to be a maintenance nightmare. Way too many locals, too large of a BD, too many property nodes, too many cases, on the bottom center, no event structure for handling the run-time menu. Look into a state machine. And arrays for data instead of 60+ scalars.

Well almost two years later and guess what, I have found how to replicate this functionality, and abuse it to my liking. I just submitted a code repository for a Variant Repository which is basically reading and writing variant attributes with some added functionality. The read function has the ability to look at the data type that the output is wired to, and change the type to that. Doing this was relatively easy using XNodes and the Adapt To Inputs ability. It gets the reference to the output terminal, then gets the reference to the sink location of the wired tied to it, then gets the data type of that terminal. It will default to a Variant if it has issues in this operation. The performance of using this is basically nothing because all it does in my case, is change the type of a constant on the block diagram of my XNode.

Name: Variant Repository Submitter: hooovahh Submitted: 04 Sep 2014 Category: XNodes LabVIEW Version: 2011 License Type: BSD (Most common) Description This package contains functions for reading and writing Variant Repositories. A Variant Repository is a variant which behaves similar to a look up table with key value pairs. Using the Write Variant Repository tags can be written using any data type. Similarly the Read Variant Repository can read back the data. The type of the data can be specified and the output of the read will be of that type. Provide the type as an input, or right click the read and select the data type to read. If the type isn't specified the read function will try to look at the data type upstream from the read and set the type to that. Errors will be generated if the tag doesn't exist, or if it exists but is the wrong data type. Multiple tags can be written or read, by right clicking the read or write function. These multiple read/write functions deal with arrays of data to read or write, and an array of tags to go along with the data. Multi-Level Variant Repositories can also be written or read. This will write a Variant Repository, as a tag to another Variant Repository. Because of this, two levels of keys are needed for reading and writing, the Section, and the Tag. Type selection, and multiple reads or writes behave like the normal read or write Variant Repository functions. When writing values into a Variant Repository there is an optional Write Once input. This is set to false by default, but if a tag is written when this is true then attempting to write this tag again will return an error. Variant Repositories can be saved to a semi-human readable INI file. This data can also be read back from the INI file. XNode Disclaimer The Read, Write, Read Multi Level, and Write Multi Level functions are implemented as XNodes. NI does not provide support XNode development. For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). Dependencies OpenG Comparison Library-4.0.0.3 OpenG Variant Configuration File Library-4.0.0.5 OpenG String Library-4.1.0.12 OpenG LabVIEW Data Library-4.2.0.21 OpenG Error Library-4.2.0.23 OpenG Array Library-4.1.1.14 LAVA Palette-1.0.0.1 Variant Repository-1.0.0.7 Variant_Probe-2.4.1 The attachment is in the form of a Package Configuration and contains the Variant Probe package found here. The reason I included it is because it is the only package that is needed but can't be found on the Package Network. This package is only needed to demonstrate one of the examples and isn't critical to any Variant Repository function. This Has Been Done Before Yup it sure has. Having a look-up table with key value pairs has been done many different ways, from CVTs, the LabVIEW Container, and native Variant Attributes just to name a few. But some of these have really poor performance, while this implementation is meant to be as little over head as possible. But the real benefit is the XNode type adaption, and type prediction. Just write anything, and then read it using the correct type without needing to perform any explicit type conversion. Because the data type is really a variant, no extra functions are needed to get to the data. This can be good or bad. Yes a class could be used to restrict the data, but with a simple implementation I feel like that would get in the way. My opinion may change in the future but for now I love that a normal tool like the Variant Probe can just look at the tree view of a Variant Repository without any extra tools or conversions. Variant Repositories also combine the WORM (Write Once Read Many) paradigm. A write can be set to write once, and then attempting to write again will generate an error. Click here to download this file

More information is needed. What is the units of the HEX time stamp? Is it seconds? Milliseconds? Minutes? Hours? Days? And what is the date of your time? Are you saying that the hex value starts 0 at midnight? and by just after noon you have over 254 million units of time? A pretty quick and dirty way of making this work is to find the difference between the hex input, and the known input you have there, then add or subtract that amount of time from the known time stamp you have there.

No that is pictures, code is in the form of VIs. In any case rolfk is right, you never close the port, because you never close your resource, because you stop your car by crashing it into a tree instead of using the brakes. Use proper coding techniques to exit your program, and perform clean up operations on exit/stop.

That is a picture of a VISA control allowing you to select a COM port for some operation. What is your problem?