"Motorola MOSCAD-equivalent" third party RTU

Does anyone know of a third party vendor whose Remote Telemetry Unit Remote Telemetry Unit (RTU) will emulate the MDLC protocol employed by Motorola's MOSCAD telemetry system product? Has anyone actually added such RTUs to an existing Motorola telemetry system and checked it out? In a related subject, has anyone used a third party RTU to communicate data to a MOSCAD CPU via the MOSCAD's "MODBUS-compatible" communications link? Thanks, Jim Spitzer

RE: "Motorola MOSCAD-equivalent" third party RTU

Re - Jim Spitzer query MOSCAD name came from MOTOROLA SCAD, for the memory of the SCAD missiles fired by the Iraqis on Tel-Aviv, where Motorola development team worked at that time. Since then the SCAD missiles were improved, and so are the communication solutions for distributed telemetry systems. One 3rd-party vendor you might try is A.G.M. who are upgrading existing MOSCAD and out-of-production TI RTUs systems in Israel, with their own low-cost, open system's RTU. Call +972-4-9952 171 or fax: +972-4-9952 270 Regards,

      Moshe 
------------------------------------- 
Name: Moshe Sela 
E-mail: selamo@netvision.net.il 
Date:  25/01/97 Time: 10:45:48 PM 
------------------------------------
      

Ref: c:\emacs\rtus\msg00000.sgml

Printer Port for DI

Hi Some time back I saw a little unit where it was possible to use the parallel printer port for 4 Digital Inputs. Does anybody have any idea where I can find such a "Gizmo". Kind regards Jannick Johnsson

Re: Printer Port for DI

Keep in mind that the "ground" from your parallel port is the same as runs past your Pentium CPU, plus the "5v" signal they represent is also the 5v for your CPU. If you use them and don't like your computer "hanging", be very careful to keep noise out of it. Only use them with safe, dry contacts right next to your computer. Your parallel port actually gives you about a dozen DO and 5 DI (newer ports have bi-directional data lines, so 8 more DI). If you can get by with 2 DI, you have safe option to also use your RS-232 ports. Just assert (turn on) your DTR and RTS signals via your software, then you can run these through a dry contact back to your DSR and CTS inputs. A simple software test of your DSR or CTS status will tell you the DI status. Or you can use the CD and RI pins and actually have an interrupt on contact closure. (Check with a data comm book for more discussion of these signals or programming for them). Best Regards;

       Lynn August Linse, linsela@robustdc.com
 Robust DataComm Pte Ltd, 30A Hillview Terrace #02-00
 Singapore 669247, Ph(65)764-2791  Fx(65)764-2740
 http://www.robustdc.com
 http://www.singnet.com.sg/~linsela
      

Ref: c:\scada\021997\msg00019.xml

One to one small RTUs

Hi, I am finding some kinds of telemetry equipment, data logging device or signal transmitters etc. for use in water service reservoirs or header tanks. The device has to be of low power design and suitable of transmitting analogue 4-20mA signals or water level signals between header tanks/service reservoirs to pump houses/pumping stations. Some of them will require transmission of additional 2 digital signals. The device should be able to communicate via leased wires or PSTN lines. Would any one have such kind of products, please let me informed ? Alex

Re: One to one small RTUs

On Mon, 28 Apr 1997 datac@intercon.net wrote: If your project is located in Europe you may want to contact

 W.A.S. Wasser Abwasser Systemtechnik GmbH
 Am Hafen 22
 38112 Braunschweig
 Germany
 Tel. +49-531-310390
 
 Ask for information about their MDS dataloggers.

 +=====================+======================================+
 |   Daniel Bischof    | e-mail: daniel@ap-kas.ie.philips.com |
 |       Philips       |  phone: +49-561-501-1736             |
 | Automation Projects |   dept: +49-561-501-1223             |
 |   Kassel, Germany   |    fax: +49-561-501-1688             |
 +=====================+======================================+

Re: One to one small RTUs

May be useful to look at T-BOX system of Techno Trade. You can find it at: http://www.tbox.fr . Best regards, Giorgio Castellani

 Giorgio Castellani
 Telsys
 Via Venezia 1,           telsys@intercom.it
 28100 Novara             Phone/Fax +39 321 457 603
 Italy
 
 WWW: http://www.intercom.it/~telsys/Telsys.html

Ref: c:\scada\041997\msg00025.xml

Re: One to one small RTUs

Alex, Check out the product line of Control Microsystems. They make some very good modular telemetry equipment that can be used for signal replication as well as data acquisition. Look at http://www.isa.org/directory/datacenter/P600000/M150970P.html for information.

 28 Steacie Drive
 Kanata ON Canada ON K2K 2A9
 Allan Erion, Marketing Manager
 (613) 591-1943 
 (888) 267-2232 
 (613) 591-1022 - FAX

