Interesting thread, and right up my alley. To summarize what it seems you are trying to accomplish, your architecture is a distributed control system, and you want a Linux PC to act as the central control point. You have a serial controller application running on the Linux PC, and want to create a way for end-users to access the devices through a web interface.

If I've got that correct, then it sounds like your problem is how to have the web server communicate with the serial controller application. The solution to this becomes one of at least a couple of methods. Firstly, you can make your serial controller application into a CGI, which is Apache-speak for a program that runs as a child of the web server, takes data from the browser, and responds with data to send back to the browser. This method will work if your serial controller does not have to run/monitor continuously on your RS-485 network.

If you require a continuous monitoring scenario, then your serial controller application will have to run in the background, performing its communications and control functions. It will have to be retro-fitted with some form of Inter-process Communications (IPC) mechanism, and a CGI application will then be used to send & receive messages and/or data to/from the serial controller. The exact type of IPC will depend on the nature of the communication, but an excellent starting point for learning about the subject is Beej's Guide to IPC.

A CGI application is normally used to take data from web HTML forms. It can be written in any language, although scripting languages such as Perl are very commonly used. There are well defined protocols for the ways in which data is transferred from a web browser, though the Apache web server, down to your CGI application and back up the chain. It does take a little learning (and we're here to help), but it isn't too difficult. Most programming languages that are commonly used for CGIs also have useful add-on modules to simplify application development.

A third possibility that has already been hinted at in this thread is to simply use a common shared database as the back-end for your web interface. Both your serial controller application and the web CGI access the database independently. The controller could receive messages from the database, and deposit updates to the database. It may be the case that either or both of the serial controller application and a CGI use the database, and also use convention IPC methods. Your overall application will dictate that.

Yet another possibility is to manage all of the distributed serial nodes through a System Control and Data Acquisition (SCADA) or control system toolkit. These can be used to coordinate the communication, perform control strategies, and provide various forms of operator interfaces.

--- rod.

2 members found this post helpful.

Thank you for your very detailed response. I need to make sure that only one command gets executed at a time on the serial network to prevent corruption of the data. That was my main reason for a continuious background task when multiple users access the serial network to my devices. I think the common database may be the best soln to this. MySQL could handle multiple users and the background task could access the database to get and execute the next command to the user. The problem would be getting the returned data to the correct user. It looks like now I will make a single user interface using multitasking DRDOS and continue to learn and test my options on Linux. It was supprising to find how simple it is to make a daemon on linux with the daemon HOWTO. Will keep you informed as to my progress on this project. Thanks. Alvin....

Very interesting read indeed, and not really suitably placed in
Newbie; I'm moving this over to <PROGRAMMING>.


Cheers,
Tink

1 members found this post helpful.

that is actually the easy part, it might take a bit of ajax, but it's just a matter of stamping an identifier such as a username or uid to the user running the process, and then just having the process stamp the same username/uid on the response, then have the web interface only read the lines for the user at the current terminal

1 members found this post helpful.

You certainly don't need to use DRDOS to achieve multitasking. Linux is already fully multitasking and comes with a full complement of the traditional tools that are used for synchronization of tasks. You are going to need to use semaphores to regulate access to your serial network. The link I pointed out on IPC will include a tutorial on the various uses of semaphores. You are probably going to need something called a mutex (mutual exclusion) semaphore. My complements to you for recognizing such a requirement, clearly above the noise of the newbie question.
Does your application require any form of visualization or interactive capability that will not be done through a WWW interface?
--- rod.

1 members found this post helpful.

Do you have any communication problems with 48 receivers on the same bus?

1 members found this post helpful.

It is probably even easier than that. The web server maintains a correspondence between HTTP requests and the resulting response. If the CGI uses a backend database that is populated by runtime data from the serial controller application, then the UI will be completely decoupled from the control function.
A fairly standard control system scheme is for a perpetually running process to receive commands/requests through a common repository/database, and then populate a common database with results and status information. Other client applications can use the backend database to read the status, and populate the database with requests. The existence of such things as transaction oriented relational databases, ODBC, CORBA, etc., greatly facilitate such implementations. This is somewhat analogous to the popular Model/View/Controller paradigm used in web application architecture, and not surprisingly, dovetails nicely with it for the purpose of providing a UI. Non-web-based applications are also fairly simple to construct using this model.
--- rod.

1 members found this post helpful.

The reason to use DRDOS and not Linux is that with linux I have found that it is almost impossible to communicate between running tasks. The whole reason I started this thread is that I am a newbie and I have not found out a way for two running linux tasks to communicate. Yes you could do it through files but unix is made for simple routines that are one shot and execute quickly and completely. Most routines that do REAL work stay resident and have a well defined communications protocol between simultaniously executing tasks. Dr DOS provides the necessary structure for interroutine communications including queues . It is odd that most experienced linux users give me a blank look when I ask how concurrently running tasks communicate. Fileio between tasks may prevent security problems but does not have the appropriate handshaking to do what I want. I was moved from newbie to programming by the brass. I have been doing all things computing on a daily basis since 1968 so I guess I do know some stuff. And this post will probably flame the fires of the Linux world.

To answer MICHAELK All communications is controlled by the PC. The PC issues a command packet either for a particular serial number or as a broadcast to all boxes. Most communcation will occur between the PC and a single serial number. The single unit then either responds with data or an ACK or NAK. The PC is in total control. That is why all communications to boxes will need to be serialized through a single resident routine on the PC. On a broadcast if a box sees activity on the serial network it waits a random amount of time and then checks again for a clear channel . When a clear serial path is found and we are not in the middle of a packet it transmits a packet. so hopefully there will be enough order on the serial bus to prevent collisions.

You may wish to consider writing such a high-level program in Perl.

The reason why I suggest this is ... aside from the fact that the language is extremely powerful and portable among many different environments, it contains a rather huge library of very well-tested routines at http://search.cpan.org, including many that are more-or-less specifically targeted at purposes such as yours. "The Camel" is a general-purpose programming language that's been called "the Swiss Army Knife(R) of computing," and I completely agree with that assessment.

When you get to the software side of things, "speed (for you), flexibility (for you), and time-to-market (for you...)" are all very critical concerns. You don't want to be writing any more code than you absolutely have to, and when (not if) you next need to change that code (adapt it in five years to the next generation of hardware, etc.), that process also should be drop-dead easy.

Something else to consider is that a language like Perl is perfectly capable of being(!) "the web server." There are plenty of web-server packages on CPAN that literally enable you to write a functional web-server in about a dozen lines of code ... and these are not toys. You say you want to be able to deploy to Windows and to Linux maybe-someday maybe-rightnow? You're there.

There is a big difference between "I want to speak in the HTTP protocol," and, "I want to load-up my controller with All Of Apache And All Of PHP So There." Most likely, you (just) want the latter. But even if you do want "a full web-server with all the trimmings," it's there. In fact, take your pick...

If you introduce this on http://www.perlmonks.org, you will be inundated with highly useful help within a matter of minutes, I daresay...

1 members found this post helpful.

In post #16 of this thread, I posted a link to a very good primer on the subject of Interprocess Communication. There is a well defined, complete and quite elegant API for IPC in Linux. There are many applications that make use of such features.
--- rod.

1 members found this post helpful.

I forgot to add that Linux also includes the capability to multi-thread, where communication between threads is as simple as using shared variables. You still may need to incorporate mechanisms to synchronize access between threads, but the API provides tools for that, too.

--- rod.

1 members found this post helpful.

Thanks to TheNbomr for the link to beej's IPC Guide (Inter Process Communications). It is probably the one thing I am looking for to answer all inter process communications which is what I wanted when I started the thread here. Thanks to sundialsvcs for the info on perl. I confess I know nothing about perl and was going to write everything in C. I will look up CPAN and the other perl routine sites you suggested. Alvin....

Michaelk asked if I would have problems with 48 devices on a serial bus. The reason it works electrically is because the bus is RS485 . A rs485 bus is a differential bus with ground. There are two lines called A and B They have a differential voltage of 200 mv. The bus can be in excess of 3000 feet in length. It is usually two wires on at twisted pair with 120 ohm resistors on each end. The terminating resistors prevent bus reflections. Usually you have a twisted pair backbone with leaders off to the individual devices. Alvin...

Last time I checked (not very recently), I'm pretty sure RS-485 allowed for 32 unit loads. IIRC, some line receivers present less than one unit load. I'm pretty sure RS-485 is used routinely with more than the specified limit, as long as good cabling practices are used.

--- rod.

1 members found this post helpful.