2

The building I work in has an MS-DOS computer that runs the building's air system. My boss has asked me to make it so that he can use smart devices to make adjustments remotely.

How much would need to go into a solution for this? Is it possible? I assume I would either need to emulate the program on a more advanced computer or use some other more modern device to interact with the MS-DOS system.

The computer is wired directly to the air system. In case it matters, it is a Dell Precision 386DX/33.

I'm a software developer, but a wet-behind-the-ears one, so I'll understand technical responses despite being out of my depth.

  • 1
    By "smart devices", what exactly do you mean? In general, you could treat an older PC in pretty much the same way you could any random dumb device you want to connect to, say, a wireless network: pick up a piece of equipment that has a wireless connection and some general purpose IO lines (e.g. one of the many boards based on the ESP8266 chip) and use those lines to control the PC (e.g. by talking to it through a serial port, emulating a keyboard, or similar). From this perspective a PC is no different to, say, a coffee machine. – Jules Jun 19 '18 at 14:50
  • 1
    It's not very "smart" to have an outdated 386 with power consumption of like 100Watts do a task, a microcontroller or a raspberriPi could do too (or better) – Tommylee2k Jun 19 '18 at 14:53
  • 2
    @JonCuster - despite rumours to the contrary, getting a new PC that can run DOS programs isn't actually hard. – Jules Jun 19 '18 at 16:20
  • 1
    You can always clone the PC and run it as a VM. I'd do that first just in case the PC goes belly up. We've had a couple of 8 year old dual cores just stopping completely in the last 8 months. Just as well we'd cloned the disks. – cup Jun 19 '18 at 20:30
  • 2
    Could you please give more HW and SW information about the system? For example, what specifically controls the A/C equipment -- is it some ISA card/cards or maybe just an RS-232 connection? Or LPT connection? How does the software control the equipment -- is it run from MSDOS shell and then goes exclusively all the time or it is over TSRs and allow another uses of the computer? – lvd Jun 20 '18 at 6:43
6

You said "The computer is wired directly to the air system". I'm not sure exactly what this means, but I'd infer there is a cable between the PC and the air system, and that cable is most likely connecting RS-232 (or similar) serial ports on the two devices. I think the best starting point would be try to understand THAT interface as fully as possible. I'd begin with the reference manual for the air system that describes how it is remotely controlled by another device, most likely via its serial interface port. Adjust accordingly if it is some other type of port/interface/connection, but RS-232 serial is the usual common denominator for such systems, I think.

Armed with this knowledge, you can start to evaluate whether it is simpler to continue using the old PC, or replace it with a newer computer that will allow you to implement a new control application that just replicates the interface talking to the air system. In other words, you are deciding whether to continue interfacing to the air system through the old PC and its app, or bypass that altogether with a new app that can communicate with the air system. Theoretically, the old PC could be replaced with an IP-to-RS-232 interface, and the new app could actually run on the "smart device" tablet/phone/whatever. It would just send commands to the air system over the network, in that case.

