Using Duro PLM

I’m excited to be using Duro PLM for a new client. Duro is an exciting new cloud PLM and I was fortunate to have the company founder give me a tour of Duro just before Christmas. I will be posting about my experiences once I get my feet wet.

I also hope to compare using Duro to ERPNext for stabilizing and consolidating sub-assembly engineering BOMs (bill of materials) to create the top-level hierarchical BOMs for product SKUs, and for transfer to a CM (contract manufacturer).

Install ERPNext on FreeBSD 11.2 using VirtualBox

Search for other ERPNext-related posts. You may also visit the demo on

The simplest way to “install” ERPNext on FreeBSD is to simply use the Virtual Image provided by the ERPNext project with VirtualBox.

The ERPNext project provides the Easy Install script for bare-metal installation but it has a number of Linux dependencies and will not work without changes on FreeBSD. Happily, the project also provides a fully configured virtual machine (based on Ubuntu Linux).

It may also be possible to use bhyve, the BSD hypervisor, with the virtual image, but the OVF file must first be converted to bhyve’s raw format.

Install VirtualBox

Install the virtualbox-ose-nox11 package for running headless virtual machines.

% sudo pkg install virtualbox-ose-nox11

The VirtualBox kernel module (virtualbox-ose-kmod) will also be installed, but it must be re-compiled from source and re-installed (at the very least, the system will crash when next re-booted once it has been configured to load the kernel module at boot). 

Update the ports collection to prepare for compiling the kernel module. 

# portsnap fetch update

If the ports collection has not been installed, install.

# portsnap fetch extract

The FreeBSD sources are required to compile the kernel module. If not already installed, install the FreeBSD sources.

% fetch % tar -C / -xzvf src.txz

Compile and install the virtualbox-ose-kmod port. Make will first refuse to install the module because it is already installed (recall it was installed by being a dependency of virtualbox-ose-nox11). De-install the virtualbox-ose-kmod package, then re-install the newly compiled version.

% cd /usr/ports/emulators/virtualbox-ose-kmod
% sudo make
% sudo make install
% sudo make deinstall
% sudo make reinstall

Perform post-install configuration.

1) edit /boot/loader.conf to load the vboxdrv kernel module at boot,

# vi /boot/loader.conf

2) increase AIO limits by editing /etc/sysctl.conf (my server is using AIO, for more information refer to the virtualbox-ose-nox11 pkg-message).


Reboot the system to load the kernel module (or load it manually).

Make a mental note before doing an OS update to first edit /boot/loader.conf to not load the module. Otherwise the system will likely crash when next rebooted.

The user that VirtualBox runs as must be a member of the vboxusers group. For simplicity, I’ll run VirtualBox using my own username, although best practise would be to create a dedicated user.

# pw groupmod vboxusers -m dale

Edit /etc/rc.conf to run vboxwebsrv (the Virtual Box web interface daemon) using the provided startup script installed in /usr/local/etc/rc.d/

% sudo vi /etc/rc.conf


and finally start the vboxwebsrv service.

% sudo service vboxwebsrv start
% sudo service vboxwebsrv status

The vboxmanage cli utility can be used to manage virtual machines but I will be using phpVirtualBox which provides a familiar GUI.

Install phpVirtualBox

phpVirtualBox can be installed from the FreeBSD ports collection but it currently has a dependency on PHP 7.1 while I have PHP 7.2. I installed phpVirtualBox manually to avoid pkg attempting to revert my PHP install to 7.1, and have not encountered any issues.

Download the latest release from the phpVirtualBox Github project . Follow the instructions in file and on the wiki. Extract the project to /usr/local/www, and edit the configuration.

# vi /usr/local/www/phpvirtualbox/config.php

var $username = 'dale';
var $password = 'dale_login_password';

Configure the webserver to serve phpVirtualBox. I’m using the basic Apache 2.4 http server package. I added a virtual host definition to /usr/local/etc/apache24/extra/httpd-vhosts.conf to serve phpvirtualbox as a

  DocumentRoot "/usr/local/www/phpvirtualbox"
  <Directory "/usr/local/www/phpvirtualbox">
    allow from all
    Options None
    Require all granted

