Are there any design patterns for handling serial port communications?

Question

We are working with some new Cutting Tools that can have it's hardware parameters altered through the serial port instead of just a control panel.

When the hardware parameters are altered the hardware will take a few seconds to reconfigure itself and then signal that it is ready to be used.

Our setup before this involved the operator clicking on a Cut Plate or Part command. The software will display a dialog allowing the operator change anything that is motion related (speed, delays, etc) as well as display what configuration the hardware should be in. After the operator verifies everything he click OK and the machine starts cutting.

For the new Hardware we pull out the current configuration if there is a change we transmit and throw up a dialog showing what the new configuration is along with a indicator showing whether the hardware is ready. Not everything is automated through the serial port so sometime the dialog has to stay up there until the operator clicks OK. Other times it can unload itself when the hardware signals it is right.

My problem (and question) is that doing this through the serial ports is all painfully slow. It also the first time we done this type of work. I am concerned that I missing some solution to make the whole thing more responsive. It is not an option to use an alternative to serial as we buy the cutting hardware from a third party.

Another thing I would like to do is have the option of displaying a status dialog and leave it running without the serial communication bogging down the rest of the system.

Tips for the Win32 API, or .NET are what I am looking for.

Answer 1

One option would be to run the serial port communication in a separate thread and have that thread report it's status back to the gui thread. (Invoke)

This is how I recently coded a HID card swiping system. One thread records card swipes to a list. Another thread writes these to a database system. Each reports to the GUI thread.

Answer 2

It depends on how interactive the control of the machine is - can you just send a moveto xy, cutto xy or do you need to constantly monitor the machine and start and stop motors?

If the machine is relatively smart then I would treat it like a plotter. Build up a list of commands in your gui and then submit them. This way it is easy to test the gui independant of the machine.

You can also have a test app that takes the command list and plots it on a screen as a check before cutting expensive material. It might even be possible to convert the commands into something like HPGL or SVG and display them directly.