[Visual-devel] Version 0.0.19 in CVS

[Thomas H. <Tho...@we...>]

Hi all, Hi Ruben, Hi Thomas, Hi Michael.

I ask everyone who is experimenting with VISUAL to download the latest CVS 
files, which represent a further step in development. The main change is all 
PLC drivers and setport.cc. See below for details of these changes.

In the previous version I found some carriage returns strayed into the code. 
My editor didn't show me them and gcc 2.95 on my box did obviously just 
ignore them, but when one is in a comment starting with "//", it's 
interpreted as a newline, causing the rest of the comment to be handled as 
invalid C code.
I cleaned up all the files using the script clean.pl, which is now in CVS 
also.
I never gor messages about "no newline at and of file" with my versions of 
gccc, but I could force it to report them using option -pedantic.
I added the newlines.
I ask you Ruben, to retry compilation on your mandrake system and you Michael 
to retry on your system.
For Michael: I did not mangae to make configure adapt the Makefile to exclude 
mysql dependend targets when libmysqlclient or mysql/mysql.h are not found. 
So I ask you to comment out the log_mysqlx targets in drivers/Makefile.am, 
please.
Thank you in advance for testing.

Changes to setport:
You may now specify other files then /dev/ttySx to the serial drivers.
The purpose of this is to redirect communication to other channels. Currently,
this mechanism supports TCP/IP connections and named pipes.
Changes to PLC drivers:
The drivers now use two distinct file descriptors for read and write 
operations. Normally, when using serial or TCP connections, the numeric value 
is identical. The purpose of distinct file descriptors is to make use of 
named pipes.
Named pipes, together with slave driver modules, make it possible to test 
parts of PLC drivers with out having the real PLC hardware.
The slave driver "emulates" the PLC using spreadsheet locations instead of 
the PLC's memory.
A pair of named pipes is used to transport the driver's output to the slave 
driver and the slave driver's output back to the driver's input. Examples for 
such a configurations are in omron.cfg:

driver allen_b.so fifos abpipe1 abpipe2
driver allen_b_slave fifos abpipe2 abpipe1

Another application of slave drivers could be to integrate VISUAL into a 
network of PLCs controlled by another master.
I have set up one configuration where another comercial SCADA read values 
from an Allen Bradley PLC. I disconnected the other coputer running this 
application from the PLC. Then I connectes a machine running VISUAL. I let 
VISUAL read the values I need and the values the other application needs. 
Then I connected the other computer to the computer running VISUAL via 
another serial port. I configured the allen_b_slave.so to deliver the values 
read by VISUAL to the other application. Works fine.

Another possible application (not yet tested) of the slave drivers is to let 
a PLC program read values from VISUAL on demand.

Now comes another applicaion case for serial port redirection:
Two programs have been added to VISUAL:
serialProxy and serialClient.
These provide a (not so comfortable) way for remote programming and 
maintenance of PLCs.
Suppose you have an installation where a local computer runs VISUAL. You are 
in your office and you can establish a TCP/IP connection to this machine.
Now you can run serialProxy on the remote machine.
To develop an application with VISUAL on your local machine, you can tell the 
PLC driver to use a TCP/IP connection to the remote machine instead of a 
serial port.
This enables you to work with VISUAL as if the PLC is connected to your 
office machine. 
Another possibility is to run the program serialClient on your office PC.
Now you can connect another computer in your office running the PLC's 
programming software to the first computer's serial port. SerialClient will 
take all characters from the serial port, forward it over TCP/IP to the 
remote machine, where serialProxy will output it on the serial port to the 
PLC and vice versa.
I'm able to remote program a Siemens S7 315 with STEP7 over my Company's 
intranet in this manner.

To use serialProxy, start it with a port number to listen and the serial port 
and parameters you would use for your PLC, e.g.:
serialProxy port=11777 '/dev/ttyS1 9600 e 8 1'
Note that you need the single quotes.
To use serialClient, start it with a host address and port number to connect 
to and the serial port and parameters you would use for your PLC, e.g.:
serialClient 192.168.11.1:11777 '/dev/ttyS0 9600 e 8 1'

Thomas