M221 -> NB omron HMI comms

[JesperMP]

Just for clarity, I now understand that the "inputs" and "outputs" are actually Modbus registers, not PLC inputs and outputs.

 

[CMDRZOD]

So just trying a standard holding circuit wont work for me. This is where I encounter the input thrashing between one and zero when i toggle the input true. I've tried different scan times to no avail. Images attached of channel settings and logic.

When I press the HMI to turn the input true I get cycling between true and false. I can insert a TOF timer but then it is impossible for me to turn the bit back to false.

Edit: Im sending the bits to memory first as, from what I understand, this is good practice.

PS I have to go to work soon but i would be open to having someone remote desktop into my programming PC to help. I'm an electrician familiar with holding circuits and such. Just have little modbus and PLC experience.

 

[drbitboy]

O
Hope this clarifies a bit for everyone.

there is still some ambiguity, but it is semantic differences between how I think of Modbus actors (client and server) and how OP expresses the same thing.

• PLC: Schneider M221
• HMI: Omron (took me a while to realize PLC was not Omron)
• IOScanner: Modbus PLC client running on PLC (a.k.a. insensitively in documentation as Modbus Master)
• Modbus Server is running on HMI (a.k.a. insensitively in documentation as Modbus Slave)
• Every 50ms, the PLC IOScanner (Modbus Client) makes at least two Modbus requests:
  • A request to read the state of HMI input(s) from the HMI's Modbus Server
    • This includes the HMI button in question, the value (0 or 1) of which is written to PLC-internal tag %IN100.0.2 (cf. here)
    • HMI's Modbus Server reads HMI-internal state of HMI button and responds to IOScanner request with that state.
  • A request to write desired state of HMI output(s) to HMI's Modbus Server
    • This includes writing from the value kept in PLC-internal tag %QN100.1.2 (cf. here)
    • HMI's Modbus Server writes that value, from the PLC Modbus Client's request, to some HMI-internal location
• Inside the PLC ladder program:
  • every rising edge (0-to-1 transition) of PLC-internal bit %IN100.0.2,
    • Will toggle the state of PLC-internal bit %QN100.1.2
• Inside the HMI:
  • The HMI-internal input bit, that is read by IOScanner an written to PLC-internal bit %IN100.0.2,
    • is 1 when the operator is pressing the HMI button in question, and
    • is 0 when the operator is not pressing the HMI button in question.
    The HMI-internal output bit,
    • is written to by the Modbus write request of IOScanner
      • from the PLC-internal bit %QN100.1.2,

Is that close?

If yes, there are many different ways to execute a flip-flop, including the code I suggested in an earlier post in this thread, which is the most aesthetic (IMNSHO). There was a thread here or a PDF somewhere with multiple (three dozen or more, IIRC) ways to implement a flip-flop.

The key thing to understand is that the trigger (a.k.a. clock) for the flip-flop (a.k.a. toggle), specifically PLC internal bit ONS in my example, needs to be a one-shot i.e. it is true on the single scan when the %IN100.0.2 bit transitions from 0 to 1, and on that single scan only (Vasily); the %IN100.0.2 bit cannot be used to directly execute the toggling of the output bit.

 

[drbitboy]

I'm an electrician familiar with holding circuits and such.

I find it very difficult to reconcile that statement with Rung 2, which is not a holding circuit in any way, shape or form, in the image below. The three instructions on the right half of Rung 2, by themselves, would be a holding circuit a.k.a. Start/Stop pattern, as I am sure OP must know.

However, Rung 2 as written is just wrong, and this is probably causing the problem OP is having.

Start with my suggestion, replace ONS and ONS_MEM with %M30 and %M31, respectively. The circuit will work.

 

[Steve Bailey]

Can we back up a little and get the OP to explain why he felt it necessary to invert the normal methodology of PLC/HMI communications? What he's apparently trying to accomplish is pretty simple when the HMI acts as the communications client and the PLC is the server.

 

[kalabdel]

Can we back up a little and get the OP to explain why he felt it necessary to invert the normal methodology of PLC/HMI communications? What he's ap
parently trying to accomplish is pretty simple when the HMI acts as the communications client and the PLC is the server.

I am guessing that is a result of lack of knowledge and a belief that he knows ( a charge of false consciousness). He doesn't know that he doesn't know. That conviction led him to extra measures to mitigate what he believed to be an issue with communication.

I suggest the OP stop everything he's trying to so that is unless it is work that is required immediately, and lear the fundamentals; in a couple of days he will have answers to his questions.

Kalabdel MD.

 

[drbitboy]

Can we back up a little and get the OP to explain why he felt it necessary to invert the normal methodology of PLC/HMI communications? What he's apparently trying to accomplish is pretty simple when the HMI acts as the communications client and the PLC is the server.

Yah, I just checked some documentation that seems to indication IOScanner is not the only option, and the M221 can be a Modbus Server. So then the question becomes can the Omron HMI be a Modbus Client?