Oh, and don't forget to build in some security too.

  • 2
    "but I'd infer there is a cable between the PC and the air system, and that cable is most likely connecting RS-232 (or similar) serial ports on the two devices." ... parallel port (being used as effectively a GPIO port) is much more likely for this kind of task (e.g. that's how most PCs used to control CNC machines and similar are interfaced, which is a conceptually similar kind of system). – Jules Jun 19 '18 at 16:27
  • @jules that depend much on the air conditioning system. if it is ment to be lead by an external system than the connection back then was either some SST interface, or simple serial. Paralell port hacks are rather uncommon in professional applications. Ofc, it the ability was later build in it may as well be a hack itself. – Raffzahn Jun 19 '18 at 17:57
  • @Jules Programmable logic controllers (PLCs) and standalone temperature controllers (e.g. Watlow) are also commonly used for this purpose. I mention this because they won't have parallel connections. – traal Jun 19 '18 at 19:09
3

Caveat: I have a hard time to consider this an RC question, as it's as well about actual software development as it is about actual hardware and an actual job. Just because the target involves some 386 doesn't mean any retro knowledge is needed or a retro task at hand. Serial or network interfaces are still common technology, aren't they?


First of all, as usual with this thing, you may want to define the ways that system can take/deliver information - in other words what are the measures to acquire data from and send commands to this machine?

Do you have access to the source?

No? Then it may get time for hacking.

Are there any documented command interfaces (serial, Keyboard, Sensors)?

No? That may need even more hacking and quite some prayers.

Without further knowledge about the whole system in question - that is the total hardware (not just some base PC) as well as the software - it's at best guessing what can be done. Typical scenarios may be:

  1. If the application has interfaces for remote control (into the PC) use them - hopefully they are documented, otherwise add a few weeks of night shifts (*1).

  2. If not, does it at least accept keyboard commands and display information? If yes, writing a TSR capturing video data and inserting keyboard input on request from an external system (like via serial) might be a way ... hacking here we come.

  3. If neither, maybe the PC is just controlling an embedded system to make it more versatile (nowadays called 'intelligent') - then your task could be replacing the PC with some newer machine offering the connections you need. Depending on the 'intelligence' of the application this might be anything but easy.

If everything fails, call someone who has done it before ... and ask you boss for a real budget first.


Bottom line, it depends on what system that is (again, system, not just the PC model), what you want to do, what is supported thereof and most of all, what's your budget.


*1 - Don't forget to account for all of them when you want to get paid. Good documentation might be helpful, as this is the typical task of 'hey, coudn't you make X work with Y' where the person requesting it will be totally baffled that you worked a month or two on a simple 'make the heating go lower' Button.

2

Step 0: Ask the people who set it up whether they know how the DOS program talks to the system.

Step 0.5: Check whether this system is going to be replaced within the next 5 years; the "proper" way is probably not worth the effort if it is.

If that's not possible, the way I'd deal with this system is as follows:

The "proper" way

  1. Set up some sort of data logger in between the DOS machine and the system it's connected to. This will vary by connector; it's probably RS-232 but it might not be.
  2. Have a play around to gather some data about the protocol they're using to communicate. Try turning the fan up and down, or heating and cooling the temperature sensor on the cooling system.

    Carry a camera around with you while you do this, and keep it pointed at whatever you're interacting with. Make sure the camera's saving the time that it's recording the video. That'll make it a lot easier to work out what action correlates to what signal.

  3. Unhook the data logger and read the data from it.
  4. Line the data up with the video.
  5. Inspect the data.
    • Is there a frequent "I'm still here" signal?
    • What is the default state of the pins?
    • What voltage does it communicate with? This might be different for different pins.
  6. Try to isolate a meaning to specific signals. You might need to do another few rounds of testing (see Step 1) to make absolutely sure you've got it right; getting it wrong can trash the equipment.
  7. Write a basic script on a [hardware protocol]-compatible device that sends a signal to the system. Does it work?
  8. See if you can get output from the system. Perhaps the DOS program was sending a "give me your stats" message to the system, or perhaps it is wired directly into the resistors.
    • If I really couldn't understand what was going on, I'd watch the DOS program running, then pause and play back execution so I could see what it was doing. Step-by-step debugging is not really possible when communicating with a non-emulated device that is not designed for said debugging.
  9. Now that you have a basic idea of the protocol, implement what you know and abstract it away. Create a RESTful API or similar on top of it. Make this code as simple as you deem reasonable.
  10. Get other things to talk to this.
  11. When you need to get that one bit working that you hadn't quite figured out, see Step 1.

The hackish way

  1. Emulate the system on a newer device.
  2. Get a hardware connection working.
  3. Put together a system to stream the display to other devices and accept input from them (modified Shell in a Box might work if it's an in-terminal emulator; tinyVNC might work if it's graphical).
  4. ???
  5. Profit.
  • 1
    He may still need to get an idea what the PC programm is doing - and just from looking at it might be hard to evaluate all operating parameters and procedures. Since there IS already a PC involved, it might be safe to assume that it's operations are anything but trivial. – Raffzahn Jun 19 '18 at 17:59
  • @Raffzahn Perhaps... Lots of that will be GUI logic, though. Hopefully there won't be that much controlling it, but it's definitely a possibility. Hence the hackish way. :-p – wizzwizz4 Jun 19 '18 at 18:33
  • 2
    I just lerned from many such projects, that there is always way more logic and rules hidden than noticed on first sight. After all, it's just controlling the temperature, and it does a fine job, what can be so hard here ... unless you learn abotu contradicting sensors, thresholds and border values changing over time plus various control curves depending on time an date and many more... Thats the moment you let that old PC run and build something arround - at least with a sensible project management :) – Raffzahn Jun 19 '18 at 18:38
  • @Raffzahn Ah... Sorry; the phrase "hardware-level interface" didn't quite register in my mind... :-) – wizzwizz4 Jun 19 '18 at 18:40
  • The core here is realy what's the task of the PC. Without a knowledge about that, it's hard to decide if a replacement is feasible. Or interfaceing at all. – Raffzahn Jun 19 '18 at 18:44
1

It all really depends on how the device operates the system.

Others here are telling you to tap the interface, and try to emulate it.

As another approach, take a look at the at the program that is used to control the device.

The trick here is instead of decoding some protocol between the computer and the device, instead, tap in to the computer to drive the program that drives the device.

A potential tact for this is to install a TSR (Terminate and Stay Resident). The TSR does several things.

One, it intercepts the keyboard interrupts within DOS, and is thus able to "send commands" to the program. If "turning the fan on" entails going through a couple of menu options, then you can simply mimic the keyboard strokes necessary to navigate the menus, select the fan, and "turn it on".

For example, say if you hit ESC 5 time from anywhere, you get back to the main menu. Then, to get to the fan controller, you go to "Menu 2" which brings up a form listing the fans. You want "Fan 2", and when you arrow down, and hit enter, you get to a form that has a "Fan Status" box with a "ON" "OFF" toggle, which you can TAB to and then hit F2 (yes, I'm making this all up).

So, send it ESC-ESC-ESC-ESC-ESC (gets to main menu from anywhere), 2 (Menu 2), Arrow Down (Fan 2), ENTER (fan screen), TAB (to the field) F2 (toggle).

Two, it can monitor the screen that's shown by the program and then "screen scrape" it to deliver output to your controller.

Third, it can install a serial interrupt handler (assuming one is available) that can be used by you to send and receive commands from your controller to the PC.

If the serial port is unavailable, the printer port might be open -- you can use that too.

You may also be able to install an Network card and a TCP stack (or NetBios, to something else).

If it's running a version of Windows (pretty much any version), it can be even easier as you can tap in to the event stream for the program, and simply send it messages -- mouse clicks, keyboard events, etc. Screen scraping is a little more difficult, but you can even read the values of controls (like text boxes and labels) on the Windows forms from a separate program. Reading the temperature from a bar chart graph is left as an exercise for the reader.

Your controller can be something like a Raspberry Pi, with Wifi. It can present a simple web interface, and interact with the PC via the Serial port and the TSR. The DOS machine will, likely, "never know what hit it" or even know you're there.

All that said, "it's a hack" to be sure. But possible. It may or may not consume a bunch of time, lots of unknowns.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.