Lasercut -- Possible interventions

Created by: gwideman, Aug 13, 2012 5:41 pm
Revised by: gwideman, Sep 21, 2012 11:11 pm (6 revisions)

Overview

This page summarizes current thoughts regarding the question that originally prompted this study: What possibilities are there to take control of an MPC6515-based laser cutter from custom software, such as an alternative pipeline or driver?

Possible points of intervention

The figure below sketches the steps in Lasercut's process from drawing to laser cutter, and indicates where interventions might be attempted.Lasercut_intervene.png
  • Point A simply corresponds to a custom app supplying drawing data that can be imported into PrintDriver (or Lasercut). To start to carry out the rest of the process the custom app would invoke PrintDriver via COM (point B), just like the CorelDRAW addin VBA code.
  • However, at this juncture, PrintDriver's UI would require the user to enter information, primarily the association of color to laser speed and power. To avoid that...
  • ...it may be possible to avoid user interaction by driving PrintDriver's UI via Windows API messages (Point C). This kind of approach is sometimes tricky to get working well, and obviously is brittle in the face of updates to PrintDriver. On the positive side, intervening this far upstream avoids having to figure out the details of the downstream file formats
  • Intervening instead at point D would bypass PrintDriver and its UI, (and I think the dongle check). In this case the custom app would need to be able to produce .TXT files containing settings and commands just like PrintDriver does. Then compile these and send them to the cutter by calling mpc05ls.dll. These settings and commands are not documented, so would require considerable experimentation using Lasercut to produce sample .TXT files to detemine the complete vocabulary and how to use it.
    • The ReLaserSoftware project has made some initial progress on this.
    • Additional identification of the .TXT settings and commands could be gained by tracing the mpc05ls.dll functions called during compile of those .TXT files, such as this ReLaserSoftware example. Such an investigation can be performed on the demo version of Lasercut.
  • In a similar vein, instead of providing .TXT files to be compiled, the custom app could generate a .MOL file by calling the individual mpc05ls.dll functions directly (point E). The functions have understandable names, and once the overall pattern of calls is understood from trace examples, this might be easier to master than figuring out the .TXT command vocabulary. Again, such an investigation can be performed on the demo version of Lasercut.
  • Point F symbolizes a custom application able to generate .MOL files directly, then using CommM05.dll (directly or through mpc05ls.dll) to send these over USB to the cuttter. This approach would require understanding the binary instructions that the MPC 6515 obeys. At the moment, it seems not to be publicly known how complex these instructions might be. Are they simply binary encoding of relatively high-level commands, such as "move to location X,Y", or do they include detailed lower-level code for the MPC 6515 and FPGA to execute?
    • The ReLaserSoftware project made a start at this line of investigation, but is far from complete, and work seems to have stalled:
    • More traction might be gained on the investigation of .MOL files by using a test program which would call just a few mpc05ls.dll's functions to produce very minimal .MOL output files that are perhaps easier to examine.
  • Point G is more or less the same strategy as Point F, except that it bypasses all Lasercut proprietary software altogether. In addition to the research required for Point F, Point G would require also working out the USB protocol(s) used. (In theory, one could dispense with EZUSB.dll as well, requiring further research, but there is little point since EZUSB is freely obtainable. Conceivably a fully generic solution might be valuable for porting to other OSes.)

Conclusions

None of the options presented is the clear winner. Each has its advantages and disadvantages, and none is particularly easy.
In my view, because they are the most upstream points that avoid user interaction, Points D or E are the most practical points at which to intervene. In particular, the research into either the .TXT settings and commands and/or the corresponding mpc05ls.dll functions looks more feasible than trying to understand details of the .MOL format. Additionally, the set of commands or mpc05ls.dll functions is likely more stable across versions than the .MOL file content.
That said, there's no question that this could be a tedious endeavor, which bolsters the argument for replacing the MPC 6515, with, for example, the LAOS card. As an aid to that line of thinking, the listing of mpc05ls.dll's functions provides a useful baseline for assessing candidate replacement cards.