09-10-2014 10:39 AM
Hello,
I'm not an expert in LabView since I come from the
embedded world (C/C++) yet I found something
quite strange when reading from a database.
Here's attached some screen captures of the
database content and structure, then the LabView
diagram with the probe output (yeah, had to stretch
it wide because there is no word wrap option).
Finally there is a little Excel snapshot of the result.
The database reading is performed with a certain
column ordering, the "casting" cluster do mirror
the same order and datatype, yet 'Variant to Data'
scramble things.
And even though I do use dis/assemble cluster
by name to avoid confusion, the resulting cluster
at probe 20 is right. Go figure...
Could someone help and explain what's going
on under the hood ? At least with C/C++ you have
a little grasp on how memory is ordered, but
LabView really bogs me...
David
09-10-2014 10:43 AM
And the remaining two snapshots...
David
PS : update the LabView's UI to something more up to date, avoid the windows-on-top, avoid messing the task bar with dozens of buttons, share to place and use your own tab bar, do something for the probe and breakpoint windows, etc...
09-10-2014 10:49 AM
I am not really sure what you are asking, but the ordering of elements in a cluster is defined by the cluster order (changeable by "right-click...reorder controls in cluster"). It is not defined by the cosmetic arrangements of elements in the cluster container.
09-10-2014 10:52 AM - edited 09-10-2014 11:02 AM
I do have ordered the clusters, not just moved things inside. BTW the clusters automaticaly display the right order when displayed vertically.
The question is : "Why 'Variant to Data' fills probe 19 wrong while probe 16 is right, even though the 'Pdt_D' cluster do mirror the column ordering ?"
Simple question calls for simple answer.
David
09-10-2014 11:05 AM - edited 09-10-2014 11:08 AM
@Kochise wrote:
The question is : "Why 'Variant to Data' fills probe 19 wrong while probe 16 is right, even though the 'Pdt_D' cluster do mirror the column ordering ?"
Simple question calls for simple answer.
And how are we suppose to know????
You have not posted any of your code as in a VI. A PNG file doesn't count.
Frankly I don't give a hoot what your Access database looks like.
09-10-2014 11:08 AM
@Kochise wrote:
The question is : "Why 'Variant to Data' fills probe 19 wrong while probe 16 is right, even though the 'Pdt_D' cluster do mirror the column ordering ?"
Until just now, you haven't mentioned probe 19 and that it is "wrong" (whatever that means), just that probe 20 is right.
This is impossible to troubleshoot from pictures alone, but did you notice that the wire on probe 20 causes a coercion dot at the next function, indicating a type mismatch?
09-10-2014 12:18 PM - edited 09-10-2014 12:26 PM
Looks like to me that probe 16 is a variant array. You pass this into the variant conversion VI with a cluster as the new type. Maybe this is causing the reordering. or the ordering of cluster controls in this constant is wrong.
09-11-2014 01:53 AM - edited 09-11-2014 01:56 AM
Ok, I've found the bug in LabView 2013 SP1.
The 'Pdt_D' cluster had suffered several modifications and
reordering, but 'Variant to Data' doesn't follow the cluster
virtual ordering but the cluster's memory ordering.
In short, if you create a cluster one way, delete members,
add some more, adapted and reorder, the 'Variant to Data'
VI will take the members' order in which they were added
to the cluster, regardless of the hypathetic ordering you
might have specified afterward.
Probably a problem of chained list, one listing the members
as they are added, one listing the members in the specified
ordering, perhaps the bug comes from pointing the wrong
list.
If you delete the 'Pdt_D' cluster, create a brand new cluster
constant, then add one by one the members of the right
datatype, 'Variant to Data' works like expected and dispatch
the variant's data into the belonging members.
There's is no use providing you with a snapshot because
it will all look the same that I have already provided you with,
just that the cluster has been recreated from scratch and
not been reordered. That's a rather annoying spurious bug
you'd better be strong hearthed to deal with.
And for the VI, it's a rather complex proprietary application
I cannot disclose, but I'll create an example VI further in
time so that you can witness it by yourself.
Sorry for not being specific enough with my problem.
David
09-11-2014 02:14 AM
If you think you found a real bug, please report it to NI so it can be fixed.
09-11-2014 02:18 AM
Will further investigate and create a sample
demonstration beforehand, then if confirmed,
a but report will be issued.
Thanks for your attention.
David