LabVIEW Binding 3.0 preview: please report feedback & problems here

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.

Edited 7 years ago
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.
Edited 7 years ago
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]"
Edited 7 years ago
Congrats, you found the first bug of this preview smile
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).



If I have DevDouble/DevVoid function I have to use _DServerGetCommandArgin.vi to read ArgIn and _DServerRequestAcknowledgement to send the ack is it right?

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 smile

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 :) )
Edited 7 years ago
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.

This is obvious smile . I tried it with flat sequence.
The figure in attachment was only to explain.
Edited 7 years ago
OK, good to know - but still a thing we have to address. :)
Hey Birgit,

Let me guess: This is a dataflow issue?

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 smile 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 smile
Edited 7 years ago
 
Register or login to create to post a reply.