Sharing Memory 18/1/2009
Another few days, and I'm much smarter than I was before. Or at least I'm much smarter about how to use SysV IPC calls from C, and the functions for them from PHP.
Some time can be wasted figuring out the serialization in PHP, before realising you can ignore it and use raw shared memory. Isn't that just the way these things always work?
Anyway, a new picture for today:
The subtle change being the addition of the shared memory, and removing the 'setcoil' command utility.
After messing about to get the reading back of data from classicladder into PHP via shared memory I discovered that the socket code for classicladder is single threaded, so running a separate thread for writing failed as the socket was tied up with the poller.
Enter message queues. I created a message queue hander in pollershm using the sys V queue mechanism to pass requests back to classicladder using the same (already open) socket as is being used to poll for data. Ta Da!
The end result is that now I can have as many clients as I want, and the polling rate across the wire to the classicladder instance will only been the load from the single instance of pollershm. Currently it polls for data every second, and checks the write queue from PHP every 100ms.
With a bit of data validation and error checking this will be quite robust. Once I've got some more testing out of the way I'll throw the code online for other people to play with. It's pretty simple, but all the bits are there if you want to create a simple HMI for classic ladder, without a lot of overhead.
The current setup is two old laptops. A Celeron 600 with 180Mb of ram running Ubuntu 8.10 is the 'PLC' machine running classicladder, and a celeron 400 with 64Mb of ram running Debian etch for the Apache/PHP pollershm components. The mysql server which stores the config is a virtualised on my network, as mysql 5.0 in 64Mb of ram is just cruel.
Long term I intend the PLC machine to be a headless single board PC such as an Alix board, and the HMI stuff will go onto one of my virtual boxes. The historic trending will probably be stuck into an RRD database rather than mysql, as that's a good geeky solution!