#1026 - Conclusion

Our implementation was a success! We've changed the necessary documentation and made a pull request. Time for a quick reflection - this was harder than I thought it would be! I've worked with server projects before and I've implemented much more difficult features in software, but doing these things with code written by someone else and in a project this large has turned out to be a real struggle. Tracing the thread of execution, understanding the original contributor's logic, and learning the tools she used was altogether a laborious process. It's because of this though that I am glad I took on this project. There is little doubt in my mind that I'll will encounter this kind of work in professional settings in the future.

#1026 - sendCommand()

The request for this issue was to check the terminal command sent by the user against the blacklist and uppercase the input if it is not in the blacklist. To implement this request we first retrieved the blacklist from the front end in the settings.js file. The terminal.js file holds the sendCommand() function which, as one would imagine, sends the terminal command sent by the user. This function automatically uppercases the first g-code command, and leaves the following parameters the way they are.

For example, if the user types,

  m33 p0

into the terminal, the sendCommand function sends,

  M33 p0

to the printer. The problem with this, the heart of the #1026 issue, is that there are g-codes whose parameters need to be capitalized. This would be easy to fix if it weren't for the g-code commands whose parameters need to not be capitalized (which is of course where the blacklist comes in to play). Our solution was to keep the previous implementation of the sendCommand function, but add a conditional statement which uppercases the command and parameters if the command is in the black list.

 For example, if the user sends the command,

  m117 Hello world

with M117 in the blacklist, the printer will receive,

  M117 Hello world

and any command not in the blacklist will have capitalized parameters.

#1026 - Back End Implementation

The settings.py file in the api folder calls the set and get functions in the settings.py file in the octoprint folder to write and retrieve the new settings data in the back end in the form of dictionaries in the settings.py file in the octoprint folder. This is the standard method OctoPrint uses to store and get their settings data so this is what we used to create the auto-uppercase blacklist:

Calling the set function on the blacklist ...

Calling the get function on the blacklist ...

The back end dictionary for the settings data ...






















The only default command for the autoUppercaseBlacklist is M117. This command is used for sending dialog to the console. Putting this command in the uppercase blacklist ensures that the dialog proceeding the command is not uppercased.

#1026 - Front End Implementation

As mentioned in the previous post, the front end of the blacklist resides in the serialconnection.jinja and settings.js files. We went with the same div elements as the 'Long running commands' and 'Commands that always require a checksum' input boxes in our implementation.



The settings.js file creates a json of the user inputted settings,



and sends that information to the settings.py file in the api folder.

#1026 - Progress

All of the necessary files and the thread of communication between them have been established. The html for the settings interface where the blacklist can be updated is in the serialconnection.jinja file. It will be placed in the advanced settings tab using a text input box. This jinja file works in conjunction with the settings.js file in the front end. The settings.js file calls python set functions in the settings.py file in the api folder and passes information inputted from the user when the save button is clicked.

This python file sends the updated information to the settings.py file in the octoprint folder, where it is stored in a dictionary of user settings. Finally, the data from python settings dictionary is written to the config_yaml.rst file.

#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.

Communication

This post is a quick self-reflection on my communication skills and deficiencies. Communication is important in any FOSS project, especially in project as big as OpenMRS. I would say when it comes to communication I am friendly, to the point, and cooperative. I often get along well with team members in coding projects. I think programmers are generally easy to get along with. Where I struggle in communication is dealing with people who don't know what they don't know. I try to be clear and honest with people when I think they are out of line, but I struggle with assertiveness towards overly assertive people. Ideally, it would be nice if every coworker I ever work with was honest and clear about what he/she doesn't know or is unclear about, but I know this is not going to be the case. As it is, I need to work on my confrontation skills.

Class Contract

The purpose of this post is to discuss the contract, regarding peer collaboration, constructed by the professor and students of the CSC486 class. If I could sum up the contract we came up with in my own words I'd say it boiled down to 6 obligations:

1. Effective communication

2. Quality contribution

3. Organized documentation

4. Organized workflow

5. Supportive teamwork

6. Clear goals

As discussed in class, the theme of these obligations is finding the right balance between experience and product. Personally, think the emphasis in this class should be on the product, and as such I think there should be more weight on obligations 2, 3, 4 and 6. Communication and teamwork are important, but in a class of upperclassmen I think a deficiency in these areas is more easily spotted and righted than a deficiency in product. If a student has a complaint about let's say, someone in his/her team contributing too much or too little, he/she is capable of resolving the problem right then and there and should do so as he/she would in the workplace. In the case of project output, however, spotting deficiency is deceptive. How does a team know which aspects of the project need more attention? Do they know what their end product looks like and are they on the right path to achieve it? I think these questions are trickier than how to resolve teamwork issues, and more grading emphasis should be given to them and questions like them.

Welcome to My FOSS Blog

Welcome! The purpose of this blog is to post research and updates on FOSS (Free Open Source Software) projects that interest me or that I am contributing to. This is for a class (Software Engineering) that I am taking at Berea College, and will hopefully carry on beyond my academic career.

To kick things off - a project of interest: http://openmrs.org 

OpenMRS is a technology platform for medical care in remote locations. This project is open source (of course) and well communitized, which is appealing. What's really attractive about this project, however, is the range of project possibilities. There are many options of varying difficulty which means there is something for everyone, even for a noob programmer like me. As of January 20th, 2016, there were 22 introductory projects ready to be picked up - 

https://issues.openmrs.org/browse/TRUNK-1861?filter=10068

Hopefully by my next post I will have decided on what I am doing (probably an OpenMRS project), and that will be the topic of discussion.