PLC Monitoring from HMI

[russh]

So far I'm liking the Do-More PLC, but I have a few questions...
1) what would be an effective way for my HMI to monitor the Do-More and know whether its in the RUN Mode? I want to create an alarm if its not.
2) I'm using an H2-ERM and a couple H2-EBC100's in expansion racks. Is there an effective way for my HMI to know whether the expansion racks are communicating properly? Again, I want to create an alarm if they are not.
3) Is there a way to put the Do-More into the RUN Mode programmatically? In other words, with the CPU switch in the TERM position, can I have my HMI put the Do-More into RUN Mode - as opposed to using the Do-More Designer software to do that?
Any help would be appreciated. Thanks.

[franji1]

1. Monitor DST10, from Help topic DMD0208:
contains a value that reflects the current operational mode of the controller, 2 = STOP mode, 3  = RUN mode

2. The first 16 discrete inputs in your ERM configuration show the Slave Status Bits and whether a slave is in error (ON means OFFLINE or IN ERROR).  Say you map it to X300 in ERM Workbench, that will be DLX300 in Do-more.  If you want to see if ANY bit is on, cast it as a Word and see if it's non-zero, e.g. DLX300:UW (or look at each bit individually DLX300 for Slave 1 in error, DLX301 for Slave 2 in error, ... DLX317 for Slave 16 in error).

3. No.  If you want your HMI to control whether your PLC is actually running, make that be a C bit that is a huge "disable" throughout your ladder logic program, then turn the C Bit ON or OFF from your HMI, with the PLC always in RUN mode.  Run mode is HUGE safety consideration (some PLCs use mechanical keys to "lockout" mode changes via programming software, not even HMIs).

[russh]

Thanks franji1 for your reply. A few more things...
1) I have tried to monitor DST10 for the controller mode. In Do-More Designer I can see the change from 3 to 2 when the CPU is put into Program. In my HMI I can see the 3 of Run Mode. Maybe its because I am using Modbus with my HMI that a change to Program Mode does not register in the HMI - the 3 gets frozen and not updated to 2. Still need a way to monitor Run Mode.
2) This is great - thanks. Monitoring the Slave Status Bits will work good. In the I/O mapping I see there is also an ERM status word - I have yet to find documentation on what this word contains.
3) My concern here is being able to kick the CPU into Run Mode should it stop running for some reason, without operator intervention. I have worked with PLC's in the past that drop out of Run Mode for various non-critical reasons, then require specific attention (which is unavailable most of the time) to kick it back to Run Mode.

[franji1]

1) I have tried to monitor DST10 for the controller mode. In Do-More Designer I can see the change from 3 to 2 when the CPU is put into Program. In my HMI I can see the 3 of Run Mode. Maybe its because I am using Modbus with my HMI that a change to Program Mode does not register in the HMI - the 3 gets frozen and not updated to 2. Still need a way to monitor Run Mode.

If your HMI is using Modbus - it has no access to DST data-block.  You will need to PUBLISH native Do-more registers to MIR or MHR data block (these are the built-in Do-more register data-blocks accessible by Modbus protocol, along with MI - Modbus (Discrete) Inputs and MC - Modbus Coil bit blocks).  Read Modbus Image Register 3 request (for example) will read MIR3 in a Do-more; Read/Write Modbus Holding Register 3 will read/write to MHR3.  Hence, use the PUBLISH instruction to move DST10 (a double word) into two succesive word registers in MIR or MHR (MIR is more secure for read-only values from a remote master cuz you can't "write" to MIR using Modbus).  You may just want to move a bunch of relevant DSTs status registers into MIR using PUBLISH then those would be available to your HMI via Modbus.  PUBLISH allows you to move DWORD values into non-DWORD aligned registers, e.g. copy DST10 into MIR1 and MIR2.  PUBLISH can also swap words due to byte-ordering issues on word boundaries that show up on some systems.

Before doing anything, you will want to figure out what your HMI is actually reading to make sure your protocol is implemented correctly.

2) This is great - thanks. Monitoring the Slave Status Bits will work good. In the I/O mapping I see there is also an ERM status word - I have yet to find documentation on what this word contains.

