Leaderboard

http://zone.ni.com/reference/en-XX/help/371361J-01/glang/unbundle_by_name/ Just search your palette for Unbundle By Name it is a very commonly used function to pull out data from a cluster which is what the frame is returned as.

Using Intrepid hu? Well that Get Messages subVI returns an array of frames. It then goes through each frame one at a time. It does this by using the Auto Index feature of the for loop which pulls each frame one at a time. You can use the unbundle by name and you'll be able to pull out the ID which will be a U32. You can then wire a case structure around the concatenate string function, and wire your ID to the selector terminal. Then when your ID is equal to 0x180 perform the concatenate, and for all other values (Default) don't concatenate. If you are new to LabVIEW check out these free training links. NI Learning Center NI Getting Started -Hardware Basics -LabVEW Basics -DAQ Application Tutorials 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training

If you want to over complicate things sure you can use Classes or Variants. But seriously what is wrong with just ignoring the data that isn't needed for that type of DIO? It is quite easy from a developer perspective to see that you are just ignoring control values if the DIO is an input. Dynamic Dispatch can do this work for you, but with no extra VIs, and a single type def you can have the same functionality. Variants could be used with a convert from one type to the other if it is an input, or output, or PWM output too but there we possible type conversion errors to worry about which might not be that big of a deal depending on how it is written. I'd KISS in this case. If we are talking about any larger of a design, where a channel could also be a counter, with PWM in or out, or an analog with in or out, or output wave etc. Then yeah classes would probably be what I suggest.

I apologize to users of this library. When NI made me rename the library to “SQLite Library†from “SQLite LabVIEWâ€, I inadvertently allowed VIPM to rename the root directory accordingly, so this might cause your minor conflict headaches when opening old projects. Sorry.

It's an excellent point. For example. Trying to log 200 double precision (8 byte) datapoints at 200Hz on a sbRIO to a class 4 flash memory card is probably asking a bit much. The same on a modern PC with an SSD should be a breeze if money is no object. However. We are all constrained by budgets so a 4TB mechanical drive is a better fiscal choice for long term logging just because of the sheer size. The toolkit comes with a benchmark, so you can test it on the hardware. On my laptop SSD it could just about manage to log 500, 8 byte (DBL) datapoints in 5ms (a channel per column, 1 record per write). If that is sustainable on a non-real time platform is debatable and would probably require buffering. 200 datapoints worked out to about 2ms and 100 was under 1ms so it could be a near linear relationship between number of columns (or channels, if you like) and write times. The numbers could be improved by writing more than one record at a time but a single record is the easiest. I have performance graphs of numbers of records verses insert and retrieve times. I think I'll do the same for numbers of columns as I think the max is a couple of thousand.

It's obvious you've never actually developed an XNode, because in my opinion it is easier than making 60+ polymorphic VIs and then having to add them. I don't want to derail the topic but here are a few reasons XNodes could be considered the better solution: XNodes make the instance with scripting so any data type can be used, where with a polymorphic VI you need one for each data type. I've had polymorphic VIs with 60+ VIs and it still didn't meet all the type needs. Most XNodes are only 5-8 VIs and can cover many more cases, with more functionality. Fewer VIs in memory - Polymorphic VIs load all VIs into memory. This means all 60+ where a XNode is just a few. Updating a polymorphic VI is a pain because you have to update all 60+ versions. XNodes have the UpdateType ability which can have revisions like classes and force a mutation to update an older version. XNodes appear to be inlined VIs and run as fast as possible. XNodes when in a built EXE are removed and they are replaced with the VI that is made so it should behave just as a normal VI in a production application. XNodes can react to other input like user interactions that normal VIs can't. Icon updating, and help can be generated based on the specific usage of the XNode. XNodes maybe unreleased and undocumented, but they are not unsupported. NI has many XNodes, and even promote a few like the Math Node. And I don't know how a polymorphic VI would be easier for the end user. My goal is to make life easier for developers and XNodes do that which is why I'm so interested in them. I do think there is a stigma associated with XNodes which maybe why people avoid them, but I saw some amazing things done with scripting in the 7.x era before NI officially supported that as well.