there is a feature request to automatically create the type descriptor within the "data 2 byte array" routine of the CoreLib library. The "data 2 byte array" routine is used when packing data for sending commands. When sending a command, one has the option to send the descriptor string of the data as well - however, that is typically not required and only used in special cases. In such a special case, it would of course be very useful, if the "data 2 byte array" routine could already construct the descriptor string. When using many "data 2 byte array" VIs after each other, the "descriptor string out" could be wired to a "descriptor string in" of the next VI.
The question is, if this would be a nice feature or not:
pros:
- there is no need to enter the descriptor string by hand (= one can save a lot of time)
- the descriptor string is always consistent with the data (= no possibility to make mistakes)
cons:
- when inspecting the code during later debugging, one does not "see" the descriptor string in the block diagram
- consequence: when the developer of class A changes the data type accidentally, debugging will become difficult:
1) assume object AA of class A on node AAA sends a command to object BB of class B on node BBB
2) object BB on node BBB will show an error
3) even if the maintainer of a control system will be clever enough to check class B on node BBB for errors, the consitency is not obvious
- the problem becomes even worse, if one uses the "automatic type selection" of the "data 2 byte array". In such a case, the type of data which is sent by objects of class A changes implicitely. I think this will be very hard to debug. A solution here would be to disable the "automatic type selection" in the "data 2 byte array" routine. (However, this would probably require to change all classes that are using the option "automatic type selection".
What do you think?
Regards,
Dietrich Beck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as discussed by Holger, Dietrich and me, the possibility of an optional control/indicator for the "descriptor string in/out" would be a compromise.
[quote]
- consequence: when the developer of class A changes the data type accidentally, debugging will become difficult:
...
[/quote]
hmm, i think this problem also already exists. If a developer changes data type on an accident ( maybe by using "automatic type selection" ), he will surely not change the type descriptor of that data ( When it is really an accident ). So the debugging will be as difficult as with the "descriptor string in/out". Moreover BB will recive a wrong descriptor on that scenario.
sry for reacting so lately, I had to think about the scenario first =)
Greetings,
Alexander Schwinn
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
no! Up to know, the developer is forced to write the descriptor as text string. By this, the data type is documented and one has the chance to debug the code in case of accidental "automatic type selection".
Please remember, that it would be very easy to have the type descriptor generated by the "data 2 byte array", but very difficult to do an "automatic unpacking" at the receiver of an event. I am afraid, that automated generation of a type descriptor would finally result in more work than it would save.
Regards,
Dietrich Beck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- When using simple data types I would prefer the hard coded explicit descriptor.
- When dealing with complex cluster datatypes I would prefer the implicit method. But It is alsway possible to proved subVIs for the data conversion to/from byte array. So, such a subVI could provide a hard coded descriptor as output paramter that could be used to concanate the final descriptor string.
- The conversion to the new proposed connector pane, especially the missing automatic data type selection, will probably cause soem work for existing claases.
Conclusion:
- The majority of the current responsible developer have finally to decide.
- In my opinion we should not change the current implementation.
Regards Holger
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
analyzing the result of the lively discussion, we can draw the following conclusions
- 1 vote pro automatic creation of data types
- 2 votes contra automaitc creation of data types
However, once change will be introduced: The automatic type selection of the polymorphic VIs "data 2 byte array" and "byte array 2 data" will be disabled in the next version.
We have decided on the subject and this discussion is closed.
Best regards,
Dietrich Beck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
there is a feature request to automatically create the type descriptor within the "data 2 byte array" routine of the CoreLib library. The "data 2 byte array" routine is used when packing data for sending commands. When sending a command, one has the option to send the descriptor string of the data as well - however, that is typically not required and only used in special cases. In such a special case, it would of course be very useful, if the "data 2 byte array" routine could already construct the descriptor string. When using many "data 2 byte array" VIs after each other, the "descriptor string out" could be wired to a "descriptor string in" of the next VI.
The question is, if this would be a nice feature or not:
pros:
- there is no need to enter the descriptor string by hand (= one can save a lot of time)
- the descriptor string is always consistent with the data (= no possibility to make mistakes)
cons:
- when inspecting the code during later debugging, one does not "see" the descriptor string in the block diagram
- consequence: when the developer of class A changes the data type accidentally, debugging will become difficult:
1) assume object AA of class A on node AAA sends a command to object BB of class B on node BBB
2) object BB on node BBB will show an error
3) even if the maintainer of a control system will be clever enough to check class B on node BBB for errors, the consitency is not obvious
- the problem becomes even worse, if one uses the "automatic type selection" of the "data 2 byte array". In such a case, the type of data which is sent by objects of class A changes implicitely. I think this will be very hard to debug. A solution here would be to disable the "automatic type selection" in the "data 2 byte array" routine. (However, this would probably require to change all classes that are using the option "automatic type selection".
What do you think?
Regards,
Dietrich Beck
Hello,
o.k., lets have May 24 a deadline for the discussion and a conclusion.
Dietrich Beck
as discussed by Holger, Dietrich and me, the possibility of an optional control/indicator for the "descriptor string in/out" would be a compromise.
[quote]
- consequence: when the developer of class A changes the data type accidentally, debugging will become difficult:
...
[/quote]
hmm, i think this problem also already exists. If a developer changes data type on an accident ( maybe by using "automatic type selection" ), he will surely not change the type descriptor of that data ( When it is really an accident ). So the debugging will be as difficult as with the "descriptor string in/out". Moreover BB will recive a wrong descriptor on that scenario.
sry for reacting so lately, I had to think about the scenario first =)
Greetings,
Alexander Schwinn
Hello,
no! Up to know, the developer is forced to write the descriptor as text string. By this, the data type is documented and one has the chance to debug the code in case of accidental "automatic type selection".
Please remember, that it would be very easy to have the type descriptor generated by the "data 2 byte array", but very difficult to do an "automatic unpacking" at the receiver of an event. I am afraid, that automated generation of a type descriptor would finally result in more work than it would save.
Regards,
Dietrich Beck
I agree with the pros and cons.
- When using simple data types I would prefer the hard coded explicit descriptor.
- When dealing with complex cluster datatypes I would prefer the implicit method. But It is alsway possible to proved subVIs for the data conversion to/from byte array. So, such a subVI could provide a hard coded descriptor as output paramter that could be used to concanate the final descriptor string.
- The conversion to the new proposed connector pane, especially the missing automatic data type selection, will probably cause soem work for existing claases.
Conclusion:
- The majority of the current responsible developer have finally to decide.
- In my opinion we should not change the current implementation.
Regards Holger
Hello,
analyzing the result of the lively discussion, we can draw the following conclusions
- 1 vote pro automatic creation of data types
- 2 votes contra automaitc creation of data types
However, once change will be introduced: The automatic type selection of the polymorphic VIs "data 2 byte array" and "byte array 2 data" will be disabled in the next version.
We have decided on the subject and this discussion is closed.
Best regards,
Dietrich Beck