Ring converted into intiger after unbundling a cluster

[Dominik.Bejma]

Hello everyone! 

I have a problem while unbundling typedef cluster. Cluster contains one bool and two ringss. After unbundling ringss are converted into intigers and all informations about text labels of rings are lost... How to save ring labels after unbundling? 

Best regards

Dominik Bejma

[GerdW]

Hi Dominik,

---

@Dominik.Bejma wrote:

I have a problem while unbundling typedef cluster. Cluster contains one bool and two ringss. After unbundling ringss are converted into intigers and all informations about text labels of rings are lost... How to save ring labels after unbundling? 

---

Copy the rings fron that tpedef onto your frontpanel and switch them to indicator…

Rings are just U16 values, the text is (more or less) just decoration.

[altenbach]

If the ring items are static, I recommend to replace the rings with enums.

[JÞB]

---

@Dominik.Bejma wrote:

Hello everyone! 

I have a problem while unbundling typedef cluster. Cluster contains one bool and two ringss. After unbundling ringss are converted into intigers and all informations about text labels of rings are lost... How to save ring labels after unbundling? 

Best regards

Dominik Bejma

---

I am not surprised! The picoscope driver failed to provide type defs for the Range and Coupling controls within the typedefed Settings cluster!  

You should, of course,  create the missing type definitions and replace the non type defined instances throughout the instrument driver.  Then submit feedback on that instrument driver to the Instrument Driver Network (or to wherever you downloaded that poorly developed software.)

[billko]

---

@altenbach wrote:

If the ring items are static, I recommend to replace the rings with enums.

---

In the CLD recert practice test, it there's a question about how to update a typedef'd ring on the block diagram, and the answer is by changing the integer type.  I never tested it yet, but does it update all the properties?  It seems like the answer would be "yes", but the test is pretty ambiguous about a lot of the questions, so...

Edit: yes it does!  I tested this first by updating the items in the typedef'd ring and applying.  The BD constant text did not update.  Then I changed it to u8 and the BD items updated.

[tst]

---

@billko wrote:

---

---

In the CLD recert practice test, it there's a question about how to update a typedef'd ring on the block diagram, and the answer is by changing the integer type. ...

I changed it to u8 and the BD items updated.

---

If you do something like this, you should always convert to a type which can cover all the possible ring values (hopefully your ring doesn't already start as a 64 bit type) to avoid losing actual values.

[tst]

---

@JÞB wrote:

---

---

You should, of course,  create the missing type definitions and replace the non type defined instances throughout the instrument driver.  Then submit feedback on that instrument driver to the Instrument Driver Network (or to wherever you downloaded that poorly developed software.)

---

I don't know if I would recommend touching driver code which is not under your control. It might be preferable to create a VI which translates that ring or cluster into a type which you can use and call that whenever you need the data.

I agree with the general advice of creating an enum typedef of the values (you can generally replace a ring control with an enum and get the same values if the ring has an unsigned type and the values are contiguous from zero. Otherwise, you will need a translation VI).

As another option, making the ring into a strict typedef also helps in keeping the values better than a regular typedef.

[billko]

---

@tst wrote:

---

@billko wrote:

---

---

In the CLD recert practice test, it there's a question about how to update a typedef'd ring on the block diagram, and the answer is by changing the integer type. ...

I changed it to u8 and the BD items updated.

---

If you do something like this, you should always convert to a type which can cover all the possible ring values (hopefully your ring doesn't already start as a 64 bit type) to avoid losing actual values.

---

Yes, that is a good reminder.  It would avoid a lot of sad faces.

[Dominik.Bejma]

Well, the longer I use picoscope provided VI and examples, the more I'm convinced about absurdly low quality of their LabView libraries. No documentation, no quick help, no comments, lot of bad practices, a lot of obscure and qestionable programming techniques... 

[tst · Accepted solution]

If you have a bad API to deal with and you need to work with it over time or have multiple people using it, I would suggest replacing it. Here are two options:

1. Recreate or modify the existing API to be better (working on your own separate copy, of course). This would require implementing the relevant low-level calls in your VIs (VISA, GPIB, DLLs, .NET, etc.).
2. Leave the existing API as it is and create a user friendly wrapper around it which hides all of the details of the original. That way, you only need to deal with the bad API when you initially develop the wrapper. The wrapper doesn't necessarily have to support all of the functionality offered by the original API, just what the user of the new API will need.