CITECT to SLC500 Communication

I am writing a program in RSLogix which will interface with a PC based CITECT application. I'm fairly new to the PLC world and have a question...

How do the two applications (logically) exchange data? In looking at other applications which interface to a CITECT it appears that no explicit read/write actions are required by my RSLogix program and that the CITECT reads and writes directly to & from bits defined in the RSLogix application. In effect, it appears that logical interaction with the CITECT is achieved in a similar manner as handling physical I/O with plant devices, but using binaries, numerics, etc.

Is this the case? Is some form of ascii read/write command required by the RSLogix application?

Thanks.

I'm not specifically familiar with Citec, but most PC based SCADA and HMI software operates using the same principle. The PLC logic works completely independent of the SCADA system, and the only adaptation in the ladder logic is making sure the data is available in PLC registers in the proper format for the SCADA software. For alarm bits, direct I/O reads, timer presets, etc. this may mean that nothing special is needed. For things like analog process variables this may require scaling or data format conversion and then moving or copying data into registers for the SCADA to access. I usually keep all my SCADA accessible data in a single block to simplify housekeeping and minimize communications, but it isn't mandatory.

In the SCADA software you generally set up a tag base or list of registers and bits that the program will be reading from the PLC(s). This usually entails identifying the PLC address and register of interest, formatting or scaling it to show on the screen, and identifying the data type (bit, integer, real number). The SCADA software includes a communications driver that constructs the commuications strings and data read/write commands into the protocol expected by the PLC's protocol. The driver also handles error checking and addressing. The driver then communicates the read/write "packets" over the PC port, be it serial, ethernet, or otherwise. The SCADA software formats the information it gets from the PLC and displays it on the screen in the manner identified by the user's screen configurations.

Thanks Tom, that makes sense.

The prevailing model for HMI/SCADA communications with PLCs is that the HMI application controls the communications. The PLC only responds to data requests from the HMI.

When RSLogix software is online with PLC but you're only using it to monitor what's going on, not making any changes to the program, it (RSLogix) still needs to periodically get fresh data from the PLC CPU. It does this with one of several possible communications protocol drivers (DF1, DH485, DH+, etc). If you've read some of the other posts on this forum, you've seen references to the PLC's 'scan' cycle. Quite often, people mention the basic scan cycle as including, 1) read the input modules, 2) execute the ladder logic, 3) update the output modules with the results of the logic solution, 4) go back to step 1 and repeat. In addition to these steps, the PLC will also check its communications port(s) to see if any external devices have requested any information and respond to any pending requests.

The CITECT application uses the same communications driver as the RSLogix software. When you develop the CITECT application you define which communications protocol to use and also set up the port parameters. Then, when you create your tag list you link each tagname to a memory address in the PLC and define how often you want to update each tag.

So, for many applications, you don't need any ladder logic to enable communications with the HMI. It's handled as part of the overhead.

You may choose to include logic in the PLC to make the communications more efficient. Let's say the HMI needs to display the values in N7:10 and N70:10. If you link two tags to those two addresses, it requires two seperate transactions for the HMI to update the two tags. One transaction requests the data at address N7:10 and the second requests the data at N70:10.

Now suppose N70:11 is not used anywhere in your ladder logic, and so is available to you. On the HMI side, you could modify your tag definitions and link one tag to N70:11 instead of N7:10. On the PLC side add one rung of ladder logic that copies the value in N7:10 to N70:11. Now the HMI can refresh the data for both tags in a single transaction. It will simply request two words of data starting a N70:10. In fact the CITECT probably optimizes the communications without you being aware of it. If your taglist needs the values in N7:10 and N7:15, but not N7:11 through N7:14, I'll bet that CITECT sends a single request for 6 words of data starting at N7:10, rather than a request for N7:10 followed by a second request for N7:15.

Thank you Steve for the expanded discussion, very informative.

Given that the SCADA application controls the processing of information between itself and the PLC are commands such as AWT (ASCII write) & AWA (Ascii Write Append) used very often? If so, when?

Thanks.

There are cases where the PLC needs to control the serial communications. You might have a device that can't initiate serial communications, but can respond to requests for data. This type of device is called a communications slave. The device initiating the communications request is called the master.

When the PLC is the communications master, you use the ASCII Write command.