Project:RELaserSoftware/MOL file format - Revision history

Axford: Clarified float format

2016-12-02T12:53:59Z

Clarified float format

← Older revision		Revision as of 12:53, 2 December 2016
Line 73:		Line 73:
	== Binary Commands ==		== Binary Commands ==

	Every command starts with three bytes describing the command itself, plus one byte containing the number of parameters following. The parameters are always 4-byte words in LSB integer or floating point format, or four individual bytes. The FP format differs slightly from the IEEE standard, but can be converted by shifting a few bits around.		Every command starts with three bytes describing the command itself, plus one byte containing the number of parameters following. The parameters are always 4-byte words in LSB integer or floating point format, or four individual bytes. The FP format differs slightly from the IEEE standard, but can be converted by shifting a few bits around. LEETRO float: [eeeeeeee\|smmmmmmm\|mmmmmmm0\|00000000]

	The same command can have a different number of arguments!		The same command can have a different number of arguments!

Wonko at 22:40, 1 June 2013

2013-06-01T22:40:55Z

← Older revision		Revision as of 22:40, 1 June 2013
Line 20:		Line 20:
	<hr>		<hr>
	The following stuff was added by [[user:Wonko]]:		The following stuff was added by [[user:Wonko]]:

			There is a script available that reads Leetro MOL files into QCad:
			https://www.ribbonsoft.com/rsforum/viewtopic.php?f=30&t=2436&p=7965#p7965

	= Description =		= Description =

Wonko: Minor new findings, making the description sufficient to generate sane .MOL files. Used in VisiCut and soon in QCad.

2013-05-28T22:31:35Z

Minor new findings, making the description sufficient to generate sane .MOL files. Used in VisiCut and soon in QCad.

Show changes

Wonko: /* Header */

2013-05-04T11:19:55Z

Header

← Older revision		Revision as of 11:19, 4 May 2013
Line 88:		Line 88:
	* 00000008: 0x02 0x02 0x01 0x04 ?		* 00000008: 0x02 0x02 0x01 0x04 ?

	Unknown, fixed value		Unknown, fixed value, probably the version of the file format
	* 0000000c: 0x00000001 ?		* 0000000c: 0x00000001 ?

