Rockwell Alias - ProSoft Integer array vs Float

[dalporto]

I'm not completely clear on the issue or even which side of the Modbus connection needs this, but perhaps you could create a UDT consisting of 2 integers and Alias that instead?

Yeah, this is something I could look at.

 

[drbitboy]

So, what I was wondering is if there was a way of writing the Prosoft INT-only address scheme to trick LogixDesigner into accepting a range of INT (ex: [2] and [3]) as an alias for a REAL tag.

I'm still not sure if I'm clear.

Why does the HMI need to look at the .WriteData array? Why not have the HMI look at the GX_I_63HPU tag instead?

 

[dalporto]

Why does the HMI need to look at the .WriteData array? Why not have the HMI look at the **GX_I_63HPU** tag instead?

InTouch gets its data from Modbus, not ABCIP (see my previous message).

The GX_IA REAL is written in let say MNETC.DATA.WriteData[320].

In SMC / OCMC over MBTCP it's: GX_FLOW 40320 F

GX_FLOW is then used in InTouch using that path in MBTCP, even if I could get in directly using ABCIP (again, see my previous message) .

 

[drbitboy]

After you COPy the individual REALs to the INT .WriteData array elements, you could, possibly with one instruction, COPy the entire INT .WriteData array to a REAL array, call it wdduplicates[0..100], then the bits in .WriteData[200] and .WriteData[201] pair will be duplicated as REAL wdduplicates[100] (which could have an Alias assigned to it, I think).

 

[dalporto]

After you COPy the individual REALs to the INT .WriteData array elements, you could, possibly with one instruction, COPy the entire INT .WriteData array to a REAL array, call it wdduplicates[0..100], then the bits in .WriteData[200] and .WriteData[201] pair will be duplicated as REAL wdduplicates[100] (which could have an Alias assigned to it, I think).

Yeah, but that would defeat the purpose of why I was asking at first.

I wanted to avoid to have to individually COPy all REALs, hopefully thinking to batch import the REAL in Logix along with the .WriteData as aliases.

They'll probably end up listed in a ST section now.

 

[robertmee]

That happen when the customer want to pick the PLC, and he picks a Rockwell PLC because "it's the best" but his whole setup runs in Modbus. Worst setup ever.

They have a remote control center / SCADA (really remote, hundreds of km / miles away) that comes in the Station over Modbus and we're stuck with it. So, even if we can program InTouch using ABCIP, I still need to accommodate for the Control center (commands and setpoints are the main issues if we wanted to use both ABCIP and Modbus). So, instead of doubling the logic in the PLC to accommodate for both ABCIP and Modbus , we ditched ABCIP.

And this is why I have so much question about Rockwell.

Understood, although there is no logic to accomodate ABCIP in logix. It reads the tags natively.

 

[dalporto]

Understood, although there is no logic to accomodate ABCIP in logix. It reads the tags natively.

Yes, you're right, this is mostly to accommodate for the Modbus.


Usually, I have 3 "screen levels" / control authority: Local HMI for its own unit, Station HMI/SCADA that supervises the station, and Remote SCADA which supervises many stations.

Typically, we use a mix of Modbus / DNP3 with Schneider PLC's, so we get the Station / Remote comm through a gateway, typically a RTAC or an Eaton SMP 42X0.

We have blocks (SE AOI) that we use to be bumpless between the 3 control authorities (LOC / STN / REM) for commands and setpoints (so the setpoint doesn't shift when let say we give the control back to the remote control center or we flip the pistol grip to local), so that block is expecting the same thing from each screen since it's all Modbus.

I can do the same using ABCIP, and it would be easy to replicate that if I was waiting for commands only using that protocol, which is not the case since the remote control center uses Modbus. And not only Modbus, Modbus through a ProSoft Module, which is not acting as "Schneider Modbus" where everything is read/write.

So, basically, since it's acting quite different and that I need to modify the logic I'd have used with ABCIP anyway, and because everything else on that stupid setup is Modbus, we've gone full Modbus since I'll need to deal with that for the control center anyway. And it's better that I learn all of it before the comm cutover than on-site. And they are replacing the Fanuc that does the bridge between the Station and the Remote center with a RTAC at the same time, so that will be a lot a fun.