LabVIEW
Funny type mismatch. Bug?
- last edited on by
Content Cleaner
I'm sure there is a very good explanation for this, but why the order in which I connect "things" to a build array primitive would make it have or not have a broken wire?
You read well!
Drop a build array primitive
Enlarge it so it has 3 inputs
connect A to the first input
connect B to the second input
connect C to the third input
It works...
It should work as long the data type of A, B and C have a common ancestor, right?
Well now remove all the wires
connect C to the first input
connect A to the second input
connect B to the third input
there is a broken wire for B
A, B and C haven't changed.
The bad news is that if you want to see this you have to buy and install NI's DNP3 module
@Ben a écrit :
Take care Cup Bearer!
Mug Bearer 
@Ben a écrit :
Try wiring the output of the build array to a seq frame or something.
Turn on the help window and switch to the wiring tool.
Float over the array wire and check the help window for a clue about what the wire type is in each of those situations.
Ben
When there is no broken wire, type is DNP3 Channel, the generic one.
For all I do I have a work-around for this issue.
With this type of ref there is some class inheritance somewhere but we don't have primitives to cast to more specific or to more generic like we do with VIServer refs.
Maybe it's an issue in the way DNP3 channel refs where implemented and maybe it's a more generic issue in the way LabVIEW handles inheritance with thy ref type.
Maybe this should be reported to R&D, not for me to say.
The DNP3 toolkit library most likely makes use of the internal LabVIEW object manager interface. This predates LabVIEW object oriented support by several versions despite its name and is based on the same infrastructure that is used to implement VISA communication. It allows specification of an object oriented interface with class inheritence and property and method implementations defined in a resource text file that gets parsed on LabVIEW startup and then defines the connection to a shared library based implementation.
The access on the LabVIEW diagram is through the well known property and method nodes which are then translated by the object manager based on the resource file specification into the according calls into the shared library. Each refnum has therefore a class specification that can refer to one class and each of these refnum classes can be in a hierarchical inheritance as defined in the resource file.
The Build Array node uses the datatype of the first terminal to determine the datatype of the output array. If you connect a more specific refnum to this terminal than any of the others, you get a conflict as LabVIEW can not guarantee that the more generic refnum later in the Build Array stack can be automatically casted to the more specific one (it could be after all a different child from the more generic refnum, or only the generic refnum itself). If you use a refnum that is more generic or equal to any of the following refnums LabVIEW will automatically downcast the remaining more specific refnums to the more generic one defined in the first terminal as that is a safe cast that always succeeds.
The only fix the LabVIEW developers could do in here is to make the Build Array node smarter in trying to determine the output datatype based on the most generic input of any of the element inputs but I suppose that has been already discussed by several LabVEW developer meetings and there are some involved consideration that make this a difficult if not impossible thing to implement.
Are you sure the to More Generic Cast function won't work on these refnums? It most likely should as almost all the LabVIEW refnums use internally the mentioned object manager in one way or the other.
I'm always impressed by the depth of your knowledge when it comes to how LabVIEW works in deep.
Thanks for taking the time to explain all this.
@rolfk a écrit :
Are you sure the to More Generic Cast function won't work on these refnums? It most likely should as almost all the LabVIEW refnums use internally the mentioned object manager in one way or the other.
Yes, I've tried to more specific and to more generic but both of them won't accept any DNP3 Channel ref (any of the 3 types) even connected to the target class input it creates a broken wire.
@rolfk a écrit :
The Build Array node uses the datatype of the first terminal to determine the datatype of the output array. If you connect a more specific refnum to this terminal than any of the others, you get a conflict as LabVIEW can not guarantee that the more generic refnum later in the Build Array stack can be automatically casted to the more specific one (it could be after all a different child from the more generic refnum, or only the generic refnum itself). If you use a refnum that is more generic or equal to any of the following refnums LabVIEW will automatically downcast the remaining more specific refnums to the more generic one defined in the first terminal as that is a safe cast that always succeeds.
I thought it would be the case but either I misunderstand what you said or it's not the case anymore with LabVIEW 2018, because the buikd array is smart enough to automatically cast to more generic the correct inputs whatever the order :
And in the case of DNP3 Channel refs, it is when the most generic type is connected to the first input that there is a broken wire for one of the more specific type.
And when the most generic is at the end it works... maybe this is specific to how the DNP3 resource file was made.
@TiTou wrote:
I'm always impressed by the depth of your knowledge when it comes to how LabVIEW works in deep.
Thanks for taking the time to explain all this.
@rolfk a écrit :
Are you sure the to More Generic Cast function won't work on these refnums? It most likely should as almost all the LabVIEW refnums use internally the mentioned object manager in one way or the other.
Yes, I've tried to more specific and to more generic but both of them won't accept any DNP3 Channel ref (any of the 3 types) even connected to the target class input it creates a broken wire.
@rolfk a écrit :
The Build Array node uses the datatype of the first terminal to determine the datatype of the output array. If you connect a more specific refnum to this terminal than any of the others, you get a conflict as LabVIEW can not guarantee that the more generic refnum later in the Build Array stack can be automatically casted to the more specific one (it could be after all a different child from the more generic refnum, or only the generic refnum itself). If you use a refnum that is more generic or equal to any of the following refnums LabVIEW will automatically downcast the remaining more specific refnums to the more generic one defined in the first terminal as that is a safe cast that always succeeds.
I thought it would be the case but either I misunderstand what you said or it's not the case anymore with LabVIEW 2018, because the buikd array is smart enough to automatically cast to more generic the correct inputs whatever the order :
And in the case of DNP3 Channel refs, it is when the most generic type is connected to the first input that there is a broken wire for one of the more specific type.
And when the most generic is at the end it works... maybe this is specific to how the DNP3 resource file was made.
Re: This seems to work
Type casting can be dangerous, particularly when we are shooting casting in the dark. Since LV does not actually "do anything" with a wire until it is acted on, there can be trouble that only shows up after the ref has bubbled down a line through a queue triggers an event and Bango! crash.
But being a second-gen wireworker, you know that.
Ben
What Ben means is that a cast can cast anything into a string, or numeric for refnums for instance and then that string or numeric is just a blob of something. And then you can go and cast it somewhere back into something entirely different and LabVIEW has no way of veryfying if that is legal as it has no information from that blob about what it originally was.
When you then try to access that recasted object/refnum VERY BAD things can happen, and a full crash isn't necessarily the worst of them! Use like this where you can guarantee that the resulting refnum is always more generic but from the same inheritance line are safe but there is no LabVIEW type checker preventing you from casting your DNP3 refnum into an entirely different refnum, and then crashing it will!
And even making sure that you only cast into compatible more generic refnums may not prevent some uncareful quick fix changing that later on and creating an illegal cast situation, without any compile time check hinting at you that that might have happened.
The to more generic doesn't accept DNP3 channel ref.
The type cast can run me into things worse than a full crash.
What I'd like to do in my App is to open the DNP3 channel - wether it is Serial or IP - in a case strutcure and output a generic DNP3 channel ref.
Is the build array with a generic ref and then index array the best alternative?
