Here’s a dedicated thread for the “LabVIEW Binding 3.0 preview”. This is the right place to post your feedback, comments or problems related to the upcoming release.
Hi, I have a problem with commands without arg-out but with arg-in (for example DevDouble/DevVoid). Which VI I should use?
Hi,
As explained in the Quick Start Guide, you need to acknowledge the client request - i.e. you have to tell the client that the command has been successfully executed (or failed). There’s a dedicated Vi called _DServerRequestAcknowledgement.vi. See the “Replying to a command execution request” paragraph for an example.
BTW, writing an attribute requires the same acknowledgement mechanism. The _DServerRequestAcknowledgement Vi is also be used in this case.
Finally, the _DServerRequestAcknowledgement has input connector panes providing a way to throw an exception in case of error (e.g. invalid input parameter, value out of range, …). The Quick Start Guide gives an example of such a case.
Thanks for your reply.
This is clear to me.
If I have DevDouble/DevVoid function I have to use _DServerGetCommandArgin.vi to read ArgIn and _DServerRequestAcknowledgement to send the ack,for example:
is it right? , but I have this error:
“LabVIEW device error:failed to execute command ‘funct1’ [data conversion fialed- unexpected null pointer to data buffer]”
Congrats, you found the first bug of this preview 
Its main consequence is to impose to have the same data type for both argin and argout.
It’s fixed now but I will not be able to regenerate the package till I’m back (on August 8th).
Right.
For a more robust implementation, I would simply suggest to check the argin value before acknowledging the request.
Let me guess: This is a dataflow issue?
The problem with that is that dataflow doesn’t really define which of the two subvis is executed first.
So what you might be able to do is use a sequence structure. Not guaranteeing it works, but more robust anyway.
This immediately identifies you as a non-LabVIEW-programmer
The standard way we do that in LabVIEW is daisy-chaining. That means, we give subvis a specific connector pattern with mandatory error structure and use the error structure to enforce dataflow.
(@Nicolas: I have actually added this error structure to all vis.. but in RC2. Mandatory for the official tools network by NI but maybe not backwards compatible for you. Email in August )
[quote=“b.ploetzeneder”]Let me guess: This is a dataflow issue?
The problem with that is that dataflow doesn’t really define which of the two subvis is executed first.
So what you might be able to do is use a sequence structure. Not guaranteeing it works, but more robust anyway.
[/quote]
This is obvious 
. I tried it with flat sequence.
The figure in attachment was only to explain.
OK, good to know - but still a thing we have to address.
Hey Birgit,
The problem reported by Salvo is actually related to a good old bug in the C++ part of the binding (fixed in my local repo).
However, you’re right, the data flow is clearly a concern. I even didn’t think about it -_- Acknowledging the request before extracting the argin data could lead to dramatic situations - like attempting to access a destroyed request. The same applies to attribute value when we try to write it. We have to talk about this daisy-chaining stuff.
Greetings from Corsica 
Here’s a fix for the bug reported by Salvo.
BTW, concerning the data flow issue, the worse case should -
(hopefully) lead to an error (i.e. no such request) and not a crash.
The potential issue related to the “VIs execution order” was limited to Tango commands execution.
Here is a fix that should solve the problem.