hooovahh

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?

Correct me if I'm wrong but Genericity (is that a word now) makes the VIs on the fly and saves them to temporary file locations on disk. One for each instance needed to support the VI. Essentially making a new polymorphic instance every time one is needed. I have no clue how that would work in a built EXE because scripting isn't in the run-time engine. But now that I think about it when building an EXE it would probably just replace the generic subVI with the instance it created that was being used. If that is the case then again a built EXE using a VI that uses a Generic terminal, should be identical to a EXE built with just a normal subVI. But really I have no idea what the compiler would do, which is probably why NI just advises against using them at all.

Don't get your hopes but, I'm quite certain this functionality does not exist in this toolkit, but I too would love something like that. Our testers don't generally have lots of graphics horse power but if they do, off loading some of that to a GPU seems like a great idea.

Which is quite ironic since generics are most certainly not "Go" and NI has said multiple times that the development of Generics are a dead end for them. I can't remember who I heard this from but I thought I remember even hearing that NI plans on removing Generics from some future version of LabVIEW because they don't think it is a stable technology.

They are a secret that's why you can't use them...but seriously they help with custom control development. They are very incomplete but give some functionality that has been desired by the developers. The interface for getting these much desired features is quite lacking, which is probably why this isn't public yet. It can allow things like defining the behavior of a decal on a button, as the button changes size. By this I mean the decal can move as the button grows, or the decal can stretch. You can also define if the decal (or text) can be resized or moved independent of the control. Very neat stuff but yeah it can behave strangely if you enable some features at the same time which the interface doesn't restrict you from doing.

I went through Ctrl+Shift+D Ctrl+Shift+<another key> for all keys on the keyboard to see what other things come up. I never found the _ debug because I was expecting some kind of popup like the W and H return. EDIT: It looks like the wireframe drawing work on 2011 not sure about older.

Not quite. When the EXE is made there is no XNode, and there is no private method being used. The private method is only being used during edit time. If you interact with the XNode described it will call the private method, but once it has ran, that private method won't be found in your source. So it is a grey area for sure. The production code doesn't contain any private methods, but a tool used to generate a portion of the production code does.

I still couldn't get that to work, but I understand what you were trying to do. This ladies and gentlemen is another reason why code review does not replace unit test.

What limitations are you referring to? And how did you get around them? I have only used these devices (and the Arduino SPI) on very simple slow devices for getting voltage readings, so maybe my application didn't see the limit you did.

That is fascinating. So that explains this thread on glyphs in multiple columns. http://lavag.org/topic/7002-multiple-glyphs-columns/ I haven't played with it yet but some of these settings sound very useful. If you don't mind me asking how did you find this INI key? EDIT: BTW has anyone just tried SuperSecret<insert function or control>Stuff=True for every function imaginable? Or EnableSecret<insert function or control>=True Double Edit: Looks like this works on 2013 and newer.

Notice I didn't say to use regular expressions, I just said that it could be used.

Maybe you should it sounds like it would meet your needs. If you are unsure what the function can do open the context help.

So you want to print the source code to your application correct? Did you try File >> Print? Or File >> Print Window? If so what was wrong with doing that? You can also do it programatically using the Report Generation >> Easy Print VI Panel or Documentation

Yup that's what I said.

Many ways. How about getting the string subset on the first four characters and seeing if they equal SDFS or ASXP then getting the string subset of there for the appropriate length and offset for each. I'm sure regular expression could do it too. Post your VI you have tried and show what you couldn't get to work.

Wow I always wondered if I could use a series of DIO lines to make a SPI device. You haven't confirmed the fact that you can or can't yet but it is interesting. What is wrong with using a cheap USB to SPI device? NI does sell their USB-8451 which is a SPI device and works quite well. Of course a much cheaper option would be an Arduino Uno and the LIFA Toolkit which has a palette for doing SPI or I2C. I've used both of these for SPI communication and never had a problem.

Support, documentation, and examples are a few things I know you get without ever having used it. If I were experienced with CUDA (which is sounds like you are) you might not see enough value in it. Download a trial and try it out, and if you do please report back your honest opinion of the toolkit for others to see, I get the feeling few have ever used it.

FYI Crosspost