Rockwell - Convert Two INT to REAL

[drbitboy]

one rung, two three instructions

OTU ctrl.EN     FAL ctrl 56 0 ALL intarray[112 - (2 * ctrl.POS)] intarray[110 - (2 * ctrl.POS)]     COP intarray[1] realarray[0] 56

 

[dalporto]

It takes three rungs in ladder logic. You need three Index values, a scratchpad INT[2], and a scratchpad REAL.

Ohhh, it's pretty sweet, it's working fine! Many, many thanks.

I'm kind of embarrassed to ask more, but for my understanding here:

• I needed to assign a 112 value to Local_Index_1 DINT, right? For it to know it's 112 INT long;
• The Execute_Conversion_Routine needs to be triggered to refresh. So, what should I do with that rung? I suppose that I cannot just get rid of the XIC and the ONS here, ad that the FOR needs to be triggered each time to refresh.

 

[dalporto]

one rung, two three instructions

OTU ctrl.EN     FAL ctrl 56 0 ALL intarray[112 - (2 * ctrl.POS)] intarray[110 - (2 * ctrl.POS)]     COP intarray[1] realarray[0] 56

PLC Faulted.

3/9/2024 2:42:24 PM
(Type 04) Program Fault (can be trapped by a fault routine)
(Code 20) Array subscript too large, or CONTROL data type POS or LEN invalid.
Task: <unknown>
Program: <unknown>
Routine: <unknown>
Location: <unknown>

 

[dalporto]

 

[robertmee]

View attachment 68645

Theres an error in his code...110 - 56×2 yields a negative index, faulting the FAL. Change the count from 56 to 55 in the FAL.

 

[dalporto]

Theres an error in his code...100 - 56×2 yields a negative index, faulting the FAL. Change the count from 56 to 55.

Doesn't work neither.

 

[robertmee]

Doesn't work neither.

You changed the length to 55? Your Int array needs to be 112 and real array 56.

I haven't tested his code, but not sure it would work...I would think the COP would need to be 112, and I don't think the FAL is actually swapping words.

First iteration copies word 110 into 112, second iteration copies 108 to 110, etc.

 

[dalporto]

You changed the length to 55? Your Int array needs to be 112 and real array 56.

I haven't tested his code, but not sure it would work...I would think the COP would need to be 112, and I don't think the FAL is actually swapping words.

First iteration copies word 112 into 110, second iteration copies 110 to 108, etc. Looks to me like you'd end up with the same value in all the even words and the odd words untouched.

I mean it's still going to fault.

I was also under the same impression as you, but then I taught he meant to offset only the even numbers so all the array would be re-arranged in the correct order, so starting at 1 we could do a COP.


But Ken code is working so far, I just need to understand what to do with the FOR rung so data can refresh.

 

[5618]

Silly question: can’t you just word swap in the Prosoft module commands? What module are you using?

 

[dalporto]

Silly question: can’t you just word swap in the Prosoft module commands? What module are you using?

MVI56E-MNETC

Yeah, I can Swap the Words in there too but I'm not sure it will work before I hook up the power meter. I hope it will but I want to be prepared in case in doesn't and I don't have any time left to figure a way to make it work under pressure.

 

[robertmee]

I mean it's still going to fault.

I was also under the same impression as you, but then I taught he meant to offset only the even numbers so all the array would be re-arranged in the correct order, so starting at 1 we could do a COP.


But Ken code is working so far, I just need to understand what to do with the FOR rung so data can refresh.

Ah. Yes, I see what he did....clever, moving the evens ahead of the odds.

If the arrays are proper length, shouldn't fault once the LEN in the FAL was changed to 55.

Your int array needs to be 113, since he's using an extra spot to shift all the evens.

 

[robertmee]

You changed the length to 55? Your Int array needs to be 112 and real array 56.

I haven't tested his code, but not sure it would work...I would think the COP would need to be 112, and I don't think the FAL is actually swapping words.

First iteration copies word 110 into 112, second iteration copies 108 to 110, etc.

I hate we can't edit posts...112 needs to be 113.

 

[dalporto]

No Fault with intarray of 113 now. I didn't remember but he mentioned it earlier.

Haven't tested how it's handling the data yet.

 

[dalporto]

There is still something not aligned as it should.

 

[drbitboy]

There is still something not aligned as it should.

Can you read (i.e. into the .ReadData array) a pair of holding registers that represent a REAL, and for which you know the value, on the Modbus Slave device?

Then post the REAL value and the two INT registers here. Then we will know the byte and word order.

Another option would be to put the INT pair 0x4041 and 0x4243 (4041H = 16449 decimal; 4243H = 16963 decimal) into a .WriteData pair, COPy those to a REAL on the PLC, and then post what the value of the REAL is on the PLC and what the value of the REAL that is written to the Modbus Slave device.