Networked K8055 over a drop-in replacement K8055D.DLL

Kits PC Related Projects
1

Having mulled over some ideas last weekend, I came up with some code. As usual, I think it’s a good idea to ask users early in the process about what they think is useful, what is useless, and what is complete garbage, so here we go.

This file:

jannicash.info/k8055/misc/k8 … -02-08.zip

contains the current work in progress. Please note that this is work in progress and only published for discussion purposes at this time. Any or all of the API methods or features may change.

I parted with the named pipe and user land character device idea and opted for a TCP/IP based server instead. This makes it easier to keep the code portable and adds the additional ability to access a K8055/P8055 board remotely over a LAN at no extra cost.

What we have here so far is a server process, designed to become a Windows Service or a Unix Deamon process, and a shared library (DLL) that can communicate with it. Currently all of this only works under Windows, compiled with MinGW/Msys. I’m at home under FreeBSD, so don’t worry about the Unix port, it will happen. I only do it this way because it is easier to port Windows code I have written to Unix, than the other way around.

The DLL is a drop in replacement for the original K8055D.DLL version 4. The new DLL can communicate with local, physical cards, as well as with cards, that are connected to remote “server” computers. Environment variables control which card is mapped to what card on a remote computer. And it can have access to selective ports of those remote cards, sharing it with other clients. Put this DLL into the K8055_Demo directory of the SDK version 4, set the environment variable, and the demo .EXE will contact a remote k8055server over the network.

That “remote” computer can of course be the local computer as well.

Included is also a Tcl/Tk demo that uses the “asynchronous” feature of the k8055server. In that mode, the client does not have to constantly “poll” the input ports. The server is monitoring them anyway and will tell the client when something changes. Since the communication is based on standard TCP/IP sockets, it will be easy to develop packages for other programming languages like Perl, PHP, Java and whatever your favorite may be.

The big picture is to make the individual ports of K8055/P8055 cards a network resource, that can be accessed via TCP/IP in an event driven fashion.

Please feel encouraged to add your ideas and opinions. They are highly appreciated.

README:

			k8055server & k8055d.dll

	This is a program and a replacement DLL to enable an application
	controlling a K8055 USB Experiment Interface Board to do so over
	the network.


k8055d.dll

	This is NOT the original PASCAL based DLL, as provided by
	Velleman. 

	If you just replace the original k8055d.dll with this one,
	things should simply work as they did before. The library
	is supposed to be (mostly) binary compatible with the 
	original.

	It will completely change its behavior when certain environment
	variables are present. Those variables are named

		K8055NET_<cardId>

	where <cardId> is (currently) any number from 0 to 15. If such
	an environment variable is set, the DLL will not try to access
	a locally attached USB card, but instead it will try to contact
	a remote k8055server instance and claim card ports there.

	The format of the K8055NET_<cardID> environment variable is a
	whitespace separated list of parameters. The interpreted 
	parameters are:

	    host=<string>	Any accepted host name or IP address
	    			where to find the k8055server.
				Default = 127.0.0.1

	    port=<num>		The k8055server port number.
	    			Default = 8055

	    card=<num>		The physical card ID on the server.
	    			Default = <cardId>

	    digital=<mask>	A comma separated list of 1..8 port
	    			numbers, this client wants to control.
				Default = all

	    analog=<mask>	A comma separated list of 1..2 port
	    			numbers, this client wants to control.
				Default = all

	This means that a batch script:

	    SET K8055NET_0=host=192.168.0.5 card=2 digital=1,2,3 analog=2
	    someprogram.exe

	will start "someprogram.exe" and it will be able to access the
	physcal K8055 board attached as card #2 to the computer at IP
	addres 192.168.0.5 as if it was attached to the local system as
	card #0. However, the program will only be able to modify the
	digital output ports 1, 2 and 3 and analog output 2. 

	
k8055server.exe

	As of now, this program is a console program, run from the command
	prompt. It is designed to become a Windows Service or a Unix daemon
	process in the future.

	The program will open all available K8055/P8055 USB cards and serve
	their ports to connecting network client applications over the
	custom k8055net protocol on TCP port 8055. 

	Several command line options control the behavior of this program.

	    -b <addr>		IP address or hostname to bind the server
	    			socket to. Set this to "0.0.0.0" to allow
				other computers to access this computers
				cards. See "man 2 bind" for details.

				The default of "127.0.0.1" allows only
				clients from the local computer to connect
				to this server.

	    -p <num>		Port number to listen on.
	    			Default = 8055

	    -d <level>		Debug output level.
				1 = Major server status changes.
				2 = Client connect/disconnect information
				3 = Client input/output messages
				4 = K8055 card input/output data.
2

I just noticed that the MinGW pthread .DLL (required to run the server process) was missing in the zip archive. Please download it again if you want to play with it.

3

One thing I would like to discuss is the behavior of the client library in case of a K8055 on the server becoming unavailable.

I am still working on a few kinks in there but here is what I am currently trying to do (and it seems to work in my current dev tree):

When a client calls OpenDevice() for a card, that is currently not plugged in, the server responds with an error and OpenDevice() fails with return code -1.

Once a client has successfully opened the device, if the card is now unplugged the server responds to all input/output requests with an error code on the internal protocol, and the function Connected() will return false, but the server will track output requests. Once the card is reattached, the server sets it immediately into the state, that the last output requests asked for and resumes operation.

This means that a client application like the K8055_demo for example, will not even notice that the card was gone in the meantime. Only applications, that call Connected() will see that the card is gone.

Do you think that there need to be other ways of handling this disconnect situation?

4

This looks very good solution to handle the disconnect situation.
Nice work indeed!