I think they are in the back of the ERM manual which is available as download on ADC's website.

3) My concern here is being able to kick the CPU into Run Mode should it stop running for some reason, without operator intervention. I have worked with PLC's in the past that drop out of Run Mode for various non-critical reasons, then require specific attention (which is unavailable most of the time) to kick it back to Run Mode.

You might try putting the mechanical Mode switch to RUN and being able to remotely power-cycle the PLC, assuming you have no need to be able to remotely put the PLC into Program mode, but there are issues with that also (unable to change modes from Designer, unable to download System Configuration changes in Run mode, et. al.).

[russh]

Thanks again!
1) In the $Main program I am using Memcopy to interface Do-More native registers to the Modbus registers (MI, MC, MIR and MHR). Following your suggestion, I used PUBLISH to move DST10 to MIR1 and MIR2. Again I can see the 3 change to 2 when monitoring DST10 (RUN to Program transition), but the MIR1/MIR2 stays at 3. Could it be that as soon as the Do-More is not in RUN Mode it is no longer "publishing"? It kinda seems reasonable that if the program is no longer running, its not going to move the DST10 value to the MIR register - or am I out to lunch.
2) Found the manual - thanks.
3) I will need the CPU switch in TERM for the reasons you described, so I may have to live with operator intervention if it needs to be put into RUN mode.

[BobO]

Thanks again!
1) In the $Main program I am using Memcopy to interface Do-More native registers to the Modbus registers (MI, MC, MIR and MHR). Following your suggestion, I used PUBLISH to move DST10 to MIR1 and MIR2. Again I can see the 3 change to 2 when monitoring DST10 (RUN to Program transition), but the MIR1/MIR2 stays at 3. Could it be that as soon as the Do-More is not in RUN Mode it is no longer "publishing"? It kinda seems reasonable that if the program is no longer running, its not going to move the DST10 value to the MIR register - or am I out to lunch.

Funny...that's exactly the problem. You can stuff a 2 in there in system task $tLastScan...which gets run by the system as it transitions to program mode.

3) I will need the CPU switch in TERM for the reasons you described, so I may have to live with operator intervention if it needs to be put into RUN mode.

Do-more should *never* drop out of RUN mode unless there is a very good reason. In the case of the some of the I/O failures, we have even made provisions to prevent normal critical errors from leaving RUN mode...although busted I/O seems like a very good reason to quit running, so I don't recommend using such features unless you have a very good reason.

[franji1]

Could it be that as soon as the Do-More is not in RUN Mode it is no longer "publishing"?

Doh!  That's it!  (sorry about that).

One possible solution, have your HMI write a 0 to a Modbus Coil or MHR, but have ladder logic overwrite it EVERY SCAN with 1 (use SET or MOVE).  If the PLC ever goes to PGM mode, that SET/MOVE overwrite will not occur.  Hence, have your HMI read back the same coil/register and if it's a 0 you know the PLC is in PGM mode, 1 if it's in RUN mode.

[russh]

Haha - I thought I was missing something. Thanks for the update.
I tried the $tLastScan trick that Bob0 suggested - but with the same result - the HMI still does not pick up the transition from 3 to 2.
In the mean time I had implemented something similar to what franji1 has suggested. I setup a system of bit setting and resetting between the HMI and the Do-More, creating a Run Mode "Heartbeat". My HMI generates an alarm when the heartbeat stops. Seems to work good.
Thanks for all your help, guys. Much appreciated.

[BobO]

I tried the $tLastScan trick that Bob0 suggested - but with the same result - the HMI still does not pick up the transition from 3 to 2.

Worked fine for me. Note that I wasn't proposing another publish of DST10...it will still contain 3 during $tLastScan, but simply moving 2 into the same destination location. You can do the heartbeat, certainly no harm in that, but it does force you to add extra comms by writing a value back to the PLC at some interval. A simple answer is to simply not use DST10...just write a 1 to some location in $tFirstScan and a 0 back to the same location in $tLastScan.

The heartbeat is probably more robust a solution though...can't mess it up.