Ref: c:\scada\051997\msg00013.xml

RTU Role

I would like to listen to the opinion of other people on this topic: "is it possible that in the near future the typical RTU will reduce its role in the electrical substation in favor of more intelligent distributed devices IED)? I'd like to try to open a discussion on this subject.

 G.Paolo FRUGONE
 Elsag Bailey Italy
 ransmission and Distribution Dept
 Proposal Manager
 Ph +39.10.658 3428  Fax +39.10.658. 3675
 Mobile +39.347.2738763 
 E-Mail: gfrugone@elsag.it

Re: RTU Role

In my opinion, the RTU will continue to evolve and will itself become more and more intelligent with sequence logic (IEC1131), better networking and the ability to work with intelligent distributed devices. I find it hard to imagine the RTU actually being replaced in the electrical substation. purely from an information management and network management ( SCADA network that it ) it is better to have the RTU as a concentrator, information gatherer, centre of intelligence for the substation. The RTU will continue to evolve with more intelligence, more independence and ability to interface to more devices, including intelligent devices. What will happen is that the boundaries between substation equipment, RTU and Master Station and their roles will become more blurred as devices and RTU's become more intelligent. Don't look at it as the RTU's role reducing in the near term, rather evolving. In the long term, anything could happen. regards, Andrew Reye.

 ____________________________________________________________________
 |  Andrew Reye                 .    Internet: andrewr@foxln.com.au |
 |  Foxboro-LN,            _--_|\   Phone:    +617 3340 2186       |
 |  42 McKechnie Drive,    /     *\  Fax:      +617 3340 2100       |
 |  Eight Mile Plains,     \_,--._/                                 |
 |  Brisbane, Qld, 4113.         v                                  |
 |  Australia                        mailto:andrewr@foxln.com.au    |
 --------------------------------------------------------------------

Re: RTU Role

All things are possible: In "traditional" architectures, an RTU would have a smaller slice of the control cake as more IEDs are introduced. In more modern designs the RTU has increased functionality in line with the advances in IED capabilities. I think it comes down to the ability of an RTU to share data with IEDs. The question as raised suggests that more IEDs means less for the RTU to do. In some ways this is true: The RTU could use the I/O of the IED instead of its own I/O by gathering data from the IED. This is appropriate where the data update rate from IED to RTU is sufficient. The RTU comms to the master could carry all RTU and IED data, instead of needing multiple interfaces to connect separately to each IED. Local processing/calculations in the RTU can coordinate the actions of several IEDs: in this case the RTU acts as a Distributed Automation computer and does MORE because it controls the IEDs. I have seen designs where a "substation computer" is installed that is interfaced to all I/O and IEDs. One architecture of this type found it was necessary to install three separate LANs in the substation to achieve adequate system performance and reliability! In similar environments an RTU and IED architecture can provide a lower module-count solution with similar functionality and better performance. My involvement with RTUs leads me to think they are a powerful component of substation control integration and automation: RTUs are evolving and becoming progressively more powerful. Modern RTUs have flexible communications capabilities and considerable user-configurable processing functionality. I wrote a paper on this topic in 1995 (things change in two years, but not too much) for DA/DSM Asia '95. I would be happy to send a copy to anyone who wants it. Regards,

.----------------------------------------------------------------.
 |         Andrew West                .       Foxboro Australia   |
 |  Embedded Systems Engineer     _--_|\      42 McKechnie Drive  |
 |  Telephone: +61 7 3340 2164   /     *\ -- Eight Mile Plains   |
 |  Facsimile: +61 7 3340 2100   \_,--._/      Queensland 4113    |
 |  Email: andreww@foxln.com.au        v          Australia       |
 '----------------------------------------------------------------'

Re: RTU Role Vs IED Vs PLC

