LabVIEW Binding 3.0 preview: please report feedback & problems here

# 8 years ago
nleclercq	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 8 years ago

# 8 years ago
Salvo	Hi, I have a problem with commands without arg-out but with arg-in (for example DevDouble/DevVoid). Which VI I should use?

# 8 years ago
nleclercq	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 8 years ago

# 8 years ago

nleclercq

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 8 years ago

# 8 years ago
Salvo	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 8 years ago Attachments:

# 8 years ago
nleclercq	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).

# 8 years ago
nleclercq	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.

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

# 8 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 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 8 years ago

# 8 years ago
Salvo	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 . I tried it with flat sequence. The figure in attachment was only to explain. Edited 8 years ago

# 8 years ago
b.ploetzeneder	OK, good to know - but still a thing we have to address. :)

# 8 years ago
nleclercq	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 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 Edited 8 years ago

# 8 years ago

nleclercq

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 8 years ago