Modbus ProSoft w/Rockwell PLC - Commands philosophy

[dalporto]

Hi all.

This is a very specific issue. My first time with a Modbus ProSoft. Customer setup doesn't make any sense but we're stuck with it.


Usually, on a complete Modbus setup (let say a Schneider PLC with a Magelis/Harmony screen), this is what I do for commands (it's actually more complicated, but let's keep it simple):

• On the screen, I set _CMD with %MXXXX to 1;
• PLC receives it, pulse the "usable output" of my CMD block for 3 seconds (while %MXXXX is still high);
• PLC set %MXXXX back to 0 after the 3 seconds, meaning that the screen %MXXXX is now also back to 0 and ready for next "same" command.

Two reasons why I do that:

• I'm making sure that the command doesn't fall between 2 Modbus scans by holding it for a while;
• I'm making sure that the command isn't latched in the PLC if I lose communication with the HMI / SCADA, so I don't rely on HMI/SCADA to put %MXXXX back to 0., and I then have nothing that could cycle endlessly.

On the Modbus Prosoft on a 1756 rack, there are 2 data arrays. They make a distinction and don't use the same registers. One for the Read (Read commands and SP from screen (BO/AO)) and another one for the Write (Write statuses (BI/AI) to the screen).

And this is where I need help. I'm not sure if what I want to do can be done with that. It's either it can't be done, or I don't know how to. And if it cannot be done, I'll need to know the best practices about commands on a setup like that. It would be the first time I cannot do it, I manage to do that over DNP3 so it's weird if I cannot.

So, I set a command to 1 on InTouch. I'm receiving it in my Read data from the ProSoft. So far, so good.

Problem here is it doesn't look like I can change a "read" value from the screen in the PLC since it's originating from the screen. Fact is I can do it and I can see that it's working in the PLC internal tag list, but it won't reach the screen since the screen looks like it's communicating with the internal ProSoft database only, so the HMI command stays high, and I cannot reset it, which screws up totally my command concept.

So I'm wondering if there is a way to do it. I'm going to check if I can play with the read/write arrays over the same register, but that looks like a long and messy road.

And if it's not working, what would be the more "solid" way to do it? Can I pulse from InTouch? I don't know how neither.

Thanks.

 

[robertmee]

InTouch tags can be read/write, so InTouch can set a PLC bit to on, and the PLC can reset it. You can also do momentary bits from InTouch.

 

[dalporto]

InTouch tags can be read/write, so InTouch can set a PLC bit to on, and the PLC can reset it. You can also do momentary bits from InTouch.

