dadreamer

Yeah, I'm aware of it and seen such behaviour during my experiments. In this case ArrayMemInfo node should be called again on a "new" wire to retrieve fresh data pointer. Or ArrayMemInfo might be replaced by those SPrintf nodes to obtain the pointer to array's handle instead. That pointer is also stable while VI is executing and the wire exists, and it's updated by LV with new array's handle, when the array is resized or whatever. Nevertheless I strongly doubt that someone would use all those codes for something except "funny" time wasting in LV, even for simple data display, that's why I did not describe absolutely all the nuances. There are many articles on the subject, e.g. "Using External Code in LabVIEW", so I assume, the experimenter understands the deal. Agree, it looks a little odd, but I didn't want to introduce additional conditional checks, but in the same time I'd like to show how simple operations like read, write and resize of the array work together. They are combined into one Event frame and do their job there. For that I especially studied the source code of NumericArrayResize and made sure, that when the input array's dimSize and the requested new size totalNewSize do match, then NumericArrayResize does nothing and returns. So, no need to check that in LV as it's already checked internally. As for that twin SPrintf formatting, I didn't find a reliable way in pure LV to pull out the pointer except this one. Maths in extcode.h aren't adapted for 64-bit integers, so I cannot use Max, Abs or something in 64-bit IDE. There exists a trick with _byteswap_uint64 function from msvcr100.dll, but I feel it's not okay to tie to this specific MSVCR version and some additional operations are needed to restore the pointer's byte order back to normal. Anyway, it's all a "proof-of-concept" thing, so may be changed/played around as desired. Which parameter do you mean exactly? int32_t ReadDCOTransferData(uintptr_t viDS, int32_t dcoIdx, uintptr_t *data, int32_t dType, uintptr_t unused, uintptr_t unused); int32_t WriteDCOTransferData(uintptr_t viDS, int32_t dcoIdx, uintptr_t *data, int32_t dType, uintptr_t unused, uintptr_t unused, int32_t unused); If you mean data parameter, it is passed as Pointer to Value, because it's a buffer, which the read/write operations are performed on. If you mean dType, it's integer, because it sets the DCO type in VI Data Space (possible values are 0, 1 and 2 as per my BD). I checked all the arguments many times, they seem to fit fine. Last 2 or 3 parameters aren't actually used in the functions, but passed anyways. Maybe it's some relict of earlier LV versions, I did not have a chance to test yet. Also I tried to reproduce the similar pointer reception on CINs according to this excerpt: But LV makes a copy for the input data, no matter how hard I try. Did it work as described at all?

Long time didn't see those hackish threads about LV internals on LAVA, so here's something. As always it's strictly experimental and "just for fun", so don't run the things below on your work systems, otherwise you'll easily get LV crashed, your files deleted and your disk reformatted. You're warned. As some of you maybe know, starting from LV 2017 there exists hidden ArrayMemInfo node, available w/ the scripting. It provides some info on the input array including its data pointer. ArrayMemInfo.vi My first discovery was that this pointer is stable and doesn't change until VI is stopped. So its common use case could be the memory copy operations for some third-party DLLs. It's obvious and it's kinda boring usage. Playing with it after some time I discovered that I'm able to not only read but also write to that pointer, able to get its handle, resize the array etc. - read on to see the examples. I could conclude that this way it's possible to manipulate Transfer Buffer or DCO's Transfer Data or whatever it's called. From now on I started to question myself, where does ArrayMemInfo node take that pointer from and could we do the same without this instrument. And here was another big surprise for me - yes, we can! LV familiar CLFNs easily do that, when you configure the input parameter as: Type = Adapt to Type Constant = Yes (checked) Data format = Pointers to Handles Actually you could set Type to Array and set Data type and Array format to the actual data type of your array, it's not that important. What is important, Constant checkbox should be checked. In this case LV not only passes the native data types, but also does not create the input data copy, providing the pointer/handle to the Transfer Buffer's data instead! I was very surprised, because it was there from LV 2009, but I didn't pay attention to it. I also did not find it to be described somewhere in the official documents. Knowing that I have replaced ArrayMemInfo with CLFNs in my basic samples. Here's how we could do read/write of a common numeric indicator: numeric_test.vi And this is the same for a common numeric array: array_test.vi As you can see, there's a major disadvantage of the whole technique - one should pass the wire to the indicator in a loop to get the indicator updated in time. Nevertheless there exists a pair of VIs, that do the similar and do not require any wires to be connected to a control/indicator. I'm saying about Get Control Values by Index and Set Control Values by Index, first introduced in LV 2013. So I dug these VIs deeper and came to these two internal functions, which are used by the foresaid VIs and ArrayMemInfo behind the scenes. ReadDCOTransferData: ReadDCOTransferData.vi WriteDCOTransferData: WriteDCOTransferData.vi As their top-level wrappers, these functions don't require any wires and care about low-level operations, i.e. no need to resize the array w/ NumericArrayResize, manually set its dimensions and actual data w/ MoveBlock etc. Although you don't get absolute control over a control or indicator (e.g., its pointer or handle), you definitely don't need it as all the work is done by ReadDCOTransferData/WriteDCOTransferData. Finally we came to the conclusion that the best has already been implemented. But... if you really want... there's a way to get Operate Data pointer for a generic control/indicator. numeric_test_ncg.vi array_test_ncg.vi However I'd like to notice, that this technique contains a lot of pitfalls besides shown low-level manipulations. Front Panel object doesn't get updated at all, for example, so it's required to redraw it manually w/ Invalidate method (or click on the object or hide-show the window). Local variables of the object don't get updated too, even when the object is invalidated. I'm sure, there are other things not done, which usually LV does on normal read/write. So, these diagrams should be perceived as the concept only. In the end I'd say that I hardly imagine, where I could really use any of these non-standard r/w methods. Surely in LV I will continue to use native Get Control Values by Index and Set Control Values by Index VIs, because they do everything, what I want. There might be one use-case though, when communicating with some external code. It would be easier to write debug (or any other) data from a custom DLL into LV's indicator directly, not using PostLVUserEvent or DbgPrintf. Extcode.h doesn't expose many APIs to the user, so calling ReadDCOTransferData/WriteDCOTransferData might be preferred inside the library. But I'm not going to check/test it now, because I haven't written DLLs for LabVIEW for a while.