Comms dilemma

We will soon be embarking on a project to build and install 5 machines on one site. To all intent purposes, each machine will be stand alone, controlled by its own GE 90-30 connected to its own PC running Specview SCADA (modbus protocol).



In an office no more than 100 feet from these machines there will be a supervisory PC running a network version of Specview enabling any machine's status to be viewed. This PC will also act as a print server for the 5 machine PCs enabling reports to be printed (initiated from each machine's PC).



Concerning PLC program access for maintainance, upgrading and debugging - I had originally thought of having each machine's PC having programmming software installed and connected to the programming port of each PC but then this would require a licensed copy for each machine, even though only one would be in use at any one time. Therefore, ideally, we would want one licensed copy of the programming sotware to run on the office PC with the ability to select which machine's PLC program we can gain access to.



On top of all that the office PC will be connected to a standard telephone land-line via a modem so that we can dial in from our office and access Specview and PLC programming on any of the 5 machines, probably using PCAnyware or similar.



Important point: failure of any one machine's PLC/PC, or the office PC, or any network connecting them all together, must not interfere with the continued operation of the remaining machines.



We've done single machine installations successfully before with one PLC connected to one PC with one modem connection to the phone line:

PLC programming port to PC COM1 for programming and PLC CMM311 comms processor to PC COM2 for SCADA comms - we don't use a direct modem link to the PLC due to inherrent problems of losing the phone connection halfway through downloading a new program, hence PCAnyware.



I am struggling to establish what system of communications to install on this system since it represents a step up from what we're used to and the fact that things have advanced in recent years, e.g. serial ports are not readily available on some PCs, advances in Ethernet comms. etc.



Incidentally, we're not tied to GE and Specview but prefer it as we have existing systems that work and would prefer not to have any more learning curves than necessary. We would consider Mitsi Q or SLC5 and other SCADA systems if there were a good reason to change. I just don't want this thread to end up as a discussion on the merits of everyone's favourite platform.



I would like to resolve this off my own bat so that I have a good understanding of what we're doing from the off, but any pointers on this would be gratefully received. I've tried researching on various manfacturer's websites but seem to end up with more and conflicting options each time I look into it.

An Ethernet LAN and something like a Prosoft dial-in ethernet modem sounds like what you need if you stay with telephone.

If the location has internet access you can go that route instead, just takes some security on the incoming side.

If you're going to stick with serial communications, you'll need an RS232/RS485 converter at the office PC running the programming software. The GE Fanuc manuals give the pinouts for an RS485 network connecting multiple 90-30s through their programming ports. If your office PC has two COM ports, the programming software won't interfere with the SCADA software except for the possibility of missing an update on the SCADA while downloading a program change to a PLC. Of course, that requires two RS485 cable networks.

Does the SCADA not support GE Fanuc's SNP protocol? Using Modbus limits access to inputs (%I), outputs (%Q), registers (%R), and analog inputs (%AI). You need ladder logic to copy %M or %AQ data to one of the supported types.

Ethernet would be a much more viable option. Even if the SCADA limits you to Modbus TCP protocol, the GE Fanuc ethernet module (or the CPU374) supports Modbus TCP.

My SCADAs are FIX/DMACS and are connected to GE 9070 PLCs, the CPUs are 925. These PLCs are connected to their SCADA via ethernet using a GE9 driver. I also connect my programming software; LM90 or Proficy (depending on the PLC) via the same ethernet. The programming s/w uses the MAC address hard coded into the ethernet module IC697XXX942. I believe the ethernet option is built into some of the higher level 9030 processors above 352? and they will probably use the same method - MAC address - for programming connection. There is a place in the config to declare the IP address for using the SCADA software.

Like Steve says, if your SCADA supports SNP protocol, you can set up a network on RS-485. This is a serial comm setup with sequential "drop" IDs.

In summary, there is no need to have separate copies of your programming software if you have ethernet or SNP access to your PLCs from one PC.

Hope this helps

Thanks for your suggestions so far.

I guessed that Ethernet would be the way that most would advocate, I need to look into this further - for example would you just hang everything onto one LAN? How would this affect the integrity of one machine's PLC/PC if anything went wrong on the LAN?

Guess I'm a bit out of touch but, unless you're dealing with this stuff week-in week-out, it's not the sort of thing you keep up with or carry round in your head.

burnerman said:

..for example would you just hang everything onto one LAN? How would this affect the integrity of one machine's PLC/PC if anything went wrong on the LAN?

Click to expand...

Ethernet is a place where collisions are expected to occur. If a packet is transmitted and doesn't arrive it is simply re-sent. That being said, we still don't use ethernet for PLC control purposes. We use it for monitoring programs, for data acquisition and recipe storage/download. All control decisions happen in the PLC logic and we store enough recipe info that we can run even if the ethernet link is down to the scada.

We are likely not in the majority on this as I've seen more and more vendors trying to sell systems with PC to PLC supervisory control. We just don't do it at my facility.

If each machine is stand alone, Ethernet is fine. If peer to peer PLC communications are required I would tend to use a different network. I prefer a token ring based system for multiple PLC peer to peer communications.

I understand GE now have Ethernet global bits available for the 90-30. I hear that this system runs as a layer on TCP/IP and as it does is probably OK if the Ethernet is just between PLCs. The last time I used these PLCs these bits were not available and I had to use Ethernet. It was a disaster as I was looking for high speed transfer of data between PLCs. The job was HV generators and if the neutral earth switch opens you have to disconnect the generators immediately or the 11kV goes wandering off in the distance due to no ground at the generating end. Finished up hard wiring a pile of stuff from PLC to PLC. Very expensive excercise.

If you wish to dial into the SCADA, Norton pcAnywhere is a good choice. It allows you to take over the SCADA computer and there are many good encription and sign in choices so that the SCADA computer is secure. I have used it successfully quite a few times. You only require standard modems for this.

Perhaps I should have explained more clearly that the Specview SCADA on each machine's PC is also the HMI for that machine, i.e. the only way to control and monitor the process. This is why I wanted to keep the link between PLC & PC separate from any global network.

Speed is not an issue as it is a relatively slow moving process - mainly temperature control and monitoring. It is not a disaster if the office PC or the global network falls over as long as each machine keeps working.

Based upon this, and advice given here (thanks) I have put together a scheme as the attached drawing - it's by no means cast in stone so feel free to blast holes in it and/or suggest any better ways to do it.