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