-
Posts
399 -
Joined
-
Last visited
-
Days Won
28
Content Type
Profiles
Forums
Downloads
Gallery
Status Updates posted by Sparkette
-
Fun fact: the Type Specialization structure works in generic VI's. Or at least as much as anything can work with generic VI's.
-
Does anyone know what a "docmod" is? (Seen in the help text for a couple private methods, as well as in Heap Peek)
-
https://www.pearson.ch/download/media/9780130153623.pdf
(Page 122) Actually, "monnie pleaser" is the 5-2-2-2-5 connector pane. "super monnie pleaser" is the first of the two shown, and the second is "monnie would be pleased-er".
-
In any application where a GPIB connection error is not fatal, there may as well not even be a warning. :p
-
Wouldn't it be convenient if there was something like a structure you could place, where you could open a window with a temporary block diagram to do some random VI scripting you'll only need once?
-
Combining Project Providers and XNodes? And putting a "/6f*" in the INI file that may very well break it entirely, for nothing more than a novelty MD5 hash? I do believe I'm being quite...
-
There's a couple file name prefixes that trigger special behavior in LabVIEW. There's the ";D" for External Nodes (obsolete predecessor to XNodes that only barely works now) and now the ")" and "))" that cause LabVIEW to treat a typedef like a channel type. Anyone know of any others?
-
I wonder, what's the most dimensions anyone has ever used in an array, that wasn't just made that way for novelty?
-
-
Lol I just noticed I'm the #1 most popular contributor for the week and the month. Not sure how special that really is as this isn't the most active forum, but it's still neat to see. Thanks I guess
-
Does anyone have any idea what DCO stands for? It's in the same context as DDO, which I know means Data Display Object.
-
Not sure. In this context it's part of LabVIEW's internal data structures for front panel/block diagram objects. Often DDO structures are contained within them. But a DCO is often used even when the data doesn't need to be displayed (in which case there's no DDO) such as for parameter terminals, For/While loop terminals, etc.
Data Container Object maybe?
-
I believe, DCO stands for Data Controller Object and DDO should be Data Display Object. You might see DCOs and DDOs already with the help of Heap Peek. I didn't study DDOs much (it's either a control or an indicator), but a DCO controls how and which data is passed through a single terminal (on BD) or control/indicator (on FP). You may find any SubVI's/node's terminal w/ Heap Peek and in its properties you should find an address of DCO assigned to it. The same is doable with controls and indicators on Front Panel. On BD DCOs are called Parameters or EFN Parameters (for CLFNs) or somehow else. On FP they're called FrontPanelDataControllers. It's easy to find them using "F" button of Heap Peek. There are two internal functions in LabVIEW, which read and write from/to a DCO's (Transfer/Execution/Operate) data buffer: ReadDCOTransferData and WriteDCOTransferData. These funcs are used in Get Control Values By Index and Set Control Values By Index behind the scenes. It's even possible to call these funcs from BD directly to mimic the foresaid instruments behaviour.
-
Did you post this before you started working for NI?
Seems kind of funny to see an NI employee asking the community for help with XNodes of all things 😄
-
Started working at NI in 2014 so this was after that. At the time, I was an Applications Engineer and this was a side project so I didn't really want to bother any of our developers.
I ask enough of our R&D team for work problems so I'll bug LAVA or our local user group with problems I've run into from more personal projects.
-
Ah ok. Just thought it was funny
-
-
I FINALLY figured out something I'd been trying to do for a long time. https://lavag.org/topic/19178-low-level-vi-data-editor-warning-not-for-production-use/