Apparent Problem with OpenG Get Data Name_ogtk.vi

[dbaechtel]

The OpenG Get Data Name_ogtk.vi is a function that takes a Data Structure in and returns the name of that structure if the Data Structure has a name.

I am using it in my Configure.vi. Configure.vi takes several data structures and saves/loads them to/from an INI file. The section name in the INI file is the same as the Data Structure name. On loading, Configure.vi takes the name of the Data Structure(s) to load and locates the Section in the INI file with the same name and then uses the elements listed in the INI section to load the Data Structure with data values.

In my case I have 3 sections. Two of the sections, Servo 1 and Servo 2 derive from the same Type Definition. I am trying to load the 3 Data Structure from the INI file attached.The System Config.ini file was generated by the Configure.vi Save function. Into the Load routine, I am passing the 3 Data Structures, each with unique names. I have explicit call to Get Data Name.vi for Servo 1 and Servo 2. But probes on the output values from the two Get Data Name.vi are returning the same string "Servo 1" even though probes on the Data Structure inputs to them clearly show unique names of "Servo 1" and "Servo 2" respectively.

It appears that the 2nd Get Data Name is returning the name of the 1st Data Structure in Error. Can anyone verify this?

Does anyone know how to fix Get Data Name.vi so that it returns the proper Data Structure names?

THANKS.

[Tanya_V]

Can you post a link to the where the openG VIs you are using can be downloaded?

Thanks!

[smercurio_fc]

---

@Tanya V wrote:

Can you post a link to the where the openG VIs you are using can be downloaded?

Thanks!

---

http://www.openg.org

[Tanya_V]

I'm missing some components of your VI to get them open.

terminate.vi (global variable)

main.lvlib (which is the owning library)

motor config.ctl

If you have this in a project can you post the whole project or lvlib? Or post the missing components.

Have you also posted in the OpenG forums?

[dbaechtel]

---

@Tanya V wrote:

I'm missing some components of your VI to get them open.

terminate.vi (global variable)

main.lvlib (which is the owning library)

motor config.ctl

If you have this in a project can you post the whole project or lvlib? Or post the missing components.

Have you also posted in the OpenG forums?

---

I am under NDA and can not post entire project or lvlib. Project is complicated and requires special hardware in order to run.

[Tanya_V]

I'm able to reproduce the behavior you are seeing. As to the why this is happening, I would again recommend posting to the OpenG forums. You should be able to get more information about how the VIs are designed to work.

[dbaechtel]

Thanks for retset.

[blawson · Accepted solution]

I was able to reproduce this and I show it here as a quirk of coercing inputs to variant on the Variant to Flattened String primitive.

Basically, if you have more than one cluster control with contents of matching type and order wired directly to this function, it will return the flattened string that it found first at every call.  The wires must be wired without first converting to variant, so you have coercion dots.

This only happens if you wire straight to the variant input on both and get coercion dots.  if you use a To Variant it does not happen.

I found that this happens whether or not the cluster is type defined, and it does not happen for constants.  I didnt try other controls.  I'll be honest, I'm generally used to coercing to variant.  I'll be more careful in the future!

----

so converting to variant first will solve your problem.  Additionally, if you leave the name input of the openG variant config section read/write VIs unwired, it will take the name it is looking for from the control you passed in, so you don't need the Get Data Name there at all.

here's a 2009 snippet.  as-is, the equals evaluates to True.  The clusters are each a dbl and a bool, but each from different FP controls.

[dbaechtel]

THANKS for the hard work and solution !

[TCPlomp]

In what version of LabVIEW does this happen?

I thought this was a bug of 8.2 only!

Please report it to your local NI AE representative.

Ton