This page shows a selection of some technical aspects. Of course this
page is not complete and we can not show everything, which is possible
with EC32.
If you need a specific application task or driver, please send us
the technical specification and we will let you know, how long the
implementation will take. From our experience we expect one to two
weeks for a new implementation.
There is only one thing, which we will deny to implement: We are not
going to make music with this system. There are a lot of others, which
do perform much better!
If you need to hear Jonny Cash, spend the money for a radio, we will
turn it on for you at the appropriate time.
| Module |
Description |
Value |
| System-Kernel |
RTK-Realtime-Multitasking,
cooperative mode, Borland-Compiler 4.52 or higher, 32-Bit-DPMI |
|
| |
Number of available
tasks |
Not limited in theory,
depends on available memory and required system performance. |
| |
Interrupt handlers |
YES, for serial communication and network. Others on request. |
|
PLC-Channels |
16 |
|
Internal Channels |
1000 |
|
Max. Applications |
16 |
|
Max. Drivers |
32 |
|
Max. Drivers per
Application |
32 |
|
Number of discrete COM-ports |
6 |
|
Multi-IO-support |
YES |
| Messages in Mailbox |
Per Application |
64 |
| Message-Trace |
Trace to window |
YES |
|
Trace to logfile |
YES |
|
Trace to COM |
YES |
| Network |
UDP |
Internal TCP-stack |
|
Telnet (remote debugging) |
YES |
|
FileTransferProtocol FTP |
YES |
|
TCP/IP client |
For COM Server |
| Second NIC |
refer to: Supported
Hardware Interfaces |
|
| Interbus-S |
Master |
YES |
| Overall |
Y2K compliant |
YES |
Application Modules
These are only the standard application modules of EC32. Numerous
"specific application" modules are available from existing and productive
installations.
| Application Modules |
| GDGraphic-Display |
Resolutions |
min. 640x480 16
colorsmax. 1024x768 256 col |
|
Max. Pictures |
16 |
|
Screensaver-control |
Time-controlledApplication-controlled |
|
Color tuning |
YES |
|
Trending |
YES |
|
Direct Touch-control |
YESUp to 1024 pixels |
|
Touch-Button-Control |
Configurable |
|
Add. Windowing |
YES |
| PMON |
Number of Subs |
unlimited |
|
Number of Drivers |
32 |
| DBF FIFO |
Number of channels |
unlimited |
| DBR index-seq Database |
Number of channels |
unlimited |
| 8E41 |
Number of channels |
32 *3) |
| TEST |
|
|
| RK512 |
|
1 |
*1) = compiler statement, may be increased by re-compiling
the lib
*2) = may be limited by the total number of filehandles in use (max.
40 – systemhandles)
*3) = not limited by application, rather than by total number of channels
in system
This is just a selection. Numerous drivers have been
written for specific applications.
By the way: If there is a statement "Number of ports 1", this does
not mean, that there is only one port available running the 3964R
task. Drivers of the same type may exist in many instances as long
as they have the required hardware resources!
| Driver Modules |
|
Addresses |
Configurable in external file |
| Interrupts |
Configurable in
external file |
| 3964R |
Number of ports |
1 |
| DIG-I/O |
Number of points |
16 / 32 |
| ASANET-M |
Number of slaves |
31 |
| ASANET-S |
Number of masters |
1 |
| DS350 |
Scanner-Driver |
YES |
| PAR. PRINTER |
File printing |
YES |
| TOUCH |
Resolution |
640x4801024x768 |
| ODS-PAGE |
MarkSensingCard |
YES |
| UDP |
Number of conns. |
32 |
| Deister-Identsystem |
Fixed ID tag system |
|
|
Max. Number of nodes
per connection |
4 |
| TCP |
Number of conns. |
32 |
|
Max. Number of nodes
per connection |
1 |
| Interbus-S |
Master |
256 I/O points |
| ProfiBus-FMS |
|
|
| PLC Connectivity
*) |
| Modicon |
Via ModbusPlus
Via TCP |
| Siemens S5 |
With VIPA Slot-PC |
| Siemens S7 |
Via Profibus |
| Other |
Profibus ? |
*5) = 2nd Control block in preparation
Outstanding highlights
Very often we are involved in discussions why we do not create
a similar system based upon Windows NT or Unix.
The reason is not that we could not do that. It's simply because
we do not want to do this, because we are thinking one step ahead
and also keep in mind, what happens if for any reason the systems
fails.
Anybody who has already made a complete re-installation of a Windows
based application knows, what we are talking about.
Give your maintenance a KISS (Keep It Straight
and Simple)!
1. Re-Configurable
Due to the fact that many of the parameters are available through
external text files one does not need a specific knowledge of
software development for changing basic parameters.
Even if there is a problem with a COM port, possibly caused by
static overload, with a little change in the central project file
a spare port may be assigned to the failing section and repair
activities can be delayed until a period of no production.
2. Easy to re-install
If the hardware of a productive system fails completely,
it is essential to have it replaced in a very short time, since
every minute could cost a large amount of production time and
money. Parallel with the replacement of the hardware goes the
re-installation of the software. The software of this system fits
entirely on only one diskette, making it possible to re-install
the package just in a few minutes. Compared with systems, which
run Windows or OS/2, this is much faster. Furthermore, maintenance
is not faced with cryptic registries and configurations.
3. Diagnostic features
With average applications all one can see about what the software
is doing is presented on the monitor or on a printer. But the
monitor should be reserved for the normal user and a printer is
much to slow for showing all the internal software activities.
Especially during the first installation phase of a new application
and during troubleshooting activities there is strong requirement
for more and detailed information about the software execution.
For our own benefit we have implemented an interface to the system,
which allows interactive communication with the system and its
modules through a special monitor task:
Each task running in the system creates diagnostic messages, depending
on its status and a global variable, the debug-level, which is
specific for each task and is defined in the project file. The
diagnostic messages are sent to a driver, which is associated
with the monitor task and which connects to a COM port specified
in the project file.
Using an external PC like a laptop connected to this diagnostic
port it is easy possible to display and record these message for
immediate or later analysis.
Furthermore, a diagnostic window is available, which can be opened
at any time by the operator in order to monitor the current system
activities without influencing the ongoing processing.
Concurrently, if so specified in the project file, the diagnostic
messages are written into a log-file on the hard disk. The logfile
grows up to a specified size (up to 10 megabytes), then renames
itself to a backup. Depending on the system activity and the debug
levels set for your system and applications you could have up
to a couple of days in your logfiles.
|
A-Modules
