Phantom input

[tvaughn 0]

At work recently we have had two machines have "phantom" input signals that I don't understand. The system is a mitsubishi FX2N and a Mitsubishi F930 GOT HMI. The phantom input is M10 which is simply the fault reset PB on the HMI. It would be on sometimes even if you were on another screen then the PB. So I went in and uploaded the GOT and plc program. In the plc program it is never once used as an output so I checked the GOT program and went to device list and it is only used once in the project. When I checked the PB setup itself momentary was selected as it should be. After the first time this happened I powered it down and it worked Ok and I blew it off, but a week later the machine next to it did the exact same thing. Both machines was built by the same OEM at the same time so I feel there is something to it, hopefully something I can do. The real bad part about this is they have it programmed it so that the reset pb activates an output which goes to a relay which resets the E-stop circuit and the way it is wired it will run with the e-stops all locked in . I will be rewiring these as soon as production allows me too so if this happens again the safety circuit will still work. Hope someone can help. Thanks for your time.

[panic mode 246]

Is this PLC networked or connected to other PLC or PC?

[tvaughn 0]

The plc is not networked. It is a very simple machine as far as the controls. Just plc, hmi, 24v power supply and a few relays for the start/stop circuit. This is the reason I'm so confused.

[panic mode 246]

There must be something. Did you check if this bit is used together with others (like "mov d20 k4m0"). If you are sure it is not used in PLC program, rightclick with mouse in the ladder window and select "List of used devices..." and type in M0. If this doesn't work, post your files...

[Guest Guest]

Just speculating here, but a possibility to consider. Most HMIs handle momentary pushbuttons the same way. When the operator touches the button, the HMI writes a '1' to the bit. Then when the operator releases the button, the HMI writes a '0' to the bit. If there is a lot of data exchanged between the HMI and the PLC, the HMI may have to queue up read and write requests. If the queue gets full, new requests may be discarded. If the request to write a '0' to the PLC was the one that got discarded, the PLC would hold the state at '1'. It's also possible that noise caused the write request to fail on a checksum error, although in that case you'd expect the HMI to attempt a retry.

[Guest John Smith]

I would suspect that it is being told to go true. But you have got your idea stuck that it is the HMI (as this is the only occurence of M10) Are you sure there isnt an instruction withing the program that although doesnt mention M10, it is encompassed within. Maybe a CMP statement where M10 is the > value and only once in a while does the value go greater than the compare. There are many instructions that can use M bits without them being specifically mentioned within the instruction.

[tvaughn 0]

When I had this problem I glanced through the program and could not find an cmp, enco or similar instruction that might interfere with it. Although I will admit I was somewhat rushed as production has been hectic which is why I haven't had a chance to check it out since my last post. Hopefully I will get a good chance tommorrow. If I can't figure it out I will post the code. Thanks for all the suggestions