Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/17/2014 in all areas

  1. 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.
    1 point
  2. Okay I haven't tried out that private method yet but I plan on it. But I have been successful with the start of this post and have attached a quick example of it. This has no documentation, very little icons, very little functionality, but it demonstrates an init changing the data type, and a read changing the data type of an output, just run Example Data Type Change.vi. The majority of the work was fixed by using the adaptive terminal types as flarn suggested. But there are times that I need to know the data type of the wire, for things like updating the icon to change with the data type change. I accomplished this by making a template VI that I would edit then run with scripting, from the XNode, which would just make a constant on the block diagram, and pull out the type within the queue, and return it. There maybe better ways but it does what I want, where an Init VI makes the data type of the wire change, and then the other functions like dequeue changes the output terminals to match. Circular Buffer XNode Start.zip
    1 point
  3. I know this issue and I sorta struggle with it. There are a few solutions, but all of them involve extra writes. When you write Channel 1, you can write blank data to Channel 2. If this data is a double I recommend writing NaN. Same with when you write Channel 2 you'll need to write NaN to Channel 1. Or you can have an index or time column for each channel. So Index 1 and Channel 1 get written together, and Index 2 and Channel 2 get written together. Or you can take that a step further and have a group for each set of data that comes in a different rates. Lets say you have 5 channels at the same rate and another 2 at a different rate. The first 5 channels can share the same timestamp, and the next 2 can share a different one. In this case it seems like a good idea to have one index per group in the TDMS data. EDIT: The problem you are having is one I have too, which is we are trying to treat TDMS files as a report format. When really it is meant to just store the data. Reports can be generated using this data, but as soon as you try to just use the TDMS as your final report, you will hit formatting limitations like this that can be overcome with extra work.
    1 point
  4. A game: https://github.com/mrhappyasthma/Snake A measurement system: https://github.com/Naviss/Oto A LabVIEW IDE plugin: http://sourceforge.net/p/lv-cct-tool/code/ci/default/tree/ A library: http://sourceforge.net/p/h5labview/code/ci/default/tree/ (I haven't used any of them except h5labview, so I can't give you an assessment on their quality) If you want a good resource on LabVIEW tricks and designs, I recommend The LabVIEW Style Book by Peter A. Blume. He walks you through sample projects, points out their strengths/weaknesses, and provides lots of useful guidelines.
    1 point
×
×
  • Create New...

Important Information

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