Yeah, I know. (I don't know how to do momentary thought)

Problem with the Prosoft is that it has 2 INT register arrays.

0-999: Read (from HMI)
1000-1999: Write (to HMI)

So what's happening is that I read the command from the HMI (1), then when I try to set that value back to zero, it stays at 1 in the internal Prosoft database and will never reach the HMI, so the HMI value stays high, even if within the PLC it looks like it's back to 0.

I'm going to try if I can overlap the registers and see what happens. I don't think it will work.

 

[robertmee]

Yeah, I know. (I don't know how to do momentary thought)

Problem with the Prosoft is that it has 2 INT register arrays.

0-999: Read (from HMI)
1000-1999: Write (to HMI)

So what's happening is that I read the command from the HMI (1), then when I try to set that value back to zero, it stays at 1 in the internal Prosoft database and will never reach the HMI, so the HMI value stays high, even if within the PLC it looks like it's back to 0.

I'm going to try if I can overlap the registers and see what happens. I don't think it will work.

Ah, that reminds me of the old devicenet panelviews....one directional only, and a pain.

You can set up momentary PBs in Intouch, or use On mouse down script to write a 1, and On mouse up to write a 0 on the same action. That would be the "pulse" you're referring to.

You could also use the PLC to read the status of an Input bit and set an output bit back to the HMI. In the HMI, have a condition script that when that output bit is 1, reset the input bit.

 

[dalporto]

You could also use the PLC to read the status of an Input bit and set an output bit back to the HMI. In the HMI, have a condition script that when that output bit is 1, reset the input bit.

This is plan B. And I'll need to plan for another button to reset all commands in case communication is lost at some point and the command is latched and now unresponsive, which I don't like.

I tried to overlap the read/write registers so I could have a couple of registers to do commands, without luck, the result was erratic.

But commands aren't that bad even if itchy and I don't like it, my biggest problem will be switching between 3 control authorities (Local-Station-Remote) setpoints while being bumpless. I don't want to have a 60MW setpoint that goes to 0MW and unload the generator because I put the 43CS back to remote.

I just wrote to Prosoft, I'll have a Teams meeting with them soon, I hope there is a way to do what I want.

 

[5618]

For what I think you're trying to do, you could probably use some conditional scripts. Press a button which sets HMI2PLC. Conditional script for other tag PLC2HMI has On True: HMI2PLC = 0; to clear the tag the button set.

Just to make sure, you're using ControlLogix with InTouch, and using ABCIP or DACIP or whatever it's called in that version really isn't an option?

 

[mad4x4]

Yeah, I know. (I don't know how to do momentary thought)

Problem with the Prosoft is that it has 2 INT register arrays.

0-999: Read (from HMI)
1000-1999: Write (to HMI)

So what's happening is that I read the command from the HMI (1), then when I try to set that value back to zero, it stays at 1 in the internal Prosoft database and will never reach the HMI, so the HMI value stays high, even if within the PLC it looks like it's back to 0.

I'm going to try if I can overlap the registers and see what happens. I don't think it will work.

Your correct they do stay high in the ProSoft because the ProSoft tags are read only. I came aross this about 12 years ago when using these card. I did eventually work it out but it was not clean. I think I used a 2nd Client for the PLC to write clears on detection of the bits rising edge. But this was a bit of a Sticking plaster. Can't remember fully if we resolved this, I think we did but it wasn't the prettiest.

 

[dalporto]

Thank you guys for your feedback.

Just to make sure, you're using ControlLogix with InTouch, and using ABCIP or DACIP or whatever it's called in that version really isn't an option?

Yes ABCIP w/ a ControlLogix, and it's working like it should when using that, same as "normal" Modbus.

Problem is that I have a control authority to deal with. Inside the station (in Local), it's an InTouch screen. But I'm getting the remote commands from a SCADA coming in the station through a RTAC in Modbus. When we learned that, we decided to go all in in Modbus since about everything in that Station is also in Modbus anyway, and we didn't want to have 2-3 distinct set of commands to deal with. And even if we'd split it now, I'm still having an issue with the remote, so we'll try to "standardize" the "new bad" concept only in Modbus.

We pushed for a Mobdus based PLC at first on the bid, but we hit a bump with the MCC being driven in DeviceNet, where most of the commands go. We'd have needed another third party device to have the DeciceNet 2 way drops "translated" to Modbus and we didn't have faith in those devices.

And there is still the matters of the setpoints that we usually track between the screens so it doesn't change when switching control authority, with the remote SCADA and RTAC not being under our scope.

Maybe ProSoft will give us a way around the issue.

I feel like I'm Dr Frankenstein working with different pieces that doesn't goes together.

 

[dalporto]

I talked with ProSoft, and it's the way it is. Different registers.

So I'll pulse the commands for 2 seconds in InTouch so it can self-reset, and I'll add Apply buttons to the setpoints since I cannot track the PV between the screens on a single tag and use it as "base" setpoint when the mode is off.

Do any of you know if there is a way to check if a setpoint / value have been entered in a box (even if the same) to create a tag to block/release the Apply/Execute button? Just want to make sure that the operator doesn't just hit it with the setpoint from 3 months ago. I was able to do it with Vijeo Designer to proof it against "too quick" operators.

Thanks.