Goals

1. convert the Path Commands into machine-specific gcode.
2. Order and duplicate the Path commands correctly for postprocessing

• If work is duplicated in a multiple WCS, the Path commands may be duplicated
• The proper ordering depends on the user selection in job orderOutputBy (tool, wcs, operation)

3. Split the output into multiple files if desired
4. Generate filename(s) for the output as configured by policy and job settings
5. Write the output to the files

Alternate goal

Do all of the above but for the purpose of generating a Camotics project file rather than final output.

Modules and Classes involved in post-processing.

PathPost.py CommandPathPost: The GUI command for triggering the post processing sequence. When activated, this command initiates the postprocessing sequence

DlgSelectPostProcessor. This class allows selecting a postprocessor if the user hasn't configured one.

buildPostList() This function takes a job as an argument and constructs a list of lists. Each sublist is a list of objects containing Path.Path objects which can be processed by a postprocessor file.

resolveFileName() This function takes a job, subpartname, and sequence number and returns a full filepath name for the postprocessor to write.

xxx_post.py Machine specific post processors. Must implement an export() method. The method must take a list of objects, filename, and argstring and write the resulting gcode to the file. The export method also returns the final gcode.

PathPostProcessor module. This implements the generic PostProcessor class. This class is responsible for finding available postprocessor and (re)loading the selected post. It functions as a wrapper of the specific post.

Process: What happens when you click the button

1. The CommandPathPost.Activated() method is called. It checks to see if what is selected is a post-able. The user should have either selected a job or a subobject of a job. If it's a job, use it, otherwise look for the parent until you find a job and use it. If none, print an error to the console.

If a job is found, it calls buildPostList and pass in the job.

2. buildPostList gets all the selected fixtures and checks to see how the output should be ordered. It then builds a list of tuples of postable objects from 1) the fixtures, 2) the tools, 3) the contents of Job.Operations Group. The list of tuples is suitable for output splitting. buildPostlist checks to see if the output will actually be split. If so, it returns the list, otherwise it flattens the sublists into a single sublist since all objects will be written to a single file. and returns the flattened list. The result of buildPostlist is a structure like [ ("first subpart", [list of postables]) ("second subpart", [list of postables]) ("nth subpart", [list of postables]) ]

3. The command now iterates the list and repeatedly calls exportObjectsWith(). For each sublist, it passes in the subpart string, sublist, job, and idx.

4. exportObjectsWith first constructs the list of postprocessor argruments and resolves which postprocessor to use for exporting. This may be set in the job or determined by asking the user via the dialog. It uses the arguments to construct a unique filename to be written with the sublist items. Once it has established a valid postprocessor and a filename, it loads the postprocessor and calls the export() method passing in the filename args, and sublist. Finally it returns the gcode and filename.

   5. The postprocessor iterates the list of postables and converts them to gcode. If the Gui is up and the user has chosen to show the editor, the editor is displayed with the gcode contents shown. The post returns the final gcode.

5. The command adds the filename to the list of filenames and concatenates the gcode IF all the sub parts post successfully, the command updates the LastPostProcessDate in the job and sets the list of filenames in the LastePostProcessOutput property.

Unit Tests