Line 95:		Line 95:
	* 00000010: 0x00000029 somehow related to the file size or the number of commands		* 00000010: 0x00000029 somehow related to the file size or the number of commands

	~~Unknown~~, ~~fixed~~ value, ~~in some files this~~ is ~~0x00000102. Is this a bit array? Could this be related to~~ the ~~home position~~.?		Four booleans, setting the second value will make the artwork top right relative to the user-set origin. If it is zero, the origin is the center of the work table (not quite though!).
	* 00000014: 0x00000001 ?		* 00000014: 0x00000001 ?

	Position of the artwork in steps (divide by 208.33 to get millimeters?		Position of the artwork in steps (divide by 208.33 to get millimeters? This seems to be 0 at all tested files, and seems to have no impact on the cutting.
	* 00000018: 0x00000000		* 00000018: 0x00000000
	* 0000001c: 0x00000000		* 0000001c: 0x00000000

Wonko: Maybe origin?

2013-05-02T17:37:32Z

Maybe origin?

← Older revision		Revision as of 17:37, 2 May 2013
Line 98:		Line 98:
	* 00000014: 0x00000001 ?		* 00000014: 0x00000001 ?

	~~Unknown, fixed value~~		Position of the artwork in steps (divide by 208.33 to get millimeters?
	* 00000018: 0x00000000		* 00000018: 0x00000000

	~~Unknown, fixed value~~
	* 0000001c: 0x00000000		* 0000001c: 0x00000000

Wonko: Some new findings added

2013-05-02T17:26:09Z

Some new findings added

← Older revision		Revision as of 17:26, 2 May 2013
Line 41:		Line 41:
	a conversion is required. All files have four chunks at fixed locations:		a conversion is required. All files have four chunks at fixed locations:

	* the header chunk starts at 0 and contains 32 words, followed by 0's		* the header chunk starts at 0 and contains 32 words, followed by 0's, followed by the locations of the following blocks
	* the config chunk is at 0x00000200 and contains informations about the total artwork		* the config chunk is at 0x00000200 and contains informations about the total artwork (this block may start somewhere else. See header.)
	* the test chunk is at 0x00000400 and moves the laser head on the bounding box of the artwork		* the test chunk is at 0x00000400 and moves the laser head on the bounding box of the artwork (this block may start somewhere else. See header.)
	* the draw chunk is at 0x00000A00 contains all commands to output the actual drawing and cutting commands		* the draw chunk is at 0x00000A00 contains all commands to output the actual drawing and cutting commands (this block may start somewhere else. See header.)
	* the file is then patched to the next 512 byte boundary		* the file is then patched to the next 512 byte boundary

Line 95:		Line 95:
	* 00000010: 0x00000029 somehow related to the file size or the number of commands		* 00000010: 0x00000029 somehow related to the file size or the number of commands

	Unknown, fixed value		Unknown, fixed value, in some files this is 0x00000102. Is this a bit array? Could this be related to the home position.?
	* 00000014: 0x00000001 ?		* 00000014: 0x00000001 ?

Line 117:		Line 117:
	* 00000030 - 0000006c		* 00000030 - 0000006c

	~~Unknown~~, ~~fixed value~~		Location of the 200 block. This is the n'th block, block size is 512 bytes. The 200 block contains general data about the artwork.
	* 00000070: 0x00000001 ?		* 00000070: 0x00000001

	~~Unknown, changes!~~		Location of the 400 block. This block is called when the user presses "Test" on the CMD03 and outlines the artwork.
	* 00000074: 0x00000002 ?		* 00000074: 0x00000002 ?

	~~Unknown, changes!~~		Location of the 600 block. This block is called when the users selects "Cut File" (or so) from the menu.
	* 00000078: 0x00000003 ?		* 00000078: 0x00000003 ?

	~~Unknown, changes!~~		Location of the A00 block. This block is called when the users presses "Start".
	* 0000007c: 0x00000005 ?		* 0000007c: 0x00000005 ?

Ciaran.mooney: Got rid of shout-y headings and tidied up line breaks

2013-04-15T09:09:44Z

Got rid of shout-y headings and tidied up line breaks

Show changes

Ciaran.mooney: /* STATUS */

2013-04-15T09:04:49Z

STATUS

← Older revision		Revision as of 09:04, 15 April 2013
Line 34:		Line 34:
	== STATUS ==		== STATUS ==

	we have a pretty good understanding of the file format to the point that we can		We have a pretty good understanding of the file format to the point that we can generate new MOL files from a dxf drawing, at least for cutting patterns on the test machine. This is for cutting only, no raster engraving and other features yet!
	generate new MOL files from a dxf drawing, at least for cutting patterns on the test
	machine. This is for cutting only, no raster engraving and other features yet!

	== THE FILE FORMAT ==		== THE FILE FORMAT ==

Wonko: Some new findings

2013-04-14T20:44:31Z

Some new findings

← Older revision		Revision as of 20:44, 14 April 2013
Line 98:		Line 98:
	* 00000000: 0x00001000 Size of file in bytes		* 00000000: 0x00001000 Size of file in bytes

	Unknown, ~~fixed value~~		Unknown, this seems to be close to the number of motion blocks plus 30.
	* 00000004: 0x00000022 ~~34d ?~~		* 00000004: 0x00000022

	~~- not always fixed, FIVE.MOL has 00 00 00 2f...~~

	File Version Number: file was written with dll 4.1.2.2		File Version Number: file was written with dll 4.1.2.2
Line 124:		Line 122:
	* 0000001c: 0x00000000		* 0000001c: 0x00000000

	~~Describing~~ the ~~stepper resolution~~ in ~~x and y~~		Size of the artwork in steps (divide by 208.33 to get millimeters (depending on the machine configuration))
	* 00000020: -20833 steps ~~per 100mm in x direction~~		* 00000020: -20833 artwork width in steps
	* 00000024: -20833 steps ~~per 100mm in y direction~~		* 00000024: -20833 artwork height in steps

	Unknown, fixed value		Unknown, fixed value
Line 140:		Line 138:
	* 00000070: 0x00000001 ?		* 00000070: 0x00000001 ?

	Unknown, ~~fixed value~~		Unknown, changes!
	* 00000074: 0x00000002 ?		* 00000074: 0x00000002 ?

	Unknown, ~~fixed value, maybe the number of blocks in this file?~~		Unknown, changes!
	* 00000078: 0x00000003 ?		* 00000078: 0x00000003 ?

	Unknown, ~~fixed value~~		Unknown, changes!
	* 0000007c: 0x00000005 ?		* 0000007c: 0x00000005 ?

Line 298:		Line 296:
	This is the end of subroutine 1		This is the end of subroutine 1
	* 000005f0: : end subroutine 1		* 000005f0: : end subroutine 1

			== Data Block at 0x00000600 ==

			This block cuts the bounding box of the artwork plus 2mm on each side. This block is optional. Fill with 0 if not used.

	== Data Block at 0x00000a00 ==		== Data Block at 0x00000a00 ==
Line 334:		Line 336:
	* 00000a50: : laser power corner:40.00%, straight:40.00%, p3:30.00%, p4:50.00%, startspeed:1041(5.00%), speed:20833(100.00%), ??:0		* 00000a50: : laser power corner:40.00%, straight:40.00%, p3:30.00%, p4:50.00%, startspeed:1041(5.00%), speed:20833(100.00%), ??:0

	Command ~~block used for repetition~~. ~~Interestingly~~, ~~the~~ blower ~~commands are inside~~ the ~~block~~.		Motion Command Block. These blocks seem to divide the file into 2kByte chunks at
			command boundaries. Command blocks never contain more than 510 (512?) words
			(<=2kBytes). This subroutine can ahve many command blocks. Motion Commands
			are switching periphery (laser, blower), setting acceleration and deceleration, and
			moving the head.
	* 00000a70: : command block follows, 290 words (form 00000a78 to 00000f00)		* 00000a70: : command block follows, 290 words (form 00000a78 to 00000f00)

JasperWallace: /* Header */

2012-03-17T21:12:28Z

Header

← Older revision		Revision as of 21:12, 17 March 2012
Line 100:		Line 100:
	Unknown, fixed value		Unknown, fixed value
	* 00000004: 0x00000022 34d ?		* 00000004: 0x00000022 34d ?

			- not always fixed, FIVE.MOL has 00 00 00 2f...

	File Version Number: file was written with dll 4.1.2.2		File Version Number: file was written with dll 4.1.2.2
Line 109:		Line 111:
	This word changes when the size of the file changes, i.e. when lines are added		This word changes when the size of the file changes, i.e. when lines are added
	This line corresponds to the number of "move relative" commands in the entire file counting		This line corresponds to the number of "move relative" commands in the entire file counting
	"unknown 07" and "unknown 09" as well. Is that coincidence? What would this value be good for?		"unknown 07" and "unknown 09" as well. Is that coincidence? What would this value be good for? perhaps estimating the cutting time?

	* 00000010: 0x00000029 somehow related to the file size or the number of commands		* 00000010: 0x00000029 somehow related to the file size or the number of commands