DottyMatrix software stack: the front end

It’s one thing building an interface – it’s quite another working out how to use it.

My DottyMatrix serial-to-parallel device is designed to drive my venerable old Epson MX-80 F/T III dot matrix printer (although it should work with any printer using a Centronics parallel interface). So far, I’ve mostly spoken to it using a terminal, sending text directly from my desktop computer over an FTDI USB-serial cable.

But that’s not how it’s meant to be. The idea is to use a Raspberry Pi as a printer server. I’ve already mentioned how this seems to involve an astonishing number  of technologies. However, I’ve done some more work and things are becoming clearer. Here’s an overall view of how it’s going to work (click on the image to see a bigger version).

You’ll be relieved to hear that I’m not going to go through it all right now. I’m going to focus on the front end, which is the stuff in the yellow box (‘web server’) on the Raspberry Pi.

Web interface

I decided on a web-based interface because that makes it easily available from any computer on my home network. (No, it’s not reachable over the web so forget about printer your program listings on my Epson – sorry.)

This does raise the issue of how to talk to the DottyMatrix interface, though. A connectionless technology like HTML doesn’t fit naturally with microcontroller-based applications. So I’ve split the Raspberry Pi applications into two main parts – the web front-end and a back-end printer server application ( that runs continuously, written in Python. It’s the latter that talks to the DottyMatrix, but we’ll talk about that more in a future instalment.

I use web servers on quite a few of my Raspberry Pi machines, with Apache running as user ‘intranet’. I’m using PHP for the apps here. I use Bootstrap to create a nice interface with the minimum effort. It was obvious early on that JavaScript would be needed to supply most of the user interface functions, and some of this is done with jQuery because it makes the code a little simpler in places.

The purpose of the web app is to:

  • Present a list of files in a dedicated directory.
  • Allow me to upload new files to the directory.
  • Delete files from the directory (not implemented yet, but should be trivial).
  • Select and print a file.
  • Check that the Python-based server is running – and start it if it isn’t.
  • Check the printer status.

To speed things up, a lot of this is done using Ajax. An Ajax server script (printerSvr.php) does stuff like getting the file list, querying status files (of which, more later) and then reports back in Json format. It’s just a cleaner, more attractive way of creating a single-page app as opposed to the PHP-only route that requires constant page reloading.

Not real time

Even with the benefit of Ajax, though, it’s worth bearing in mind that the web app is, to put it politely, ‘stateful’. One example of where this is significant is when checking the printer status.

Not even the back-end Ajax server talks directly to the DottyMatrix. So how do we know the printer status? The answer lies in one of that row of three text files you can see in the diagram.

The constantly running Python-based, which does talk to the DottyMatrix, keeps a watchful eye on the printer status. Whenever it changes, it writes the current status to a text file, printerStatus.msg. This is accessible by the Ajax script. And so, whenever I click on the ‘printer status’ button on the UI, this fires off an Ajax query, which checks this file and reports back what it finds.

The ‘printer status’ message on the web app, then, just shows the status the last time it was checked. This is important to understand because, when I ask for a file to be printed, the checks to see whether the printer is actually available are going to have to be done elsewhere. I haven’t done the printing part of this solution yet, so much of the implementation is yet to be decided.

But let’s have a quick look at the UI.

We’ve just loaded the page. Calls to the Ajax server have been made to get the current list of files, the status of the back-end server and the printer status. (‘Crow’, by the way, is the host name for the RPi – I don’t know why.)

I can add new files by dragging & dropping them into the dotted rectangle, or clicking the button to use the usual file selection dialogue. The functions of the three buttons are, I imagine, self-explanatory. The file list gets updated automatically when new files are added, but it seemed prudent to make a manual check available, too.

If I click on a filename, it gets highlighted and a ‘print file’ button appears (although only if the server is running).

If, at this point, I upload new files, the print button disappears and no file is highlighted.

As I said, I haven’t yet implemented the printing function, but I know what it’s going to involve. And we should also talk about how that server status message works. These both involve intermediary text files, similar to the printer status method, so I’ll go into full detail about those in the next post.




Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.