I took the "build-benchmark-v1-0.stl" file found in the distribution of RepRap I had on my machine (reprap-mendel-20100105), ran the java RepRap console, loaded it using the "Load STL" file, selected to send the GCodes to file, and clicked print (I did not change any preferences from the default.)
It got thru the first 53 layers, and appears to have hung at layer 2 (2/55) It took ~5 minutes to get to this point, it has now been running for about 25 minutes. -- I pressed stop, and exit.
It still generated a large GCode file: 4,482,904 bytes in size.
It had gcode commands for:
G1, G4, G21, G28, G90, G92, M104, M106, M107, M108, M109, and T0.
According to the mendel user guide, this means this 'test' lacks confirmation of the following additional codes that are documented:
G0, G20, G91, M110, M111, M113, M114, M126, and M127
Of those missing, The only ones I might be concerned with 'missing' might be:
G20, G91, M113, M126, and M127.
I don't believe this is a suitable 'gcode' test; certainly, the STL -> printed part is definitely worth having in a battery of tests, but this particular "test" seems more suited for end to end testing and general printer effectiveness; while certainly a nice thing to have, I don't think I'm at the stage to be able to utilize it -- I need something that I can use to unit test my gcode compiler.
As there has been not much recommendation, I may create a suite of much shorter tests, consisting of 40-50 or so gcode commands.. perhaps some simple geometric shapes, draw layer by layer but using different techniques to generate the same geometry (I.E inches one layer, mm another, absolute on layer, relative another, etc.) This could then be used to verify 1 - correct implementation of a new gcode interpreter, 2 - printer axis accuracy and repeatibility for all the supported gcodes. I think a test for extrusion rate could also be evaluated by setting extrusion rate, and measuring the overall weight or volume of the printed artifact... Has anyone tried this before? Any suggestions? Is something like this going to have enough accuracy to be useful as a measurement for hardware and/or software control?
If anyone has really good experience with GCode, I would appreciate any advice or help, or references to existing gcode test files that I might be able to leverage. I only read the NC standard the other day as I've been implementing the compiler -- My vision is to transmit a semi-byte code encoding to the firmware that encodes all control as a sequence of cubic polynomials; this is more useful for 3rd order motion control (limiting jerk as well as acceleration and velocity), as well as the more powerful notation usable for non-linear motion required by polar axes. On this -- if I understand feedrate correctly, I will be able to ignore feedrate completely, correct? This simply encodes how fast the tool should follow the path given by a gcode? I plan on tuning the motion with my own set of parameters to define the exact limits for velocity, acceleration, and jerk for each of the various controls. Still, there might be some utility in having a 'feedrate' test -- could you not measure the time it takes to build a specific path, and therefore validate feedrate?
Does anyone have any further suggestions for a test suite suitable for testing out any of the various gcode modules that currently exist as well as those that may exist in the future? I understand that there are some hardware dependancies, such as 3D vs 5D, but I believe these can be identified in a comment block, and assuming we hand code the gcode files, it should be possible to write them in a way such that one could adapt it to suit the particular hardware or software being tested? (Any thoughts on that might be good to hear, too.)