That said, the flip-flop logic is the same, although the the rising edge logic can be a little simpler, since it is the [PLC-internal copy of the HMI-internal button state] that is used to detect the rising edge, which edge in turn is used to change the bit (PLC-internal) that is ends up back on the HMI.

 

[Lare]

M221 is by default Modbus server and you don't need any extra coding on PLC if HMI is Modbus client.
If omron HMI have toggle bit button, you only need one PLC memory address for that on HMI.


IO scanner is usually only needed on M221 if you want read data from another device. Like another PLC or control VFD.

 

[Steve Bailey]

So then the question becomes can the Omron HMI be a Modbus Client?

In the world of HMIs, the HMI acts as the client unless there is some compelling reason for it to be the server. The number of HMIs that support Modbus TCP server is a smaller subset of the HMIs that support Modbus TCP client.
Have you ever encountered any HMI that only supported Modbus TCP as a server?

 

[CMDRZOD]

The reason Im using IOScanner is I plan to connect a schneider inverter + MPPT charge controller to the PLC and read and manipulate values using the HMI.

I found the best way to manage all of the data was to use ioscanner as it will automatically poll the devices for information. Seemed logical at the time.

I plan to use this system for home automation and control.

I understand I'm a noob. I get it. Theres lots I dont know about programming PLC's.

I've now written this flip flop logic in the attachment. The timer is required to keep the input true long enough for the flip flop logic to act on it. Seems to be working reliably now but the delay input sucks. Im sure there is a better way to do this. Maybe a rising edge trigger? I've got the modbus polling to the hmi set at 100ms seems to work okay.

 

[Lare]

The reason Im using IOScanner is I plan to connect a schneider inverter + MPPT charge controller to the PLC and read and manipulate values using the HMI.

I found the best way to manage all of the data was to use ioscanner as it will automatically poll the devices for information. Seemed logical at the time.

I plan to use this system for home automation and control.

I understand I'm a noob. I get it. Theres lots I dont know about programming PLC's.

I've now written this flip flop logic in the attachment. The timer is required to keep the input true long enough for the flip flop logic to act on it. Seems to be working reliably now but the delay input sucks. Im sure there is a better way to do this. Maybe a rising edge trigger? I've got the modbus polling to the hmi set at 100ms seems to work okay.

M221 can be client and server same time (as most of TCP devices). Use IOscanner (PLC as client) for inverter and Omron HMI still can be client also. Much easier communication on HMI side.

 

[drbitboy]

The IOScanner bits are %IN100.1.2 and %QN100.0.2, although I am not sure how those translate to Modbus server node address: the M221 manual says %IN1xx.y.z or %QN1xx.y.z translates to xx for device ID, y for channel ID, and z for object instance ID; how those map to Modbus Server Node address is less than clear.

The "100" indicates a serial line, perhaps there are multiple devices on the serial line and the PLC has to be the one Client to rule them all. However, in that case the device ID (xx) is 0, which would be the broadcast "node" address in Modbus.

 

[CMDRZOD]

My m221 has serial only, no TCP. I am using a Real Time Automation RTU -> TCP Gateway. No problem sending and receiving comms.

Since I only have the serial to work with I am sticking with IOScanner.

The rising edge instruction is what you refer to as "one shot", correct? This is my next try at the flip flop logic which I find is working very good now.

Knowing the proper terminology has been very helpful. Thanks everyone.

PS %IN100.0.0 is my input from HMI, QN100.1.1 is the output the HMI checks to see what the status of the bit is.

 

[Lare]

My m221 has serial only, no TCP. I am using a Real Time Automation RTU -> TCP Gateway. No problem sending and receiving comms.

Since I only have the serial to work with I am sticking with IOScanner.

The rising edge instruction is what you refer to as "one shot", correct? This is my next try at the flip flop logic which I find is working very good now.

Knowing the proper terminology has been very helpful. Thanks everyone.

PS %IN100.0.0 is my input from HMI, QN100.1.1 is the output the HMI checks to see what the status of the bit is.

I assume that PLC is then M221C model as there is only one serial. Add extra serial port with TMC2SL1 and then you can have one master for IOscanner and one slave port for HMI.

 

[drbitboy]

Congratulations on finding one of the many canonical ways to implement a flip flop!

The timer is required to keep the input true long enough for the flip flop logic to act on it.

That is almost certainly a misunderstanding of how the scan cycle works in digital PLCs. The canonical PLC paradigm of the power/current flowing from the high voltage on the left rail to the ground on the right rail can be useful, but it can also be misleading; specifically, left-to-right and then top-to-bottom represent time*, not voltage or current or power.


* or sequence, if you prefer.


Watch the first two or three videos in this playlist, which explain how a PLC scan cycle works; watch them repeatedly until you understand everything @Ron Beaufort says before he says it. Then come back and play your code in your head. Then play the code below in your head (it's much simpler).

Summary: only two of the rungs and two-thirds of the instructions are required; the timer is not required; see below (N.B. the Set and Reset instructions have been switched!). If this does not work, and give minimal delay, I'll shut up; the only thing that would cause this to fail is if the operator holds button for less than 100ms.