Change the default phpVirtualBox login password to something secure after logging in for the first time.

“Install” ERPNext

Download the desired ERPNext Virtual Machine image (*.ova).

% cd ~/downloads
% wget

Using phpVirtualBox, create a new vm by importing the downloaded ERPNext-Production.ova Virtual Image file (File/Import). The OVF includes port forwarding rules to forward client port 80 to host port 8080 (for serving ERPNext) and a rule to forward ssh from client port 22 to host port 3022 (for system administration).

Start the vm and then login to ERPNext from a browser (e.g. using the default credentials. The new site wizard will run and lead you through ERPNext configuration. Use a secure password when defining the initial (admin) user, and the wizard will delete the initial Administrator user (with default password) when complete. 

Once logged into ERPNext, setup email processing so that users will receive notifications outside of ERPNext. This will be valuable to understanding and appreciating ERPNext’s significant social aspect. You will also want to change the system login (i.e. ssh) password for “frappe” user to something secure (or disable password authentication entirely in favor of key-based authentication).



Modbus Master and Slave Simulators

I needed to learn about Modbus recently, I don’t know it has eluded me for so long living in SCADA-rich Oil and Gas country.

Modbus is a communication protocol for industrial devices developed in 1979 by Modicon, now Schneider Electric. It was originally designed for communicating with programmable logic controllers (PLCs), but has since become popular for industrial sensors and instruments in general., a U.S. non-profit trade association, now controls the Modbus protocol and provides free access to protocol specifications and technical resources.  

When developing a device which will communicate using Modbus, there may be value in using a master controller or a slave device simulator, or make use of readily-available utility software and libraries.

Master Simulators

A Modbus Master simulator is used to query data from devices and can be a valuable test when developing a Modbus Slave device. A large number of Master simulators are readily available, including free of charge, open source, and commercial software.


QModMaster is a free and open-source Qt-based ModBus master application based on libmodbus (see Libraries below). QModMaster is licensed using the LGPL and includes a bus monitor for examining all traffic on the bus. 

Modbus Tester from Schneider Electric is a free proprietary Windows executable for reading Modbus registers. It supports Modbus RTU and TCP.

Modpoll Modbus Master Simulator from proconX is a free proprietary Windows command-line utility and supports Modbus RTU and TCP. Modpoll is a demonstration utility for proconX’s commercial driver libraries. 

Radzio! Modbus Master Simulator (RMMS).  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. 


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.

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.

ModScan32 from WinTECH Software is a was developed to verify correct protocol operation in new or existing systems. Extensions provide third-party data acquisition using Control Automation routines or the MS Jet Database engine.  A debug mode displays raw serial data to and from a connected device, and ModScan32 can execute test scripts with stimulus messages and expected responses for production testing. Single user license US$64.95. WinTech also provide a number of other Modbus-related utilities. 

Slave Simulators

A Slave simulator provides a source of data for a Modbus Master, and can be useful as a known source of data when setting up a test workflow for a device being developed. A Slave simulator can also be used to create a model of a new device being developed, and act as both the development specification and a source of expected behavior for validating the device being developed.


ModRSsim2 was forked from MOD_RSSIM and seems to be the more active of the two now with a number of updates including 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.

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

MOD_RSSIM is a Windows-based Modbus PLC Simulator (and basis of ModRSsim2 above). 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. 


WinModbus ( Modbus Slave Simulator for Windows. GBP62.50. Lifetime support. 14-day functional demo for evaluation. Polished website.

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 Unserver website includes a nice Complete Modbus Guide.


A number of Modbus libraries are available.

FreeMODBUS is a free implementation of the Modbus protocol with separate ASCII/RTU and TCP ports for a variety of embedded systems. FreeMODBUS is licensed using the BSD 3-clause license. 

libmodbus is a 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. 

Other Resources

Peter Chipkin has a nice list of various Modbus-related tools.

com0com is a 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.

Microchip PIC24F Development using MLA, EZBL, Git and Dropbox – Part 1

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
  • MikroElektronika microSD click (mikroBUS™ microSD Card module)

Create new MPLABX project

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.

(Getting Started, Microchip Libraries for Applications. (c) 2013 Microchip. help_mla_getting_started.pdf, page 11.)