Effective embedded product development involves coordinating a large number of tasks in complex relationships, managing risk and dealing with issues that arise due to uncertainty. Development teams are multi-disciplinary and can involve industrial and user experience design, mechanical design, electronics design, embedded, desktop, mobile and cloud software development, product verification and validation testing, and manufacturing process development, each with its own unique processes and workflows. Put simply, the effort needed to bring a complex high-tech networked embedded product to the world should not be underestimated.
Regulatory requirements must be met before a product can be placed for sale, including meeting electrical emission and compliance regulations, safety related requirements that may impose specific product requirements or following specific development processes, and environmental requirements affecting component selection and recycling of packaging and eventually the product itself. Managing regulatory requirements and demonstrating compliance is a critical part of the development process.
Software development today commonly includes a wide variety of open-source software components, such as operating systems, device drivers, database systems, data encryption, and network communication stacks. Each software component is licensed by its creator, and imposing specific requirements on use. In addition, use of encryption technologies is usually subject to national security regulations. Managing this complex interrelationship of requirements requires careful attention to ensure the final software application will be free of undesired encumbrances and can be distributed legally.
Development of a high-tech product can be a complex undertaking, involving a complex relationship of simultaneous tasks. To be effective, an engineering project manager must not only have related technical experience, but must also provide a suitable balance between attention to detail and time to market, without allowing unacceptable risk or sacrificing quality.
PLM and NPI
Product Lifecycle Management (PLM) describes how a product is consciously managed from concept through design, into manufacturing and sales, and eventually to retirement. PLM includes aspects of Product Management and also Sustaining (aka Maintenance) Engineering to add features, eliminate defects, optimise process, increase quality, etc. PLM integrates people, data, processes and business systems, and provides trust-able and transparent design and manufacturing data.
New Product Introduction (NPI) is that portion of PLM involved with the hand-over from engineering design to manufacturing and eventually introducing a product into the market for sale. NPI is a broad topic, and depending on the organization, industry and product, may include Design for Manufacturability, Pilot Production, and Validation Testing, as well as creation of marketing and sales materials, managing sales campaigns and events, developing eCommerce and service subscription processes, and whatever else can be involved in bring a product to market.
Modbus is a communication protocol for industrial devices developed in 1979 by Modicon, now Schneider Electric.
A Modbus network consists of up to 247 Servers (originally Slave), and typically one Client (originally Master). A server is commonly a dedicated end-point device, such as a sensor or control device, and a client is commonly a Programmable Logic Controller (PLC) or gateway device in a SCADA network. A client reads or writes to the Coils and Registers in a server, whose purpose is unique to that server.
A Modbus communication starts when a client sends a message to a specific server, either requesting current coil states or register values, or sending states or values for the server to use. The server responds with either the requested data, or confirmation the sent data was accepted.
Modican designed the Modbus protocol for their PLC products, and freely provided the specification so that others could communicate with their PLCs. Modbus has since become a de facto industry standard for industrial devices, due at least in part to the specification being freely available to use. Modbus has evolved over time to remain current, starting with Modbus ASCII using serial RS-232 and RS-485 communications, then binary Modbus RTU for efficiency (also using RS-232 and RS-485), and more recently Modbus TCP for use with Ethernet networks.
Interest in Modbus has surged recently for use in the Industrial Internet of Things (IIoT). Modbus TCP enables data to be exchanged over a wide network, leveraging the advantages of Ethernet and the IwIP network stack for wireless end devices.
For testing and evaluation, general purpose Modbus software running on a desktop or laptop computer is often more convenient than using a purpose-designed Modbus device. A Modbus Client (Master) simulator can be used to query data from devices, and can be a valuable test tool when developing a Modbus Server (Slave) device. A Server (Slave) simulator can be useful as a digital twin for verification testing when developing a physical slave device, or as a device to interact with when developing a Modbus Client.
The following is a non-comprehensive list of available Modbus Server and Client software. If one of these doesn’t quite suite your needs, you consider adapting an existing open-source project or create your from-scratch solution using an open-source Modbus library.
Please post a comment to say if you have found any of these useful, or if you use software that is not listed.
Free Client (Master) Simulators
CAS Modbus Scanner
CAS Modbus Scanner is free Windows-only software from Chipkin Automation Systems recommended by Stephen. CAS Modbus Scanner can retrieve coils, inputs, holding registers, and input registers (displaying values in a variety of formats), and also discover Modbus devices on a network (testing every address, function, length, and offset to check for exceptions or responses). Source is not provided.
The scanner function came in handy recently when I used it as part of the verification test program for a new industrial controller.
ModbusScope
ModbusScope is a free open-source cross-platform app for capturing and graphing Modbus data. In the past, I would capture Modbus data using Modpoll and hammer the output into CSV with sed, or use ModScan to capture CSV directly, and plot using using either DatPlot or spreadsheet software. However, thanks to Ben’s comment, ModbusScope is now my go-to for data logging and capture when I’m looking at three or fewer registers from up to three devices.
ModbusScope is a Qt app and coded in C++, and uses muparser (“fast math parser library”) and QCustomplot (“easy to use plotting widget for Qt”), with icons from Lucide.
Modbus Tester
Modbus Tester from Schneider Electric is a free proprietary Windows GUI program for reading Modbus registers, and supports Modbus RTU and TCP. I found “Tester” did what it claimed, but it didn’t do anything better than I was already doing with other software.
modpoll
modpoll from proconX is a command-line program for Windows and Linux. It supports Modbus ASCII, RTU and TCP, and is a de facto standard based on the number of references it has on the web.
proconX provides modpoll as reference software for their commercial driver libraries. Source is provided, but compiling requires a paid license for the libraries.
mbpoll
mbpoll is an open source (GPL-3) cross-platform command-line utility based on libmodbus (see Libraries). It supports Modbus RTU and TCP and is available in many (most?) Linux distributions. mbpoll conveniently uses similar output syntax and command options as modpoll, I use mbpoll on a Linux Mint test computer and the two are essentially interchangeable. Unfortunately, although mbpoll claims to be multiplatform, I haven’t found a pre-built Windows binary and have found building from source on Windows to be problematic (if you are building mbpoll on Windows, please submit a comment explaining your procedure).
QModMaster
QModMaster is a free open-source Qt-based Modbus master based on libmodbus (see Libraries below). QModMaster is licensed using the LGPL and includes a bus monitor for examining traffic on the bus.
A binary executable is available for Windows, but using on Linux will require compiling the from source using Qt Creator (which I was unable to do successfully, so on Linux I use ModbusScope or Scanbus-BR when I prefer GUI software).
RMMS
Radzio! Modbus Master Simulator (RMMS) is a free proprietary Windows utility (GUI) and claims to replace commercial ModScan and Modbus Poll utilities. It supports Modbus RTU and TCP, and multiple Modbus slave devices.
Scanbus-BR
Scanbus-BR is is a free cross-platform multi-lingual Modbus RTU and TCP GUI client (Windows and Linux, and Portuguese, Spanish and English). Rodrigo Hernandes created Scanbus to scratch his own itch and released it publicly to help others and as a demo to support his project development work (he is also a Brazilian, which presumably is the reason for the “- BR” suffix). I found the charting capability very handy (plotting up to six registers vs time), and having register values shown in integer, hex and binary simultaneously saved time by not having to convert or switch display formats.
Paid Client (Master) Simulators
Modbus Poll
Modbus Poll from modbus tools was designed to help developers of Modbus slave devices and others to test and simulate the Modbus protocol. Using a multiple document interface, several Modbus slaves and/or data areas can be monitored at the same time. US$129 per developer. The modbus tools website also has a good intro to Modbus.
ModScan
ModScan from WinTECH Software was developed to verify correct protocol operation in new or existing systems. ModScan supports an arbitrary number of queries, each with its own document window, and you can create your own custom windows and add content using the provided widgets (for example, using the trendline display shown below, which can plot up to four difference sources in one display). The data from each document window can be logged to its own data file.
Extensions provide third-party data acquisition using Control Automation routines or the MS Jet Database engine, and a debug mode displays raw serial data to and from a connected device. A single-user license cost US$65 when I last checked.
Simply Modbus Master
Simply Modbus Master (RTU and ASCII ). The Free mode allows six request messages before the application must be re-started. C$60. A slave simulator and TCP client are also available. The website has a nice intro to Modbus and Modbus Enron.
Free Server (Slave) Simulators
ModRSsim2
ModRSsim2 was forked from MOD_RSSIM and includes compiling on Visual Studio 2010. ModRSsim2 supports RS-232 and TCP/IP connections, the full range of Modbus addresses for all four Modbus types (0xxxxx, 1xxxx, 3xxxx, & 4xxxx addresses), as well as diagnostics with complete traffic byte capture and logging capability. ModRSsim2 supports CSV loading and a scripting environment for testing as well as HTML custom displays. It is free and open-source, and licensed under the GPL.
MOD_RSSIM
MOD_RSSIM is a Windows-based Modbus PLC Simulator (and parent of ModRSsim2). It is free and open-source, and started as a test program for a SCADA/HMI with Modbus RTU and TCP/IP. Typical uses are to verify device configuration, support development of Modbus master and slave drivers for embedded and desktop platforms, and as an educational tool to learn Modbus protocols.
pyModSlave
pyModSlave is a free and open-source Qt-based Python-code ModBus RTU and TCP slave from the developer of QModMaster. A Windows executable is provided and pyModSlave includes a bus monitor for examining all traffic on the bus. pyModSlave is licensed under the LGPL
UnSlave Modbus Slave Simulator
UnSlave Modbus Slave Simulator . UnSlave simulates any number of Modbus slaves. UnSlave is provided free from Unserver, possibly as a source of test data for Unserver’s Modbus REST API Server, which provides data from Modbus networks and devices to higher-level clients – and is monetized. The informative Complete Modbus Guide is also provided by Unserver.
Paid Server (Slave) Simulators
SimServe
SimServe by SCADAmatic can simulate Modbus ASCII, RTU, or TCP/IP. It provides a user interface for setting up a network topology of multiple devices simultaneously. The developer James brought it to my attention, and was kind enough to provide a guest key for evaluation. SimServe could be a valuable development aid if you are developing SCADA software and need simulated devices for testing, or if you are developing a device and could benefit from having a digital twin for comparison (assuming SimServe is capable of simulating your device).
WinModbus
WinModbus is a Modbus Slave Simulator for Windows. When I found it, the price was GBP62.50 which included lifetime support. A 14-day functional demo is available, and there is an attractive polished website.
Libraries
A number of Modbus libraries are available to leverage application development.
FreeMODBUS
FreeMODBUS is a free open-source implementation of the Modbus protocol with separate ASCII/RTU and TCP ports for a variety of embedded systems. I can recommend FreeMODBUS based on first-hand experience replacing a DIY protocol stack in an embedded industrial controller with an 8-bit MPU. FreeMODBUS is licensed using the BSD 3-clause license.
libmodbus
libmodbus is a free open-source library for Linux, Mac OS X, FreeBSD, QNX and Win32. The library is written in C, supports RTU (serial) and TCP (Ethernet) communications, and is licensed using the BSD 3-clause license. QModMaster, pyModSlave and mbpoll (reviewed above) use libmodbus.
Other Resources
Peter Chipkin has a nice list of Modbus-related tools on the CHIPKIN website, including their own CAS Modbus Scanner, which is handy for investigating the functions, coils and registers supported by a device.
com0com is a free open-source kernel-mode virtual serial port driver for Windows. An unlimited number of virtual COM port pairs can be created, and any pair can be used to connect one COM port based application to another. The module is signed with a test certificate, and requires configuring Windows to load test-signed boot modules.
I recently started working with a client on the final stages of a new product development project. The hardware design is based on a Microchip PIC24FJ1024GB610 microcontroller and firmware is being developed on a Microchip Explorer 16/32 development system until prototype hardware is fully tested. I have been working almost exclusively recently with the TI MSP432, and it’s been great fun familiarizing myself with Microchip’s 16-bit development environment.
Tutorials and demo applications are great sources of information, but are often from the perspective of a single developer, and brush over details such as source traceability and effective team development – often important within an enterprise to reduce risk and expedite time-to-market.
In this new series of blog posts, I will explore using the Microchip Library for Applications (MLA) as the basis of a new project, managing source files in a version control system (Git), sharing a source repository amongst a team using Dropbox, and finally integrating an application with the Microchip Easy Bootloader (EZBL).
Development Environment Summary
Windows 10 development workstation
GitExtensions 2.50.02
MPLAB v4.05 (necessary at this time to use Easy Bootloader)
MLA v2017_03_06
Microchip Explorer 16/32 development board with PIC24FJ1024GB610 PIM
Microchip provides the MLA (Microchip Library for Applications) which includes demo applications which can be used as the basis of a new project. Two important components of the new instrument’s functionality is to present an internal SD Card to a USB host as a Mass Storage Device (MSD), and to support in-field firmware updating.
Based on this functionality, it was appropriate to start with the MLA msd_sd_card_reader demo app, and integrate EZBL after getting the demo code running on the Explorer 16/32 development system, .
Unfortunately the MLA does not include a specific app for the Explorer 16/32 and PIC24FJ1024GB610, so I will have to adapt the Explorer 16 demo app for the PIC24FJ256GB210.
Copy the selected demo app to the ~\MPLABXProjects directory and rename it to something meaningful.
The project directory includes sources files and MPLABX project meta-data.
Now that there are files in the project it’s time to put it under version control. I will use Git for the project source file version control system (VCS), and have installed GitExtensions which integrates with Windows Explorer. MPLABX includes a built-in Git client which can be convenient but is less featured than GitExtensions. I’ll try to show the MPLABX Git client in a future post.
Start by using GitExtensions to create a working Git repo from the project directory.
Create a suitable .gitignore file so that Git will ignore files we don’t need to keep in the repo (generally the intermediate and debug compiler output). MPLABX project meta-data will be kept in the repo though, as it includes specifying which files the compiler is to use, the include path settings, the target processor, etc. The new project files are then committed to the repo.
The project won’t build yet though because I haven’t copied the MLA support files into the project yet. I’m going to simply copy the MLA framework\ and bsp\ directories into the project. Even though I likely won’ t need all the files, it’s convenient to have a complete and consistent MLA in the project as it will simplify use and maintenance.
The source file directories in the project properties must be configured for the new MLA location within the project directory structure.
The build configuration must also be updated. I created a new configuration by copying the existing build configuration, and renaming it according my target processor and set the new configuration active.
I also set the target Device to the PIC24FJ1024GB610, and picked the Explorer 16/32 development system in Hardware Tools.
I had hoped the project would build at this point, but at least not complain about missing files. This was not the case. Performing Clean and Build Project produced a torrent of missing files.
Investigating, I first found the build configuration includes specifying the “C include dirs” for the xc16-gcc compiler pre-processor, seemingly duplicating the project Source Directories. I made the preprocessing include directories the same as the Project Properties Source Folders set earlier.
I then noticed that files reported missing in the build output were not shown with a “!” in the project navigator, and they also didn’t have the expected “H” or “C” in their file icon.
I don’t understand why the files they weren’t found since I had corrected the include file settings. I had thought path settings were all relative to the project directory, but for some reason MPLABX expects the framework directory to be in the root of the drive, instead of the root of the project. Not sure what else to do, I individually removed each include and source file and then used “Add existing item” to re-add each file.
The project still doesn’t build, but now there are no errors due to missing files.
Now that all the files are found, I will commit the updated project to the Git repo.
In upcoming posts, I will fix the undeclared symbol errors, push my local dev repo to a Dropbox repo to share with others, and finally integrate the demo app with the Microchip Easy Bootloader.
For Followup
The correct use of include directory settings is still not clear to me. Manually removing and re-adding each source file would be extremely laborious and error prone in a significant project, and I am concerned I may have made the project non-portable in the process.
There is a note in the Getting Started document for the Microchip Libraries for Applications on this topic, which I need to explore in the future. Point 1 seems to imply though that at least the framework directory must be in the same location on each development system.
Project Include Path Settings
1. Path to the framework folder: In order for the projects to build, the include path up to the framework folder should be
provided for each build configuration and must be placed in the “Includes directories” list in the compiler properties for the
project. The framework module header files expect this. It is already done for the examples provided with MLA, but for the
customer specific project, this needs to be done.
2. Path to system_config.h: For each build configuration, the path to system_config.h needs to be provided.
3. Path to the application project src folder: The hardware independent code resides in the src folder for the application.
The path to the src folder needs to be provided for each build configuration.
For a project to be portable from one machine to another, it is recommended that the paths in the MPLAB X are relative,
while adding files to MPLAB X and while specifying include paths.
I recently purchased a BeagleBone Green (BBG) to experiment with FreeBSD on an embedded platform. The BBG has been available for a couple of years, and while I was tempted to get a BBG Wireless (BBGW), it would have meant ordering on-line and waiting for delivery. At least for initial development work I prefer a hard-wired connection, but also prefer to support local when possible.
BeagleBone Green
A BeagleBone Green (BBG) is a TI Sitara AM335x (1GHz ARM Cortex-A8 processor) with 512MB DDR3 and 4GB eMMC (which is the standard boot device), a micro SD socket (the alternate boot device and data storage memory), two USB connectors (one client and one host), ethernet, two Grove 4-pin connectors and two 46-pin 2×23 0.100″ pin headers. The original BeagleBoard emerged around 2010, and in 2013 was a winner in Embedded Computing Design’s “2013 Top Embedded Innovator award” in the Top Products Silicon category. The BeagleBone Black (BBB) was launched in 2013 as a lower-cost barebones BeagleBoard, and the BBG was launched in 2015 with two Grove connectors replacing the BBB’s HDMI connector.
Open-Source Hardware
A significant advantage of the BBG (and the other BeagleBoards and BeagleBones) for that the physical design (the schematics and pcb layout files) are provided under an open-source license. The BBG files are in a GitHub project using the MIT license. For someone designing a similar-but-different product, this can be a significant time saver. The openness reportedly continues to other technical details of the design, such as the low-level details of power management.
FreeBSD
The RaspBSD project provides pre-built images for the BBG. The project originally provided FreeBSD images for the Raspberry Pi, but has expanded their scope to include the BBG (and BBGW). Once I sorted out how to select the alternate boot device (to boot from the micro SD card I had copied the RaspBSD image to) everything started falling into place.
The RaspBSD image is based on Head, which is new for me as I’m running 10.3-RELEASE on my web server. However, I’m looking forward to experiencing life on the edge.
I’m not sure if this is correct, but it seemed to work consistently. To boot from the micro SD card instead of eMMC, disconnect power then hold down the switch beside the micro SD slot, apply power and continue holding the switch for a count of three. After some testing (and being sure I could re-load the bundled Ubuntu-based system if I wanted), I used the script provided with RaspBSD to copy the FreeBSD image to the eMMC. This significantly improved boot time and also freed up the micro SD card for data storage.
Conclusion
For me, the BBG is the superior single-board unix computer for basing a new product design on. The openly provided design files and technical documentation, as well as easy access to GPIOs and other hardware resources on the two pin headers, provide a significant head start compared to having to start from scratch.
