I had the opportunity to present on the main auditorium of Unitec, a private, technical university. The audience of the congress was compromised mostly of professionals and students from Central America. Local and National media also covered the event.
Hello, during the last weeks we have been working on Knitlib and Knitpat, a knitting machine control library and a standardized format that allows for exchange and storage of patterns.
In order to achieve a common platform for knitting machine development we have the need to abstract away implementation details that can difficult the generic usage of the lib, while keeping extensible and powerful control features. Among the most important abstractions developed for Knitlib is the Knitting Machine Finite State Machine, an abstract representation of the procedures needed to operate a knitting machine.
BaseKnittingPlugin, the basis of knitlib’s machine knitting controller plugins.
The architecture of Knitlib allows for easy integration of different knitting machine plugins for varied use cases, hardware, and software protocols. All functions of the plugin are non blocking except for .knit(), which is blocking due to the physical interaction needed in order to execute this command. To ease usage and to enable more versatile behaviour from the .knit() function, without limiting the interaction facilities needed for operation, the callback infrastructure allows for blocking and non-blocking callbacks from the Plugin to the machine operator (the Knitlib client), such as Information, Warnings, Error Notifications or Mechanical Required Actions (moving spools, switches, needles, etc). Callbacks abstract away the notification and interaction paradigms from the plugin, allowing for simpler behaviour, a more elegant design and ease of testing. Callbacks also allow for future plugins to not take care into implementing user interfaces, but to focus on functionality.
The pending remaining challenge is to standardize configuration options, flags and settings in order to allow for UI that respond to each plugin requirements and options, and to specify which features are supported on each machine plugin. Insofar, most of the standardization has been done on Knitpat, but some specifications such as physical resource assignation (Serial Ports, input streams, etc) are still to be implemented soon.
Thank you, and I hope this article helps you to understand the software architecture and design patterns of the implementation of Knitlib.
Hello everyone, my name is Sebastian Oliva. I am a developer from Guatemala and part of the team of students currently in Google Summer of Code ’15 working on Fashiontec. During last year’s GSoC I built a GUI interface for the AYAB project, allowing for easier control for knitting machines supported by AYAB (Brother KH-930, KH-910).
Currently I am working on developing a knitting machine abstraction library and JSON based knitting file format that can enable the use of a single API to control a varied number of knitting machines. A knitting machine library allows us to create even more advanced software to control and operate machines, while a standardized and open format for knitting patterns allows us to create pattern collections such as the common pattern books usually shared by knitting communities, as well as enabling pattern editors and ecosystem.
Currently I am:
Working on designing and implementing Knitlib’s API design.
Writing tests for Knitlib’s desired behaviour.
Starting work on defining Knitpat, the open knitting file format.
I hope that this year’s GSoC brings a lot of advances to the machine knitting community, and I am happy to be a part of it.
You must be logged in to post a comment.