Does anybosy have an example to work on with OMEGA CN612 temperature controller

[RavensFan]

Attach your latest VI.

It is possible the that the registers have the other endianness and need to be swapped.

I can't tell what you are trying to do in the Write value to two registers because of the broken wires.

---

@DDuff wrote:

The top line holds the address that is calculated using combo boxes and is a U32. NO.  Addresses are always U16.  Using the register to typecast a value seem like an arbitrary decision.  Typecasting is about changing data types. It has nothing to do with a register address.  The wire going into the top of a typecast should always be a constant, and a constant of the correct datatype you are trying to cast to.  Using a live data wire is just confusing, and wrong if it isn't the write datatype.  That address works because it is the same line that is feeding the address input for the read portion of the code. No.  It doesn't work, as you say so yourself in your following sentences. I have a typecast changing the input value, set to “100” into a U32, that flows into a split numbers block (splits it into 2 words) and then they are fed into a build array so I have a 1D array of U16 with 2 elements. I have tried swapping the hi and lo of the split number block to see if they are wrong and it doesn’t work either way. I don't know why you think that set of operations will work for you.

But if your register-pair is expecting a Single, then you can't just split a U32, because that gives you two U16's, one is 100, the other 0.  You need to typecast the Single into a U16 array.  Please google how numbers are represented in memory.

---

Here is the difference between the two.  Do you see it?

[DDuff]

---

@RavensFan wrote:

Attach your latest VI.

It is possible the that the registers have the other endianness and need to be swapped.

I can't tell what you are trying to do in the Write value to two registers because of the broken wires.

---

@DDuff wrote:

The top line holds the address that is calculated using combo boxes and is a U32. NO.  Addresses are always U16.  I did not realize the MODBUS SubVI's were coercing the data into a U16. When I was looking at the line and the indicators on the line everything showed U32, so it was logical to me that the address it wanted was in a U32 format. Now I know to look at the input requirements for the SubVI and check to see if it has a little red coercion dot indicating I am using the wrong datatype. I added a conversion to fix that, Is that an appropriate way to do that?   Using the register to typecast a value seem like an arbitrary decision.  Typecasting is about changing data types. It has nothing to do with a register address.  The wire going into the top of a typecast should always be a constant, and a constant of the correct datatype you are trying to cast to.  Using a live data wire is just confusing, and wrong if it isn't the write datatype.  First time using typecast, now I know. That address works because it is the same line that is feeding the address input for the read portion of the code. No.  It doesn't work, as you say so yourself in your following sentences. I was saying the address worked, which it did because the VI's were coercing the data to the correct datatype. not the sending of of the write data.  I have a typecast changing the input value, set to “100” into a U32, that flows into a split numbers block (splits it into 2 words) and then they are fed into a build array so I have a 1D array of U16 with 2 elements. I have tried swapping the hi and lo of the split number block to see if they are wrong and it doesn’t work either way. I don't know why you think that set of operations will work for you. For the same reason my kid thought chocolate milk came from brown cows, I was uninformed of how the system worked and made the best guess I could based on self admitted limited understanding. 😂  There seemed to be some misunderstanding on what I was having problems understanding so instead of asking the same question repeatedly I tried to digest the info you were giving me, look at reference material and standards, and write some code that I thought was going in the right direction. You get a better idea of where my knowledge gap is and see that I am trying to understand the concepts instead of just asking for code handouts.

But if your register-pair is expecting a Single, then you can't just split a U32, because that gives you two U16's, one is 100, the other 0.  You need to typecast the Single into a U16 array.  Please google how numbers are represented in memory. This definitely pointed me in a good direction.

---

Here is the difference between the two.  Do you see it?

This was super helpful to have visualized and really explained a lot for me on what I was doing wrong. 

---

Let me see if my understanding of how this works is correct and write it out for anyone who may come across this in the future. 

According to the manual an internal holding register is a 16-bit entity. (Page 31, section 18) 

Profile Registers (Page 39, section 19.7) have a data type of IEEE Floating point Value as designated by a F in the type column Page 34, section 19).  IEEE Floating Point Values used in Labview are  SGL (32 bit) DBL (64bit) and EXT (128 bit)

Registers using Floats are dual register entities, thus using 32 bits. (16 bits x 2). The IEEE Floating point value that utilizes 32 bits is a SGL (Single-precision, floating point). When creating a control to send a value to the register It should have a datatype of SGL. 

The Write to Multiple Address MODBUS VI wants a 1D array of U16. To achieve that I should Typecast my SGL control into a U16 1D array.  This will split the 32 bit SGL into an array of two 16 bit as shown in your example. (SGL > U16 decimal)

Attached is my latest VI. Thanks for all of the help. 

[RavensFan]

I'm glad I could help.  And I think you summarized it pretty accurately.

Let me give a couple more LabVIEW related tips.

1.  Index Array.  You don't need to wire that 0 and 1 as constants.  When unwired the top index defaults to 0.  And any subsequent indices default to one higher than the one above it.

2.  You didn't need to add coercion bullet to make it U16.  Back where you read the hex formatted string and converted it to a number, there is a input on the lower left which defines the default datatype and value.  Unwired, it defaults to U32 with a value of 0.  If you right click that and pick Create Constant, then right click that constant and change the representation to U16, the wire coming out will be U16.  You won't need the coercion bullet.  Make all the other constants and indicators U16 as well so that you avoid the red coercion dots throughout the calculations.

3.  I find that when you are doing something like wiring in the constant for SGL or U16 which sets a datatype, it is worthwhile to make the label on that constant visible and edit it to show the datatype.  Then it clearly documents why it is there and what datatype you are using.  Since there are 6 different floating point datatypes that are all orange, and 8 different integer datatype that are all blue, putting the label on that constant makes it clear to others (and you later on reviewing your own code) that the constant has a specific purpose to define that datatype.  It is clear and self-documenting.

4.  Instead of a combobox string, you could try a menu ring.  It has a different appearance.  But instead of string label and a string value, it will give you a string label and a numeric value (set to to U16 datatype representation of course.)  That would let you get rid of the hexadecimal string to number conversions.