Pattern jobs

crap

Hi all!

I have my Duet3 set up as a CNC router. I'm looking to produce a large number of identical parts out of wood, so I would really like to be able to repeat a job in patterns, in this case 5x5 for a total of 25 parts per batch. With the added twist that some of them are rotated to get better material use (got a separate g-code file for this).

I'd like to think this is easily done, to call the same two G-code files repeatedly from another G-code file while changing the origin point. But I can't seem to manage this. Here's what I've tried, to only make three parts of which one is upside down:

G54 (the G54 origin is set manually, and represents the first part to be milled)
G0 Z36
G0 X0 Y0
G10 L20 P2 X-214 Y-120 Z36 (set G55 coordinates, used for the second part)
G10 L20 P3 X-177 Y0 Z36 (set G56 coordinates, used for the third part)
G54
M32 "Kanel_uppv_trimmad.g"
G55
M32 "kanel_upponer_trimmad.g"
G56
M32 "Kanel_uppv_trimmad.g"

Firstly: This doesn't work. If I run this from the Job folder in DWC, it will make only the first part and then stop. Surprisingly if I run it from the macro folder instead, it will only make the last part.

Secondly: This doesn't scale well since there are only 9 numbered origins (G54-G59.3), and I want to make 25 parts. I could still use this method if I redefine the origins as I go along, but I'd like to think there is another way. I tried G92 but the command seems fully broken on my firmware, a simple "G92 X0 Y0 Z0" does not make the current coordinates 0 in any coordinate system (neither machine coordinates nor any of the G5x).

I'm due for a firmware update either way so if anyone suggests a G92 way of doing this I suppose I could update the firmware and hope that it fixes the command, but I'd prefer to just get on with this job right now and update some other time. I know that several of the commands in my config.g have been redefined so it will take me a while to get the machine working again after the update.

Any suggestions on how to do this? Image below shows intended result.

I don't know if this will work for you, but I suggest you check out the gcode meta commands if you're not familiar. Essentially basic programming language.

https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands

Perhaps use global variables for your origin points for each iteration, and a while loop to iterate

I dont know your machine config/origins but something like:

global jobOriginX = 0
global jobOriginY = 0
global jobOffsetX = ???
global jobOffsetY = ???
global iteration = 0
global maxIterations = 10

while global.iteration < global.maxIterations
   G10 L20 X{global.jobOriginX} Y{global.jobOriginY} Z36
   
   INSERT CODE FOR MAKING PART
   
   set global.iteration = {global.iteration + 1}
   set global.jobOriginX = {global.jobOriginX + jobOffsetX}
   
   ADD LOGIC FOR OUT OF BOUNDS  X ORIGIN
   
   set global.jobOriginY = {global.jobOriginY + jobOffsetY}
   
   ADD LOGIC FOR OUT OF BOUNDS Y ORIGIN

Using the above you would need to add logic for ensuring each iteration does not go outside the boundaries of your XY axes. Perhaps adding more variables for job size and then checking to see if origins + job size are out of bounds, then adjusting accordingly.

Alternatively you could manually define an array for your each x and y job origins and then just iterate through the array in the while loop. The advantage of using the code above would in theory be once you get it working you can use it for other batch part jobs by just changing the appropriate variables without having to manually define origin points for each iteration of the batch.

crap

@wwak84 Thanks for the pointers, I'll look into the meta commands. It would still be nice if I could call a g-code program and have it return and continue executing. I did consider pasting the job 25 times into the same file, but that would make for one nasty file. With your suggestion at least I would only need to paste the full job code once.

@crap To elaborate on my suggestion, this would be a macro that you could pass parameters, one of which being the job, and another to define the relevant variables, and lastly number of iterations

call the batch job gcode by

M98 P"batchjob.g" J"jobGcode.g" V"jobVariables.g" I(insert integer)

pseudo code batch job gcode

;Batch job gcode
;Parameters... J = job gcode to be repeated
;                         V = relevant variables for iterating job
;                         I = number of iterations

M98 P{param.V}

local iteration = 0

while iteration < param.I
    M32 param.J
    Whatever logic to move job coordinates
    set local.iteration = local.iteration +1

No idea if this would work as is, but I think the general concept will point you in the right direction

crap

@wwak84 Adding variables to the batch job is a neat idea, I can see that being useful at some point. Although in this case I'd probably run the same parameters quite often so more likely I'll modify the macro instead when it needs changing. A slight issue I've found while trying this is that M98 only calls g code files from the macro directory, although I suppose I can place the job files there instead.

But I'm still surprised that it's not possible to have nested jobs with M32, whether I run the base program from the job directory or the macro directory it behaves differently but neither will allow me to call consecutive jobs from a single file. If using M98 and running everything from the macro folder solves it then fine by me, but it's not the behavior I would expect.

@crap You can call macros from anywhere on your system

from the M98 documentation

"The filename may include a path to a subdirectory. For relative paths, the default folder is /sys. Absolute file paths are also supported starting with "0:/" for the internal SD card or "1:/" for the external SD card if fitted."

e.g., M98 "0:/somefolder/somemacro.g"

I expect you could do the same for M32 "0:/somefolder/somejob.g"

I would still suggest using variables rather than explicit values. For me personally, it's easy to miss one value and then the whole thing runs funky because of one missed edit.

I think nested jobs is a rather niche use case, and probably not going to be implemented. You may be able to run the jobs as macros if nesting is necessary, but you would likely lose the job screen while the macro/job runs. I'm surprised that multiple consecutive M32 calls do not work in a single macro but I have never tested to see if that functionality works. I'll do a simple test later today to see if I can print two lines using separate job files.

What firmware are you running?

crap

@wwak84 I'm running version 3.3 (on a 6mbhc board). I did suspect it would be possible to call files in other directories using M98 knowing the correct syntax, thanks for telling me how. Nested jobs are not so rare in CNC industry actually, but probably not many hobbyists/makers use it.

@crap Yeah, I'm not too familiar with CNC. Since RRF is primarily oriented to 3d printing, I think some of the CNC functionality might be a bit behind the overall industry.