There is no "Vs" about it. Each has its place. Sweeping generalisations (ie: these are just my opinions): If you come from an industry that can use "conventional" PLCs in SCADA applications, you can probably also use PCs as master stations, Windows-based HMI, byte-asynchronous comms protocols, one-pass controls, have a database of less than 1000 data points, can afford to loose data occasionally and the cost of inadvertent control activation is low. RTUs are normally uneconomically expensive for these systems. If you come from an industry where you need very high SCADA system availability, multiple operator HMI stations, thousands to millions of data points, need to track event sequences and inadvertent control operation can kill someone or cost thousands of dollars, you need to use RTUs. PLCs usually do not have the capabilities required by these systems. Modern PLCs and RTUs are (generally) capable of similar processing: PID loops, automated control functions, etc. PLCs are usually cheaper and generally use simpler, less-secure communications protocols. For some particular application an RTU solution or a PLC solution will be more cost effective. It depends entirely on the system functional and performance requirements. IEDs can be considered as a set of separate entities: They usually perform a specific function and perform that function very efficiently or very quickly or with great accuracy. It is usually appropriate to use specific-function devices where these criteria are important. If requirements are less strict then a programmable "general-purpose" RTU or PLC could perform the function in place of an IED. Again the system cost for performing the required functions needs to be considered, including the cost of integrating all the system components and set-up or configuration/database costs. In summary: Each system will have several possible mixtures of RTUs, PLCs and IEDs that can perform the tasks required by that system. It is the system designer/integrator's task to select an architecture that is cost effective and maintainable. Remember to include cost of data collection and protocol interfacing where necessary. Conforming to standards is very useful in this area. Regards,

 .----------------------------------------------------------------.
 |         Andrew West                .       Foxboro Australia   |
 |  Embedded Systems Engineer     _--_|\      42 McKechnie Drive  |
 |  Telephone: +61 7 3340 2164   /     *\ -- Eight Mile Plains   |
 |  Facsimile: +61 7 3340 2100   \_,--._/      Queensland 4113    |
 |  Email: andreww@foxln.com.au        v          Australia       |
 '----------------------------------------------------------------'

Ref: c:\scada\051997\msg00017.xml

E-Mail file conversions

Hello all, I'd be interested to hear of anyone's thoughts or experiences on the following.

I'm using the internet to collect summary data from RTUs using SMTP. The RTU has control over the recipient address, the message subject, and the message body (incl type). The system does NOT support file attachments.

Using the case where the destination is a desktop PC running Windows, I can easily filter and copy received messages to various mailboxes on the basis of content. I'd like to store the content (body) of these messages in separate files in other formats such as .wk4 .dbf .xls etc.

I've been unable to locate suitable Plug-ins or API's for common E-Mail packages. Any direction or advice is welcome. Thanks, Bob Lockert Carried Process

 Bob Lockert
 Carried Process
 #7, 5918 - 5th Street S.E.
 Calgary, Alberta, Canada

Re: E-Mail file conversions

The Pegasus Email program has facilities for developers to add "extensions". There is an extensions mailing list. The details are probably on their web site, or in the documentation you get when you download Pegasus. If you can't find it, email me direct.

 Ian Wiese                  Ph 6189 420 2610
 Tek Soft Consulting        Hm 6189 448 7487
 http://www.iinet.net.au/~ianw
 ianw@iinet.net.au          Fax 6189 420 3179

Re: E-Mail file conversions

I can think of a couple of things to do. Probably the easiest way will be to format the email message in comma delimited format, e.g.

23.05,345.76,on,23.87

Most programs can import this format easily.

Another way would be to get someone (say some wizz high school kid) to write a simple Visual Basic program to extract the data from the e-mail files and format it in comma delimited or spreadsheet format. Standard rate in Australia for high school programmers is a bottle of whisky and case of Jolt cola per week :-).

I'm interested in this RTU that sends e-mail. Can you tell us a little more about it?

 |-------------------------------------------|
 | Gregory J Smith                           |
 | Vector Systems Integration         ,-_|\  |
 | gregs@vecint.com.au             /     \ |
 | Perth, Western Australia ------- *_,-._/ |
 | P:618 9242 3396  F:618 9242 3397       v  |
 | WWW: http://www.vecint.com.au             |
 |    * Software Solutions for Industry *    |
 |-------------------------------------------|

Re: E-Mail file conversions

I've seen several book in the computer centers about using Visual BASIC to access the Internet including send/receive email and web stuff. I broswed one once and it sended you needed surprisingly few code lines to do this. If all you want to do is GET mail and save it out in files or formats, I suspect a VB program to do that would not be too tough.

Browse your local book stores, or Byte/PC magazine, or book publishers on the Internet. There are also a number of VB magazines out there full of 3rd party VB add-ons.

Keep in mind EXCEL can load CSV files, so one alternative is to just save this data as a good CSV and if needed create a simple excel macro to clean it up or rename or relocate it. For example you could save the desired file name on the first line and your macro could (I guess) use this to rename and save the file once run.

Best Regards;

 Lynn August Linse, linsela@robustdc.com
 Robust DataComm Pte Ltd, 221 Henderson Road #04-10
 Singapore 159557, Ph(65)272-2340  Fx(65)272-0582
 http://www.robustdc.com
 http://www.singnet.com.sg/~linsela

Ref: c:\scada\081997\msg00017.xml