Built-in DVR Call Wrapper

[_carl]

DVRs are extremely powerful, yet tedious to work with. Much of the coding is just a matter of following the exact same pattern over and over again, while making the code uglier. And I have yet to come up with a good way to reduce that coding overhead...

What if there was a built-in DVR call wrapper that allowed direct access to VIs?

The UI experience could be a hybrid of the Static VI Reference and Call by Reference functions: drop the "DVR Call Wrapper" on the block diagram, drag your VI into it, then wire it up directly.

It could have options for write and read-only.  And it could have right-click options for changing default error behavior.

My standard use case would be class calls specifically, but I don't see a reason this couldn't be applied to any data type -- although some serious thought would have to go into expected behavior in terms of which terminal to treat as the DVR (although this could be dynamic based on which terminal a DVR is wired into, or maybe even settable on the wrapper).

A tool like this would likely save me countless hours of development time, and make it less likely that I'd make coding mistakes while writing routine code.

[wiebe@CARYA]

Duplicate:

Allow Class methods to accept DVRs - NI Community

Which is duplicate of:

Have Dynamic Dispatching terminals accept Data Value references of the class or any child class. - N...

[_carl]

Thanks for adding the duplicates -- I've added my votes there. I didn't find those when I searched originally, but I had a suspicion this request had already been made.

It also bothered me that my original screenshot was actually a lazier approach then what I'd really like to have done under the hood in any DVR wrapper.  But...it's such a burden to actually do it this way, that I rarely actually implement DVR code like I'd really want it to be written. Here's what I'd really want to see:

[wiebe@CARYA]

>Thanks for adding the duplicates -- I've added my votes there. I didn't find those when I searched originally, but I had a suspicion this request had already been made.

No worries, finding ideas is hard. I got lucky.

[fefepeto_kb]

@_carl, I think your second snippet is the textbook example of why error handling should not be handled by an automated script that generates the code. On top of that, I also think the error handling is overdone in your example, which wastes performance. And these are the main reasons I don't like code that is automatically handled by the environment or the runtime engine. Full disclosure, I do use property nodes, that have a similar pattern of error handling, but I would not like my instrument handling methods to be always skipped on error.

Let me explain what we see in the second screenshot:

If no error:

   try to derefence the pointer

     if pointer valid

        return the class in the pointer

     else

        return an error

   merge errors

   if no error

     call Instrument:Close method

   try

     update the value in the pointer

     if pointer valid

       dereference the pointer

       update the value in memory

     else

       do nothing

Assuming that your code is designed to be in a working environment, in >90% of cases there will be no incoming error, and the pointer will be valid. In all these cases the error checks are unnecessary and the processor is wasting time executing them. In the rest of the cases the gain is marginal, unless you are actually doing something based on the returned error codes. But, especially for instrument close methods, the best practice is, to always execute the driver method. If this is a LAN based connection and the error is not a timeout, then it is likely a session closed from the side of the instrument, therefore it should make sense to close the connection on the host side as well. If this is a timeout, then the error might need to be handled in entirely different level. If this is a VISA session, the same applies. If this is a USB instrument then I would explicitly want to call the close on incoming error, most of the cases to bring the device to a known state and be able to reinitialize from scratch.

All these need the error handling to either be in the lowest level method, or to force the execution regardless of incoming errors. I understand, that executing the method if the class' pointer was invalid makes no sense, but if the error handling is in the lowest level, that would allow handling all the error cases in a single place, which arguably can make the code more readable.

I changed the color of the error handling that is 99% of cases unnecessary to red and the ones that might be useful when error handling happens separately to brown.

But my question stands: how can the dev or runtime environment know, that I want it to apply the default error handling or not? If I want to add a more sophisticated, error code based approach, then how can I insert my code to deal with all the expected errors?

[_carl]

@fefepeto_kb, thought I'd respond to a few of your points:

• I'm not proposing that this be an automated script, but instead a built-in optional mechanism, not a replacement. As such I'd expect that the inefficiency would be minimal for the extra error checking and you wouldn't have to use this in applications where you were concerned about this. I, for one, would take very-slight runtime inefficiency in exchange for more-maintainable, reliable, and simpler code almost any day (the exception being applications where every clock cycle matters...).
• I proposed having a right-click menu option for changing error behavior. This could include an option for not doing any error handling. Although I'd expect default behavior to be "Do nothing on upstream error. Do nothing and output error on DVR error".
• This is not a replacement for the standard in-place DVR behavior that you could always use for custom error handling, doing multiple things with a DVR at once, etc.

[fefepeto_kb]

@carl_ Sorry, I might have used incorrect terms, I'm concerned about any automated code generation, weather it is in the compiler or in a dev environment using scripting. The other problem is, if we say the class methods shall handle the by reference classes in the same way as they are handling the by wire classes, then there would be a lot of inconsistency in the code. Additionally, the already lengthy style guides would get worse. To me, this would trade one inconvenience for another, even if there is a context menu option.

And, about the error handling, I agree 1 error handling case in one VI is not a big deal. My problem is that this code gets inserted around each and every class method. In production lines where the batches are of 100 000s, microseconds matter, and using an overly aggressive error handling with the only benefit of making the error cases faster is not worth it. I just see this as a bad practice that is not really present in other languages. In C#, for example you can implement try-catch where you would like to do something about the exception that is being thrown, but in general these structures are applied only where there are issues that are expected during normal runs and can be healed.

On top of that the only way to do some sort of error handling is, to handle the reference myself instead of the automatic mechanism, which would result in an inconsistent code (I mean in one method it is handled automatically and in the next I make sure to handle it, which already results in two methods for the same functionality, one might chose to not create a VI out of it, but that does not change the fact that it shall be a separate VI). Or LabVIEW has to create an API that would allow us handling the errors, but that would result in an ugly and complicated API and I'm not sure weather the benefit would/could be justified.

I also read trough on the linked ideas and their comments after I made my comment here, and I think I agree with AQ. If we want by reference classes then we shall create them in a way that results in a clean user experience and clean code. Automating the error handling and hiding away the fact that the classes are by reference can not achieve this.

[Christina_R]

Have Dynamic Dispatching terminals accept Data Value references of the class or any child class. - N...