Listed below are some initial observations about the Maslow firmware, and features I would like to see eventually.
The intent of this thread is to start a community discussion that clarifies the direction in which the community would like the firmware to go, so please add to the list if there is something you want. Including a use case generally helps people understand why you want a specific feature and lets people consider whether there is a better way to achieve the goal than the feature proposed.
Currently I see 73 forks. So people are working on modifying the code. If we can get on the same page, we will minimize duplication of effort and maximize contributions back to the public project.
-
First and foremost, endless appreciation to the original and subsequent code authors that created a thoughtful solution that really WORKS!
-
[quote=āMeticulousMaynard, post:131, topic:3319ā]
Do we know where the setting in the firmware is to enable them? I just took a quick look through the firmware but thereās so much to it now that itās like looking for a needle in a haystack.
[/quote]
Program flow and configuration options are unnecessarily complex and under commented. A flowchart, or general description of program flow would be helpful until the following changes can be implemented. Comments at the top of a header file should describe the logical intent of the file. If the contents do not lend themselves to a concise description, perhaps the contents are better located somewhere else. -
The first file a person will look at is the one and only .ino file, currently called cnc_ctrl_v1.ino. Why not simply Maslow.ino? Version info should be in the opening comment and within VCS (git).
-
A valid reason to include a file which does nothing except include other files is if that set of included files represents one of several different configurations. maslow.h is not that, however, maslowRing.h, maslowLink.h, maslowDueEthernetQuartersheetParallelogramSpeedcontrolSharpieLaserProgramtoolpath.h as mutually exclusive files could be useful in selecting only the specific files and #defines required for the desired feature set and target arduino.
-
.ino should directly contain the highest level global #define statements such as debug verbosity, version, machine ID(name).
-
It should be possible from .ino file alone, to determine all arduino pins which will be used in the project.
#define SOME_PIN 1
static const int X_PIN = 1;
// someclassfile.h someclass.begin(int x_pin, int y_pin, char* something);
someclass.begin(1, 2, āfredā);
// if not otherwise obvious, a comment helps.
// otherfile.h uses pin 0 for Rx, 1 for Tx, and 13 for onboard LED -
.ino should directly include any libraries under different source control, to keep them current.
// https://github.com/PaulStoffregen/Encoder
#include Encoder.h -
Do not modify external libraries without a darn good reason. The published external code is extensively tested and debugged. It already works. Try not to break it.
-
If you have a darn good reason, submit an issue or pull request to the original author to benefit the wider community. I know for a fact that PaulStoffregen works very hard to keep his libraries compatible with a wide range of Arduino hardware. If something as popular as Maslow requires a modification of his library, chances are he will be receptive to updating his source, or showing you a better way to use his libraries to accomplish the same thing.
-
Arduino compatibility. There is nothing special about Maslow that requires it to run on any specific arduino, yet the code is written in a narrow way that prohibits using anything but the Mega. Take advantage of the Arduino hardware abstraction layer to maintain compatibility with a wide variety of hardware. A target specific include file can bring in any native code required for the chosen target. Example: timer1 setup for Mega vs PIT for arm based micros.
-
Compatibility with external hardware and software need not require having the external hardware or software. Ground control is great, but some jobs could run just from the arduino program.
Example1: #ifdef PROGRAMTOOLPATH_NC //Programtoolpath.nc file exists, so record this toolpath in program flash to become machineās default toolpath, run at the touch of a button. Good for a dedicated mass production oriented machine. Cut the maximum number of 5" square shapes that will fit a full sheet. No host required.
Example2: dialAcut Coded Rotary Switch selects which of several programs to run from an attached SD card.
Example3: Self test. When button is pressed, Move to top left of workpiece, pen down, alternately command takeup 1 encoder count from right motor, pause for settling, then release 1 encoder count from left motor, pause for settling, repeat. When encoder count near edge of work is reached, pen up. Repeat for remaining corners. Resulting plot is edge case limit of precision test. This is theoretically the most precise line segment Maslow could ever draw. Now draw a very large rectangle on the workpiece 1 inch in from the edge. This test is for accuracy. Variance from 1" distance, straightness of line, angle of line are error. Change pen color(transparent highlighter?), continue program which starts at end points of previous tests and reverses path. Difference in position of ink colors represents repeatability error plotted over entire workpiece. No G code required, no host, no router even.
- It would be helpful if the .ino file describes the overall program flow. That means(as far as practical) any calls to functions in included files should come from .ino, NOT from other included files. Once program flow enters those include files and starts ping ponging around it becomes very difficult for a human to follow.
