Project:RELaserSoftware: Difference between revisions
No edit summary |
|||
Line 17: | Line 17: | ||
* [http://wenku.baidu.com/view/1af68b3283c4bb4cf7ecd15f.html Documentation for the MPC03] (previous version, we're MPC05) with .ini file info | * [http://wenku.baidu.com/view/1af68b3283c4bb4cf7ecd15f.html Documentation for the MPC03] (previous version, we're MPC05) with .ini file info | ||
* [http://focus.ti.com/docs/prod/folders/print/tms320vc33.html DSP chip] and [http://focus.ti.com/docs/toolsw/folders/print/c3xfreetool.html compiler]. [http://www.google.com/search?q=TMS320C31 See also], [http://www.elec.canterbury.ac.nz/c4x/ GDB toolchain]. These chips are end-of-line, but were supported by GCC up to [http://gcc.gnu.org/gcc-4.3/changes.html 4.2]. | * [http://focus.ti.com/docs/prod/folders/print/tms320vc33.html DSP chip] and [http://focus.ti.com/docs/toolsw/folders/print/c3xfreetool.html compiler]. [http://www.google.com/search?q=TMS320C31 See also], [http://www.elec.canterbury.ac.nz/c4x/ GDB toolchain]. These chips are end-of-line, but were supported by GCC up to [http://gcc.gnu.org/gcc-4.3/changes.html 4.2]. | ||
== Current State of work == | |||
* We have some knowledge of the ,mol format | |||
* We have a TXT to mol compiler based on a dll. (windows only) | |||
* We have a TXT parser/generator using python and construct | |||
== Currently to do == | |||
* Figure out DXFs - A [http://pypi.python.org/pypi/DXF-Converter/1.0/ python to dxf to pdf converter] might be useful. I've not found a stand alone parser. | |||
* Figure out which parts of the TXT file correspond to which function calls, so we know how to generate meaningful TXT files. | |||
* More work on .Mol files? | |||
==Current Repo== | ==Current Repo== | ||
Line 42: | Line 56: | ||
[[Projects/RELaserSoftware/Compilation traces]] | [[Projects/RELaserSoftware/Compilation traces]] | ||
==USB== | ==USB== |
Revision as of 21:16, 19 January 2011
Reverse Engineering Laser Software
The laser software by Leetro is bad, we need to know about the .mol file that is created by it so we can create our own in some fashion. Also if it does anything fancy when it downloads itself via USB.
Background
The software is available here. Please scan this with antivirus software before use.
There is a special patched version that cannot currently (but hopefully one day) will be useful for exploring .mol files on babbage in EB4890's folder.
- Manual for the MPC6515 controller (uses Modbus over serial for the control panel)
- Note that this says there's software bounds protection with firmware versions 4.1.0.0 or above (once origin is set)
- Firmware for MPC6515 controller (and LaserCut software again)
- the firmware is in the "And tools update" .rar file
- the above, translated by google
- Has comments on the .ini file settings
- Documentation for the MPC03 (previous version, we're MPC05) with .ini file info
- DSP chip and compiler. See also, GDB toolchain. These chips are end-of-line, but were supported by GCC up to 4.2.
Current State of work
- We have some knowledge of the ,mol format
- We have a TXT to mol compiler based on a dll. (windows only)
- We have a TXT parser/generator using python and construct
Currently to do
- Figure out DXFs - A python to dxf to pdf converter might be useful. I've not found a stand alone parser.
- Figure out which parts of the TXT file correspond to which function calls, so we know how to generate meaningful TXT files.
- More work on .Mol files?
Current Repo
Current Repo of work done by user:JasperWallace
Initial Analysis of .mol file
Looking at: /Solexious/MarioBoxes/MINIMARIO.MOL
No ASCII strings (looking using strings)
Does not appear to be compressed (too many zeroes)
0x000 | Header |
0x200 | One set of information What? |
0x400 | Another set of information. |
0xa10 | Likely co-ordinate data. Quite repetitive. Analysis document was mario boxes, with many repetitions of sub boxes, so that makes sense. It looks like possible 16bit number co-oords as the numbers range from a few thousands to hundreds. 32bits are in unrealistic ranges (huge in negative ranges). |
Projects/RELaserSoftware/Compilation traces
USB
Vendor: 0548 Product: 1005
The protocol seems to be fairly simple. I have a capture of some file downloads and deleting a file.
looks like:
commands are sent to endpoint 0x04 and read form 0x88, sent commands are (byte)length and then length bytes
commands 5 and 6 seem to be start and end
example command block:
>w04 0002 00000000: 01 05 *r88 0001 00000000: 04 >w04 0006 00000000: 05 01 01 83 01 7a *r88 0001 00000000: 06 *r88 0001 00000000: 05 >w04 0002 00000000: 01 04 *r88 0014 00000000: 0f 01 83 53 51 55 41 52 45 20 20 4d 4f 4c 00 0e 00000010: 00 00 00 66 >w04 0002 00000000: 01 06
That last reply packet includes the ascii for 'SQUARE MOL' with two spaces in the middle to pad it to 11 characters. This must be a file name in DOS 8.3 format with the . implied between the 8th and 9th characters.
This presumably maps directly to a FAT16 entry, so don't let it be null or begin with a dot!
It isn't, the protocol dosn't seem to be doing any block level management at all, looks like the controller is nice enough to do that for us JasperWallace 01:11, 28 November 2010 (UTC)
State Dump
Now all in this mercurial repo:
Random Links that may be useful
- http://www.solustan.com/linkmotion_and_leetro.php
- http://www.rabbitlaserusa.com/DriverDisk/MPC03/MPC03LV3030/MPC03-LV%203.0.3.0/
- http://www.rabbitlaserusa.com/0/
Driver
Works for VID 0548, PID 1005. Description of the device is EZ-USB (68013A), which is basically a serial interface.