stabillski
2020-04-30T20:09:06Z
I am fairly new with using GE plc's . I am using a IC693CMM311 communication module using both ports in RTU mode in a application and would like to know if there is an easy way to monitor when i lose communications with the external device. Are there some sort of status bits for this?
Guest
2020-04-30T20:09:50Z
Can you post your external devices that you are communicating with?
Zackbo
2020-04-30T20:10:43Z
I don't recall anything off the top of my head, but I'm shure there is something in the manual. It can be found at http://globalcare.gefanuc.com 

The manual is GFK-0582.
stabillski
2020-04-30T20:12:48Z
Originally Posted by: rwhite 

Can you post your external devices that you are communicating with?



I am communicating with some Graphic Panels that a vendor configured for us. The vendors devices reads and writes to a few %R registers in the plc.There are no comm_req in the plc logic at all. All I had to do was set my cmm311 card up to rtu only,plus baud rates. The problem is, when the graphic panes are swithed off, nothing in the registers will change. I need to be able to detect this "off" position. I do notice that the US1 light on the cmm311 constantly flashes while the graphic panel is on, then goes off when GP is off. I was hoping there was a simple way to monitor that led.?

I've been reading the manual and it seems like i may have to set up a comm_req instruction to monitor the serial port. I have never set one up and it seems kinda confusing.

thanks
Guest
2020-04-30T20:13:36Z
That is pretty standard that the operator interface requests and posts information to the PLC without any intervention from the PLC program. There probably is a status indicator to let you know that communication is active. It may be hardwired, but it probably does some type of status bit. I would have to look that up; however, the best way to handle checking communication loss either between PLC's or a graphic interface from the PLC side is to work up some sort of heartbeat between the two devices. In a PLC to PLC communication, this would require setting up a timed bit toggle that would be transmitted to the other PLC. The other PLC would check the heartbeat bit to make sure it is cycling as required. This would also work with your situation. The operator interface could be programmed to toggle a bit at a predetermined rate and the PLC could check that. This is an unusual circumstance as most operator interfaces have some way to indicate a communication loss to the operator. Generally if you lose the operator interface, you lose the ability to operate the system and indication is necessary to let the operator know. Your situation is unusual as you want to detect on the PLC side to be able to take action. You mention that nothing in the registers will change. Are you just referring to the fact that the operator cannot enter setpoints or something else?

Russell
stabillski
2020-04-30T20:14:40Z
i have an extra input pre-programmed in the graphic panel. Im going to wire the keyswitch to that and keep power on the grphic panel when turning the swith off. This will solve my issue for now.
Guest
2020-04-30T20:15:26Z
Ok I am glad that helps, but now help me out. How does that take care of your comm status? I am now completely confused....
stabillski
2020-04-30T20:16:09Z
it wont actually help with the comm status. It will only let me know if the operator decides to "shut off" his panel. I was hoping to use "comm status" as a way to do this. As of right now, if i do lose comms, the plc will not know.
RSLogix500 Introduction
RSLogix500 Inserting Instructions
RSLogix500 Opening a File
RSLogix500 Creating a Project
RSLogix500 Instruction Comments
RSLogix500 Rung Comments Page Titles
RSLogix500 Inserting Branches
RSLogix500 Program Organization, Part 1 - Overview
RSLogix500 Program Organization, Part 2 - Examples
RSLogix500 Using Symbols
RSLogix500 View Properties
RSLinx
RSLogix500 Online Offline
RSLogix500 Dowloading and Uploading
RSLogix500 Processor Modes
RSLogix500 Processor and Cards
RSLogix500 Introduction to Faults
RSLogix500 Indirect Addressing
RSLogix500 Indirect Addressing Faults
RSLogix500 Handling Faults
RSLogix500 Forcing I/O
RSLogix500  Custom Data Monitor
RSLogix500 I/O Configuration
RSLogix500 Advanced Diagnostics
RSLogix500 Instructions OTL OTU, Part 1
RSLogix500 Instructions OTL OTU, Part 2
RSLogix500 Instructions OTL OTU, Part 3
RSLogix500 Instructions, OTE
RSLogix500 Instructions, XIC XIO
RSLogix500 Instructions, ADD
RSLogix500 Instructions, COP
RSLogix500 Instructions, CPT - Part 2
RSLogix500 Instructions, CTU CTD - Part 1
RSLogix500 Instructions, CTU CTD - Part 2
RSLogix500 Instructions, CTU CTD - Part 3
RSLogix500 Instructions, CPT - Part 1
RSLogix500 - Comparison - Part1
RSLogix500 - Comparison - Part 2
RSLogix500 Instructions, DIV
RSLogix500 - FIFO - FFL and FFU - Part 1
RSLogix500 - FIFO - FFL and FFU - Part 2
RSLogix500 Instructions, FLL
RSLogix500 Instructions, JMP and LBL
RSLogix500 Instructions, Masking and MEQ
RSLogix500 Instructions, MUL
RSLogix500 Instructions, MOV
RSLogix500 Instructions, LIM
RSLogix500 Instructions, NEG
RSLogix500 Instructions, OSR
RSLogix500 Instructions, RTO
RSLogix500 Instructions, SQO sequencer - Part 1 of 3
RSLogix500 Instructions, SQO sequencer - Part 2 of 3
RSLogix500 Instructions, SQO sequencer - Part 3 of 3
RSLogix500 Instructions, SUB
RSLogix500 Instructions, TOF
RSLogix500 Instructions, JSR and RET
RSLogix500 Shift registers
RSLogix500 Instructions, SQR
RSLogix500 Instructions, TON - Part 1
RSLogix500 Instructions, TON - Part 2
RSLogix500 Instructions, TON - Part 3
Introduction to Ladder Logic