QCAD.org Forum

MacOs Version 15.6.1
Qcad CAM Pro Version: 3.32.5.0
Arcdroid Post Processors installed

I’ve started to use my new Arcdroid and understand the built in trace programs and UI. I am now starting to program using QCad/Cam. I know how to design in CAD already. I have a few questions about the use of CAM software for someone who has never used it.

Will the CAM export file (g code) override the values I put into the Arcdroid.. (ie. Z offset, ker, etc)? I am pretty sure it does, but dont know 100%

Tools:
I think I need to create a tool around the Plasma cutter.

If I need to create new tool in qcad, should I create a new tool for each media and thickness around amperage, speed etc? For example 1/8”, 3/16”, 1/4” steel…aluminum… stainless etc?

Any help would be appreciated, I have my settings in a spreadsheet already

Hi,

A Plasma cutter is still something different than a milling router or using that with a laser module.
Common is that they all move in XY and in Z.

Plasma typically 'touches off' and then retracts a bit.
Height is then constantly adapted depending measured arc parameters.
This last part is fully up to the Plasma driver with a closed loop algorithm and some settings by parameters or knobs.

I have a copy of the post processor is front of me.
It is directly based on GCodeBase.js.
Meaning that all things define in the most standard G-Code exporter are used unless overruled by ArcDroidMM.js for example.
Overall power (amps) and FEED is of course depending on the material to cut.
More power, bigger nozzles, ... all make a bigger hole and then the offset to the required contour matters.
QCAD/CAM is set to generate those because G41/42 is not supported.

It's a pity that Laser or Plasma do not have their own Profile dialog ... It's the Milling Profile dialog that is molded to suit the needs.
In Laser machining I remember that milling rotational SPEED is being (mis-)used as Laser POWER.

ArcDroidMM.js:
Tooltype 'Mill' is simply replaced by 'Plasma' ... Textual.

In the CamProfileToolpathDialog:
- CamSpindleSpeed and associated are set invisible.
- Whole the CuttingDepths_Group is set invisible.
- CamPlungeRate is set invisible.

In the CamToolDialog:
- CamSpindleSpeed and associated are set invisible.
- CamPlungeRate is set invisible.

I have to admit that not everything is fully understood ...
... But I see the initialization of a LayerDialog.

I guess that Plasma parameters depends on layer properties. (Custom Properties as key-value pairs)
Probably meaning that things drawn on Layer X use different settings than those drawn on Layer Y.
Perhaps ArcDroid documentation explains that further.

Continuing with the same assumptions:
In QCAD/CAM you can generate a Template drawing.
This would normally include tool types and their specifics for milling.
It can include a layer with a rectangle of your work-area.
And that can also include layers with predefined custom properties ... Properties for Plasma in this case.

Then it would be the question of placing shapes to cut on the intended layer before creating a profile.
It is also possible that a drop-down on the Layer Dialog is expandable and that (new) content is saved persistent.

Hoping this helps and that it is somewhat assumed correctly.

Report back with success or failure.

Regards,
CVH

CVH wrote: ↑

Fri Dec 26, 2025 10:53 am

Hi,

A Plasma cutter is still something different than a milling router or using that with a laser module.
Common is that they all move in XY and in Z.

Plasma typically 'touches off' and then retracts a bit.
Height is then constantly adapted depending measured arc parameters.
This last part is fully up to the Plasma driver with a closed loop algorithm and some settings by parameters or knobs.

I have a copy of the post processor is front of me.
It is directly based on GCodeBase.js.
Meaning that all things define in the most standard G-Code exporter are used unless overruled by ArcDroidMM.js for example.
Overall power (amps) and FEED is of course depending on the material to cut.
More power, bigger nozzles, ... all make a bigger hole and then the offset to the required contour matters.
QCAD/CAM is set to generate those because G41/42 is not supported.

It's a pity that Laser or Plasma do not have their own Profile dialog ... It's the Milling Profile dialog that is molded to suit the needs.
In Laser machining I remember that milling rotational SPEED is being (mis-)used as Laser POWER.

ArcDroidMM.js:
Tooltype 'Mill' is simply replaced by 'Plasma' ... Textual.

In the CamProfileToolpathDialog:
- CamSpindleSpeed and associated are set invisible.
- Whole the CuttingDepths_Group is set invisible.
- CamPlungeRate is set invisible.

In the CamToolDialog:
- CamSpindleSpeed and associated are set invisible.
- CamPlungeRate is set invisible.


Regards,
CVH

What I see when I am setting up the tool (like you mentioned) is a limited set of parameters. I am currently just working with one material thickness of 3/16" of an inch and a feed of 63. I will have to set the power on my machine.

I can get the tool path to start where I want, do the appropriate lead in etc. The one thing I do not understand is when I run the simulation it starts off at the safety Z position moves to the start position then drives to 4" (ie a plunge of 4") below the surface. I have no idea if this is correct, and can't find anywhere to change it. I am concerned that it will try to drive my machine down into the material. it's supposed to stay .06 above for the cut

clearly I dont understand what supposed to be going on here and im worried to try it on my machine

It is certainly best to 'cut nothing but air' for starters.
Meaning that you fool your machine Zzero so high that it can't touch your material in any case.
For milling machines we can also remove the cutter all together.

A short introduction:
Not many DIY machines have a true feedback of their actual axis positions.
Certainly with stepper, closed-loop steppers or servo motors.
They all work with sending NN steps in one direction and only assume that the axis has moved NN steps.
The software counter is thus not per definition in sync with the actual position.

