Third party Linux support incoming

[Garrett Stewart]

Before I start anything, I'd like to thank /u/modtdev on the new matter subreddit for his initial work getting gcode sent to the Mod-T on Linux using python.

Hello everyone!

This will be my first post here, and hopefully a relatively eventful one for some of the Mod-T community. Over the past couple of weeks I have started to work on implementing a fully fledged native Linux application for Mod-T support. I plan on releasing this application freely and completely open source on GitHub. To preface, I have two main intentions with this application; one to bring full usability of the Mod-T to Linux users around the world - with a second goal of providing a Raspberry Pi based touchscreen standalone interface for the Mod-T. The latter is a secondary goal, and I hope to eventually allow people to have different objects saved to the Raspberry Pi, as well as being able to select items from the store and add them to a local queue (instead of the store based queue) and send them directly to the Mod-T. 

Now that we all know my intentions, and what I've got planned - where are we at? What progress has been made?

Well, for starters, I've got most of the basic functionality of the New Matter desktop application wrapped into small command line utilities. These utilities will be the core on which the graphical application will build. These command line utilities so far include:

• Checking for firmware updates
  
• This works the same as the New Matter desktop application, it uses the same URL and authentication method to pull the exact same information
  
• I'm going to reach out to New Matter for approval on this, after all the web services are provided by them, and they may wish me to use a different authentication method
• Updating the firmware
• This also should work identically to the New Matter desktop application, first the printer is placed into DFU mode then the update is sent using dfu-util
• Failsafe is included in dfu-util, you won't be able to send an invalid firmware update to the printer, which should eliminate "bricks"
• Sending gcode to the printer
• This is yet another feature "stolen" from the New Matter desktop application, a few commands are sent to the printer via USB, and finally the gcode is "encoded" and then sent to the printer.
• To build on the new matter implementation, this should enable a user to send gcode files as prints are completed, instead of having to open the application every time and press the button
• Monitoring printer/print status
• This is done by "reading" the printer's output over USB. It returns a nice JSON formatted string giving me (and you!) tons of useful information:
  
• Current extruder temperature
• Print progress (percentage and current line, which could be used for rendering the current status of the print)
• Current Firmware version
• Serial number
• Uptime
• Total print duration
  
  

Right now not much of this is useful to anyone other than relatively advanced users. Sending gcode and updating the firmware is all usable stuff, as is querying the printer's current status. What remains is gathering that data and creating a useful interface for the end-user. So far the majority of things have been written in python since it enables easy access to the USB interface, but there is also some Bash involved. The end-user application on Linux will likely be either PyGTK or Bash based for my own ease (I am terrible at writing traditional GUI applications, perhaps someone interested can help?). For the Raspberry Pi distribution the interface will prefer the official Raspberry Pi 7" Touchscreen, and be rendered in HTML5. Communication between the HTML5 page and the various scripts for queue management and printer management will be done via Websockets and Websocketd. As far as pulling data to/from the store for the Raspberry Pi based interface, this will be something I'll need New Matter's approval and cooperation with - I can't go poking around their servers and pulling things without their permission, after all.

Anyways, I'm mostly posting this as an interest check. If you'd like to see the code, let me know!
I should be updating this post with a github link over the next week or so, once I feel comfortable with the usability of the scripts.

Thanks for reading

Garrett

[Henrik Sozzi]

Wow, great work, great idea! I would like to help you making the UI, if only I had time to do it :( I don't believe I'll find the needed time but in case... are your command line utilities portable to Windows as well? Could be nice to build a cross platform unofficial printer tool, with more advanced features. The UI could be built with .net (Mono on Linux). I'm a .net dev on Windows but I've had some experience with mono too and I have a basic knowledge of debian based distro like ubuntu, so... :)

But first we have to wait what New Matter will say about that. The whole thing is not open source, even if such a tool will greatly benefit the MOD-t userbase.

Let's see what happens :)

[Jonathan Mayer]

I've done some work with Python GUIs using Pygame on the Raspberry Pi.  I'm really interested in being able to make a small box that could be used to send prints directly to the printer using the Raspberry Pi touch screen kit.  Is there a github link to the project somewhere?

[Garrett Stewart]

Not quite yet, I need to make sure these scripts can't screw anything up. I'm interfacing with the printer directly via USB. They should be safe but I want to be 100% certain of this beforehand.

I've actually found a silly way for me to write a GUI for a daemonized version of these scripts:
Websocketd to host a webserver and provide access to the scripts in a CGI-manner and HTML5/CSS3/JavaScript for a WebGUI. Here's a sneak peak of some sillyness:
http://puu.sh/poA90/c160e7ff1d.mp4

[TheRik]

Any news on this?  I also would like to abandon the MOD-t desktop utility.

[Ashley Hooper]

This sounds like an excellent idea, has New Matter okay'd it? Because I could really use something like this.

[Garrett Stewart]

Sorry for the lack of updates, I ran into some technical difficulties but I think I've just about go things sorted out.
I'm going to first release all of the raw python scripts so other people can use them on their own and get to tinkering.

Past that, I'm continuing to work on the front-end for these scripts which will most likely be web based similar to new matter's website but hosted offline and managed by a single executable. It shouldn't be hard for anyone to get up and go with these scripts.

The last piece of the puzzle was obtained last night, which was filament load and unload scripts which I'm currently testing. I'm also working at dissecting the firmware updates but it's probably best to leave it to New Matter for firmware tinkering since I'll only be able to get bits and pieces from the whole picture there.

As far as being "okay'd" by New Matter it has not been _yet_. Basically that just means that we can't talk to the store. Which isn't a huge deal. The firmware update website is being accessed by one of the scripts but that shouldn't be a huge issue since you won't need to check for updates very frequently.

I'll be putting things on github as soon as they are all properly tested. I don't want to risk anyone bricking a printer due to something silly.

I might be asking New Matter for some insight as to why the gcode send script is occasionally erroring out instantly, requiring a printer reboot to send gcode.

Anyways, look forward to some updates soon

[Garrett Stewart]

Here's a github link for what I have so far:
https://github.com/Xaero252/Mod-T-Scripts.git
Have a look, fork do whatever
Thanks

Garrett

On Tuesday, June 7, 2016 at 1:03:53 PM UTC-6, Garrett Stewart wrote:

[r.d. terramir]

I looked through your git hub repository i am wondering if we could use the for octoprint compatiblity?
One thing that concerns me is the seeming limit on the size of the g-code. Seems like your script is limited to 20* 5120 bytes I have seen g-code that is bigger than 100 kbytes but maybe I am misinterpreting your code I am not good with python. We would not really need the dfu and firmware functionality that urgently just the ability to load / unload filament and the ability to send the g-code and monitor print status so we could use octoprint to load the files over our Network / the web so peeps would not need their laptops connected to the mod-t just a cheap pi hell since the print would not be fed by octoprint but stored in the mod-t we could even use a pi0w if we wanted too.
Pi0wireless causes stuttering on regular print situations.
terramir

terramir