All the trouble a new user may hit, and some incorrect simulation.

[AndKe]

All necessary documentation is here: https://drive.google.com/open?id=1PoXcpEmy-p9_TOGIYLHb5D5GCp9P6Eze

executed on GRBL1.1h (current release)

Whatever I did as a new pycam user, something is wrong. Please see "expected motion.ogv" - the toolhead starts by down, does the job.

Then the reality: "bad start.mp4" : the Z axis crash in the top limit, then never reach the working area.

The machine does not have yet absolute coordinates (no endstops yet). only relative-coordinates - the bad behavior may be caused by that ? Is there were a way to tell pycam where the tool origin is ? (i would like to set it to start from a position where Z axis is 0mm above material, and XY are at a specific corner, or center of the object.

Finally, please see the "inconsistent speed.mp4" - I do not know what may be causing that.

[sumpfralle]

Thank you for your the thorough visualization of your attempt. This simplifies the discussion a lot.

Then the reality: "bad start.mp4" : the Z axis crash in the top limit, then never reach the working area.

The gcode file starts with the following Z positioning commands (all others removed):

G0 X15.024615 Y39.902692 Z25.000000
G1 Z21.000000
G0 Z25.000000
G1 Z21.000000
...

First it moves to the safety height (pycam defaults to 25mm; this is configurable in the toolpath settings). Then it moves down to 21mm - I guess, this is supposed to be within your target material.

I assume, that you did not adjust the relative coordinate system of your controller before?

Usually I do the following:

1. shift the top of the model in pycam to Z=0
2. move the machine (manually) to the top of the material
3. set the Z coordinate to zero

Now your physical coordinates of your material are in line with the positions used by pycam. (obviously you also need to adjust the x/y axis positions)

(no endstops yet)

I am used to the linuxcnc controller software. It forces you to specify the maximum dimensions of the x, y and z axes. And it forces you to specify the physical position of each axis before starting an operation. This may be done with sensors or (maybe) manually.

Even without endstops (really no sensors at all?) you will be able to do this manually by moving the head to a defined position and telling this to your machine controller. Afterwards the machine controller will prevent moves outside of the physical working area.

(or maybe I misunderstood you)

Finally, please see the "inconsistent speed.mp4" - I do not know what may be causing that.

The gcode contains the following line:

G64 P0.000000

Thus you picked a zero tolerance for movements. In this case the machine needs to slow down to standstill at every corner. If you select a tolerance greater than zero (depending on your required precision), then the machine will be able to cut corners slightly and maintain speed. Even a very small value will help a lot.

(see the documentation of G64)

Does this answer your questions?

Can you think of specific changes, that could be added to pycam's documentation in order to help other users with similar issues?

[AndKe]

Yes, I too think no endstops are an odd choice, but ebay and https://www.banggood.com/3018-Pro-3-Axis-Mini-DIY-CNC-Router-Adjustable-Speed-Spindle-Motor-Wood-Engraving-Machine-Milling-Engraver-p-1463876.html?rmmds=search&cur_warehouse=CN are selling lots of those.

Dirt cheap, and fairly ok, several upgrades since they made the photos, build instructions do not match :) , but it works, people buy them. I bought one, and a 15W laser. I do plan to mount endstops on every axis in both directions. (ordered suitable microswitches yesterday

As for LinuxCNC I thought/think it was for paralell-port driven CNC's. - so I did not even try it.

regarding "G64 P0.000000" Reagrdsless of the "path mode" I choose, the "motion blending tolerance" and "naive CAM tolerance" fields are always disabled, and showing "0,000"

It would be nice if the preview showed all motions, including the initial up by 2.5cm How do you suggest I do "set the Z coordinate to zero"? (maybe there should be an option for this in the pycam ? "assume head is moved to 0,0,0" )

[sumpfralle]

I do plan to mount endstops on every axis in both directions.

The machine I use has only one switch for each axis. This is sufficient for giving your machine controller a single point of reference (the machine controller will limit moves according to the configured length of each axis). But if you expect troubles with incorrect moves of some axis, another switch at the other end may help.

As for LinuxCNC I thought/think it was for paralell-port driven CNC's. - so I did not even try it.

I guess, there are other backends supported, too. I wired my machine to a parallel port - it works great.

Reagrdsless of the "path mode" I choose, the "motion blending tolerance" and "naive CAM tolerance" fields are always disabled, and showing "0,000"

I tried it on v0.6.4 - there it seems to work. Which version do you use?

It would be nice if the preview showed all motions, including the initial up by 2.5cm

This is a bit hard, since pycam cannot know, at which position (x/y/z) your machine starts. Do you have an idea, how to solve this?

How do you suggest I do "set the Z coordinate to zero"?

Use the position action for a model and click at "align position". The defaults cause the model to be moved to the position, that you are looking for.

[..] "assume head is moved to 0,0,0"

It is more precise to say "move the model to ...".

It is probably a good idea, to get a feeling for the positioning logic of your machine controller software. This may give you a better understanding for your questions above. For example in LinuxCNC the position handling feels quite intuitive to me.

[AndKe]

I am running master, (quickly downloaded pycam-master) , did not even clone, the just run the run_gui.py

I do understand the problem of not homing, and having absolute coordinates. Also, when I mentioned double endstops, that was for better foolproofing against cockups.

One solution would be to have a "relative mode" - where Gcode starts with G92, ( you expect user to have moved toolhead to some part of the model to what will become 0,0,0) and calculate all movements from there. - then maybe store it in G53..55 in case of multiple gcode files for manual toolchange etc.

One note: I am most familiar with 3D printing, where most things are fine with absolute coordinates+autolevelling, where none of these issues exist, so my suggestions may not be the best for every scenario to to little experience with CNC milling.