#1026 - The Blacklist

The gcode uppercase blacklist needs to store the gcodes the user does not want to uppercase. This means that the file storing the blacklist needs to be configurable. The question is where is this file? I'm not finding any database files, and the only .yaml file is the default.profile.yaml file, so I'm guessing that's what I need. The plan is to use the blacklist to filter gcode commands that the user types into the terminal. My thought is that this filtering process needs to be done in the terminal.js file. This sendCommand function in terminal.js appears to filter and format commands before sending them to the printer -

Still working on figuring out the thread of execution through these files, but things are starting to come together.

#1026 Analysis

Fixing issue #1026 is going to require adding a new section in the serial connection tab in settings for a configurable blacklist of gcodes to not uppercase. This blacklist needs to be stored in the settings.py file, talk to the settings.js file, and have a front end widget in the serialconnection.jinja file. We will also need to add a function to match the gcodes inputted by the user against the gcodes in the blacklist. This function may need to be located in the gcodeinterpreter.py file.

Issue #1026

The team has momentarily split up. We had an unproductive number of people working on issue #1149, so I am now working on issue #1026. The problem issue #1026 addresses is that some gcode command parameters sent by the user via the terminal need to be uppercase and others not. Currently, the user needs to know what to uppercase and what to lowercase. The request is to make these commands and their parameters not case sensitive. The solution discussed by the community is to make a configurable list of gcodes to not uppercase.

OctoPrint - First Bug

As of now I am working with two of my fellow CSC486 class mates on the OctoPrint project - Kye Hoover and Ishwar Agarwal. Our first bug fix for OctoPrint is bug #1149. This issue is a request for arrow buttons next to the print object layer slider bar. The layer slider bar allows the user to scroll through the layers of an object the user wants to print. The problem is that this interface does not work well when incrementing one layer at a time. Arrow buttons would give this ability to the user. Additionally, key bindings to the incrementing function were requested.

At first glance the code for the slider bar appears to be contained in three files - bootstrap-slider.js, gcodeviewer.jinja2, and gcode.js. The jinja file holds the HTML for the slider bar which has a function in the gcode.js file which calls the slider class in the bootstrap file. Our team is still in the brain storming solutions stage, so my next post will be on what we've come up with.

OctoPrint - Setting Up & Getting Ready

Installing OctoPrint for development is very straight forward. The process comes down to cloning the repo, setting up a virtual environment in the developer's branch, and starting the server. A friend of mine has the detailed instructions on his blog so being the friend that I am I will just leave a link to his post here -

https://hooverkblog.wordpress.com/2016/03/21/octoprint-development-setup/

My next step is to complete the developer tutorials and then hopefully find an interesting bug to fix or plugin to write. For those interested, the link to the developer tutorials is given here -

http://docs.octoprint.org/en/master/plugins/gettingstarted.html

OctoPrint

I'm switching gears from OpenMRS to OctoPrint - http://octoprint.org. OctoPrint is host software for 3D printers. It is a smaller FOSS project than OpenMRS and the community response time has a better track record. What makes OctoPrint an especially interesting project to me is that it is written partly in python and uses flask for it's web development (a language and web development tool that I am both very familiar with). My next will post will cover the installment procedures.

Dropping OpenMRS

I've decided to drop the OpenMRS project. My two biggest issues with the project were the setup and the community's communication. The problem with the developers' setup is that there are many different ways to setup OpenMRS and some of these methods are outdated. The documentation for setting up is incomplete, which led me into issues I didn't know how to fix. Several weeks in I found success in launching a local instance of the reference application using vagrant -

https://wiki.openmrs.org/display/docs/Developer+How-To+Launch+a+Local+Instance+of+the+Reference+Application

A friend also working on, and struggling with, setting up OpenMRS showed me this after communicating with the main contributor of the project. This method works very well, but it is not mentioned on the developer's setup page. All this is just to say that the online documentation seems to be outdated.

Finding issues to work on didn't appear difficult at first. The issues tracker made it easy categorize and find issues. The problem I ran into was the documentation on most issues and lack of communication from the community on the specifics of the issues.

The OpenMRS project is a great cause, and I would encourage experienced open source developers to join the effort. However, for a novice FOSS engineer this project was just too much hassle.