A certain type of linear motors are a far better option but are also really expensive.

Homing:
On power up, the software driver has no valid reference of the physical position of the axes.
For that we run a Homing sequence.
Typically first in Z ... Until a limit switch or so is reached ... Best as high a possible to be safe.
Then in XY ... Again until limit switches or so are reached.
At this point the software values are in sync with the actual positions.
The driver now knows where the machine is.
But that doesn't mean that the XYZ values are already meaningful.
We call this Machine coordinates.

Zeroing:
After that the virtual and real positions are in sync we can zero our machine on the work-piece.
Typically first in XY.
Using QCAD/CAM that must correlate with the drawing origin.

For example left (X) - low (Y), so we move our setup to a point that can serve as left-low (manually).
At this position we zero the X and the Y axis.
Then we need to zero in Z and that depends on the thickness.
For that we move down in Z until the mill or nozzle just touches the work piece.
At this height we zero the Z axis.
We call this Work coordinates.

For the rest we need at least the used parameters.
But because whole the CuttingDepths_Group is set invisible, a screen capture serves nothing.

Diving back in the ArcDroid post processor, you probably use ArcDroidIN.js with display name 'ArcDroid CNC plasma [in]'.
Please also read above forum rules in red.
Without any information we can only guess.

ArcDroidIN.js is based on ArcDroidMM.js with some minor adjustments:
- In inch (G20) with 4 decimals
- A slightly adapted header: - And working parameters: Zsafe will thus be 1 inch above the material ... If and only if the machine is zeroed correctly
And it will not drop below 1/10 of an inch.

PS: You don't have to quote a whole post.
Select only what to quote from a text/post/reply and then hit the Quote button.

Regards,
CVH

Hi,

Reading your topic, I understand that Gcode is new for you. While the G-parameter is the best know, the Speed (S) is used for the 'tool-intensity', like RPM of a drill, or the PWM-setting for a lasercutter. The Feed (F) parameter is used for how fast your tool is moving in x,y,z-space. Also often used are M03 (Switch tool On) and M05 (Switch tool Off).

Different materials always requires different S and F settings. These can be set while creating the tools and/or while creating the paths in QCAD/CAM. Mind that your machine might need some odd S and F values. Consult the machine documentation.

QCAD's simulator is only a representation of the toolpath-cad-entities; it does NOT represent the really executed movements on your CNC-machine. The by QCAD generated GCode, is read, interpreted and executed by the machine-Gcode-interpreter on your plasma machine.

Just browsed for the Arcdroid; it is a desktop plasma cutter. And downloaded the Arcdroid postprocessor. Nowhere mentioned in the machine specs is the used gcode-interpreter. As for most desktop CNC-machines grbl is most likely to be used.

For creating a toolpath with QCAD/CAM one has to create a tool first. I notice the S-parameter is called 'Diameter' and Feed Rate is the F-parameter. In field Description you can enter a text like "Aluminium 3 mm". Even when a plasma cutter has only one torch, you might add a second tool for "Aluminium 1 mm" or for "Steel 0,8 mm"; every tool with their own specific Diameter and Feed rate for a particular material or application.

Arcdroid only uses QCAD/CAM for designing and creating the basic Gcode. That Gcode is (like on a 3D-printer) read and processed by Arcdroid. No more not less.

Be aware of the 'workpiece-zero-point'. Arcdroid presumably converts the Gcode to a 'machine'zero-point.

For some more detailed information of Gcode from the QCAD-postprocessor to a grbl-machine, you might read the info within the PwmLaserOffsetMM.js post-processor.

As stated above:
ArcDroidIN.js is based on ArcDroidMM.js
ArcDroidMM.js is based on GCodeBase.js ... CamExporterV2

True, Grbl.js and related are also based on GCodeBase.js ... CamExporterV2
There is probably a reason that ArcDroid provides post processors not based on Grbl.js or related.

ArcDroidIN.js doesn't register/alter new parameters.
ArcDroidMM.js registers 2 new parameters and alters none. Both used in the header after M444.

ArcDroidMM.js also replaces the tool type "Mill" with "Plasma"

It is GCodeBase.js that registers these parameters among others: It is ArcDroidMM.js that disables/hides SPEED and all related and sets spindleSpeed to 1.

Presets, Power, Speed, Passes and so on are handled in a Layer Dialog.

But as there is almost no documentation on the CAM Add-On ....

Regards,
CVH

Thanks

I am going to try and test today and see what the results are. hopefully it doesn't try and drive my torch down through the material.

tiger351w wrote: ↑

Mon Dec 29, 2025 9:21 pm

hopefully it doesn't try and drive my torch down through the material.

It won't if you do the Homing and Zeroing sequences correctly.

High-end machines do that automatically.
Especially if they have a battery of interchangeable tools and an automatic tool-changer.
There is even something like tool wear compensation.

My flat-bed engraver its driver must Home first or it doesn't run over F100 (mm/min).
The working area isn't guarded either, simply because the driver doesn't know where the physical edges are.
But it is me that has to start the Homing sequence manually, it is a G-Code macro.

Because Homing is carefully slow, I have implemented a Park position.
Before turning of the machine I park it near the Homing positions.

Why 'carefully slow' is because it must be able to decelerate to a full stop not crashing into anything.
You can't 'Home' at F6000 and expect it to stop within an excess travel less than a fraction of a mm.

Regards,
CVH