03-17-2017 04:06 PM
I'd like to write a value at the address pointed to by a DSNewPClr.
Can that be done with LV2013, Win 7-32?
Thanks,
Solved! Go to Solution.
03-17-2017 04:45 PM
There are some peek and poke primitives buried deep in the Low Level Register Access of the Instrument I/O palette.
03-20-2017 01:56 PM
@MinerHokieRamp wrote:
I'd like to write a value at the address pointed to by a DSNewPClr.
Can that be done with LV2013, Win 7-32?
Use MoveBlock to copy data from a LabVIEW data structure to a pointer, or vice versa. MoveBlock is basically memcpy, it copies bytes from one address to another. In LabVIEW you call it as you would DSNewPClr - configure a Call Library Function Node with the library name set to LabVIEW. MoveBlock is documented in the LabVIEW help. Note that you will need to pass the pointer returned by DSNewPClr by value to MoveBlock, not by pointer - since the value itself is a memory address.
03-21-2017 12:18 PM - edited 03-21-2017 12:23 PM
@nathand wrote:
@MinerHokieRamp wrote:
I'd like to write a value at the address pointed to by a DSNewPClr.
Can that be done with LV2013, Win 7-32?
Use MoveBlock to copy data from a LabVIEW data structure to a pointer, or vice versa. MoveBlock is basically memcpy, it copies bytes from one address to another. In LabVIEW you call it as you would DSNewPClr - configure a Call Library Function Node with the library name set to LabVIEW. MoveBlock is documented in the LabVIEW help. Note that you will need to pass the pointer returned by DSNewPClr by value to MoveBlock, not by pointer - since the value itself is a memory address.
I didn't see an option in DSNewPClr to pass as value. Anyway, I need to use the pointer from DSNewPClr as well as the memory address.
If I connect the pointer to the input address pin of a MoveBlock, I believe the memory address could be 'passed as value' from the destination output pin.
I've used MoveBlock to dereference pointers but I'm not understanding how I could use one to write a value to a memory address. Can you illustrate how to do that or provide a reference?
Thanks,
03-21-2017 01:37 PM
@MinerHokieRamp wrote:
I didn't see an option in DSNewPClr to pass as value. Anyway, I need to use the pointer from DSNewPClr as well as the memory address.
A pointer, by definition, is a memory address. What I meant was that the value you get out of DSNewPClr gets passed to MoveBlock, and that parameter of MoveBlock should be configured to be passed by value.
@MinerHokieRamp wrote:
If I connect the pointer to the input address pin of a MoveBlock, I believe the memory address could be 'passed as value' from the destination output pin.
I've used MoveBlock to dereference pointers but I'm not understanding how I could use one to write a value to a memory address. Can you illustrate how to do that or provide a reference?
Here's an example I posted years ago but is still valid, although I should have changed all the Call Library Function Nodes to run in any thread because the LabVIEW memory manager functions are re-entrant:
In your case you're asking about the first MoveBlock call (the one I labeled, in the context of the original discussion, "your DLL does this").
03-24-2017 10:26 PM
@nathand wrote:
@MinerHokieRamp wrote:
I didn't see an option in DSNewPClr to pass as value. Anyway, I need to use the pointer from DSNewPClr as well as the memory address.
A pointer, by definition, is a memory address. What I meant was that the value you get out of DSNewPClr gets passed to MoveBlock, and that parameter of MoveBlock should be configured to be passed by value.
@MinerHokieRamp wrote:
If I connect the pointer to the input address pin of a MoveBlock, I believe the memory address could be 'passed as value' from the destination output pin.
I've used MoveBlock to dereference pointers but I'm not understanding how I could use one to write a value to a memory address. Can you illustrate how to do that or provide a reference?Here's an example I posted years ago but is still valid, although I should have changed all the Call Library Function Nodes to run in any thread because the LabVIEW memory manager functions are re-entrant:
In your case you're asking about the first MoveBlock call (the one I labeled, in the context of the original discussion, "your DLL does this").
nathand,
Thanks for the code.
I took your snippet, changed the memory block size to 8192 at the input to DSNewPtr, and connected the numeric constant of value 8 to the input of the first MoveBlock. Since the pointer value I need to write to memory is DataType U64, I converted it to two U32 numerics for the array. So, now there's a U64 control input and the 2nd MoveBlock outputs the same U64 value.
Further downstream in my code, a function call requires the pointer as a U16 input (that's the pointer provided by the DSNewPtr in your snippet). This doesn't make much sense; it should be a pointer-sized integer (64 bit).
It's off-topic but below is info on the downstream function if you can offer any advice. I had planned to use the pointer provided by the DSNewPtr in your snippet as the ppCurMsg value. I'm questioning my interpretation of the downstream function and plan to consult with my local C++ programmers again.
PROTOTYPE:
#include “mti.h”
S16BIT _DECL aceMTIDecodeRawMsg(PMTI_CH10_DATA_PKT pCh10Pkt, U16BIT **ppCurMsg, MSGSTRUCT *pDecMsg);
PARAMETERS:
pCh10Pkt (input parameter); Pointer to IRIG 106 Chapter data packets
ppCurMsg (input parameter); Pointer to buffer pointer location of current message to decode within pCh10Pkt, from IRIG 106 Chapter data packets into Legacy message structure
pDecMsg (output parameter); Pointer to MSGSTRUCT to store decoded message
Thanks,
03-27-2017 12:14 PM
I don't fully understand your last message, particularly "a function call requires the pointer as a U16 input (that's the pointer provided by the DSNewPtr in your snippet). This doesn't make much sense; it should be a pointer-sized integer (64 bit)." I see that your downstream function has a parameter of type "U16BIT **ppCurMsg" which, from the documentation, is a pointer to an array of U16.
Because you're dealing with memory addresses on the LabVIEW wires, the function prototype shown in the Call Library Configuration Node will NOT match the function prototype from your header file. In this case, you have a pointer - a memory address - on the wire, and you should configure that parameter as a pointer-sized integer passed by pointer. LabVIEW doesn't know, and doesn't need to know, that following the pointers eventually leads to an array of U16. Getting this right really requires some C programming experience; if you've never programmed with pointers, you'll probably have trouble.
If that's not clear or doesn't help, and you can't get a good answer from your local C programmer, please attach your VI(s) and the entire header file or documentation for the functions you're trying to call. Then I (and others on the forum) can see exactly what you're doing and provide specific suggestions.
03-28-2017 11:06 AM
After I posted the comment, I spoke with a co-worker who is experienced with pointers. He explained that u16 refers to the data being pointed at, not the pointer. Nice to have a confirmation.
Thanks,