In my musings today, I started to give thought as to some of the mechanics associated with the implementation of a debugging interface for the IEC 61131-3 virtual machine run-time. More specifically, I have considering what form the debugger client and interface protocol might take – While one approach might be to start work on a development environment (or build upon an existing platform such as GEB Automation Integrated Development Environment [IDE], http://www.gebautomation.com), the scope of such development extends far beyond the core focus on this project. Such an extension of scope is neither desirable with respect to ensuring my own on-going interest in this project (which as already grown beyond my initial expectations of development scope) and overall project quality.
Beyond the development or debugging environment, there is also a question as to what communication protocol should be employed for debugging between the development environment and the IEC 61131-3 virtual machine run-time running on the target hardware. With a desire to ensure the interoperability of this platform, my preference would be for a published standard or protocol, however none of the existing, standard industrial protocols (with which I have experience), incorporate sufficient scope to necessarily support all operations required for debugging of IEC 61131-3 applications – such as start application, stop application, step execution, continue execution and the setting and/or clearing of breakpoints. Moreover, Google searches for “debugger protocols” returned links to protocols better suited to more capable host environments than those where I would expect the IEC 61131-3 virtual machine run-time to be executed.
Nevertheless, after having spent some time considering available options for remote debugging, an interesting idea emerged – Why not use the GNU Debugger (gdb, http://www.gnu.org/software/gdb/) for debugging applications running on the IEC 61131-3 virtual machine run-time?
While admittedly somewhat novel, this approach does have some merits that I can identify – Namely:
- Widely available, extensively used, existing debugging environment – This in turn is particularly advantageous for me as the existent nature of this platform means that the existing scope of this project can be maintained.
- Employs well-documented and lightweight protocol between client and server – Definitions of this protocol can be found at https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Protocol.html
- Supports lightweight server stubs for debugging embedded platforms
- Supports continue execution (c), single-step execution (s), program restart (R), setting and clearing of breakpoints (Z/z) and the reading and writing of registers (g/G) and memory (m/M).
Additionally, this remote protocol employed by the GNU Debugger can equally be employed over Ethernet or serial physical layers providing a high level of flexibility for the range of targets envisaged for the IEC 61131-3 virtual machine project. Addendum: Moreover, because of the lightweight nature of this protocol, there is no reason why it could not be incorporated within any Integrated Development Environment that might be employed or developed in the future for use with this IEC 61131-3 virtual machine project.
So, while there are some other higher priority items that I need to address in association with this project, one item that I will be turning to shortly will hopefully be the implementation of a proof-of-concept GNU Debugger stub for the IEC 61131-3 virtual machine run-time, in turn allowing for remote debugging using this standard development tool. Indeed, this promises to be a very neat solution for this element of the project if it can be proven to be workable.
IEC 61131-3 Virtual Machine 