PLC to HMI

As a newby to programing im a little confused as to how a program like RSview interfaces to a PLC, as i understand it the PLC scans the input tables reads the ladder logic and then sets the output tables, how does RSview intereact with this scan process without conflicts?. I understand that inputs, outputs and variables are given a tag name, how are these syncronised with the scan process? gear is AB SLC500 RSlogix500 and RSview

Great first question!

The answer is: RSView doesn't synchronize with PLC scan, and in general, it doesn't have to.

Messages across many PLC-PLC or PLC-PC network connections often work asynchorously to scan. This is partly by necessity. PC drivers are often not very efficient at sending and recieiving large chuncks of data (sometimes taking a few seconds for the message to get sent.

The PLC can't sit around waiting for data - it's got WORK to do. So a signal from the PC will "just show up" in the data tables.

Usually, this doesn't cause any problems. You often don't use the same signal from the PC in two different places in the code in two different ways such that the difference of a scan between the two rungs would cause problems, so it usually doesn't matter.

If you run into a case where it DOES matter, then rewrite you program so that the common bit on the two rungs is a different bit than the PC writes to, and then use the PC bit to drive that different bit. Now, regardless of when the PC bit arrives, the different bit will be set only at that part of the scan where the mapping occurs.

As far as PC reads go, again, it can happen anywhere in the scan. If you have logic that uses the same register for interim calculations as well as storing the final result (a common memory-saving technique), then even if the rest of the PLC program never sees anything but the final result, it is possible, that occasionally the PC will show, breifly, the interim value if it happenned to scan right when the PLC scan was in the middle of the calculation.

Again, if this is a problem, buffer the data.

Some events, such as one-shots, the PC will never see. This can make alarming tricky. Lets say you have an alarm that is triggered when the motor is ON but the AUX contact doesn't come in 3 seconds. And lets also say that you don't run the motor if the alarm occurs.

But this means that, since the motor is no longer ON, the alarm condition is now false. The alarm will stop the motor, but it won't be active long enough to be certain that the PC will read it.

Some folks get around this by making sure that the alarm is active for a minimum time - adding a timer to seal in the alarm. This is not a recommended approach, because there is no guaranty that even 5 seconds is enough for the PC to read the PLC.

A better approach is to latch the alarm, and unlatch it on some kind of response from the PC- usually an alarm acknowledgement from the operator.

Hopefully this answers your question, and gives you some things to think about.

Put simply, the PLC has a time-slice or interrupt routine set aside to deal with communications.

Some controllers even let you manipulate the amount of time spent dealing with the commuication ports. It's really not all that different from your PC.

AK

A true interupt?

As I understand it when a PC receives an interupt all other work is temporarily suspended during the interupt is this true of a PLC?

RayK,
The PLC has some overhead depending on the way it is configured.
Solving logic is just one of the MPU duties.
Certainly the total scan time includes program solve time, and servicing of this overhead, that is why there are so many specilized comm cards. Depending on the PLC it may contend with this as a smart module as the case of the AB ControlLogix backplane, most exotic comms are handled by the card with no MPU overhead.
Excessive PLC/MPU or native based comms tend to extend the total scan time.

Bitmore