End Move xy should go befor end move z

[Bastel Baus]

preprocessors/default.py:227ff

def end_code(self, p):
    end_coords_xy = p['xy_end']
    gcode = ('G00 Z' + self.feedrate_format % (p.fr_decimals, p.z_end) + "\n")

    if end_coords_xy and end_coords_xy != '':
        gcode += 'G00 X{x} Y{y}'.format(x=end_coords_xy[0], y=end_coords_xy[1]) + "\n"
    return gcode

‌

Machine should first go to endxy and then to endz (which might for example be z=0). Proposed fix:

def end_code(self, p):
        end_coords_xy = p['xy_end']

        gcode = ('\n')
        if end_coords_xy and end_coords_xy != '':
            gcode += self.lift_code(p) + "\n"
            gcode += 'G00 X{x} Y{y}'.format(x=end_coords_xy[0], y=end_coords_xy[1]) + "\n"

        gcode += ('G00 Z' + self.feedrate_format % (p.fr_decimals, p.z_end) + "\n")

        return gcode

‌

[Bastel Baus]

Included in PULL request: https://bitbucket.org/jpcgt/flatcam/pull-requests/350/beta-minor-bugfix-proposel-issue-597-issue

[Marius Stanciu]

Hello Bastel,

Actually the move done first to Z followed by the move to XY position is by design. If the user choose a Travel Z based on some fixtures that he has on the table and which he wants to avoid, then the user would want not to crash the spindle into the fixtures at the end of the job.

[Bastel Baus]

Dear Marius,

I understand what you are saying. When I check the documentation, it says where it parks [1] and not “z where it will more to the park position”. So I would at least appreciate if we could update the description. Or even better additionally split it in two parameters, something like this

- ('parkz', 'Height to which the tool will go after reaching the endxy position (park position).'),

- ('endz', 'Height on which the move to the end postion is done (default: z_move).'),

I would also change the comment of startz

- ('startz', 'Moves to this height before the first move is done (default: z_move).'),

What do you think? Would you like such a change? If yes I could do an implementation proposal ?

BR,

BastelBaus

‌

P.S.: I would also update the comment line 85ff in preprocessor/default.py

[1] ('endz', 'Height where the last move will park.'),

[Marius Stanciu]

Hi,
Sorry but I’m in the vacation now. I have said something not correct in my previous post, there are 2 different parameters: travelz and endz. Endz is indeed Z for the parking position, but it makes more sense to me to be the first, when the endz > 0.
But I understand your position too so maybe the best of two worlds is to make the reversion only when endz parameter is 0.0. And in that case, to have the same behavior across the app, all the preprocessor files needs to be updated.

‌

[Bastel Baus]

Enjoy your vacation, no hurry for me since I have a local bugfix :-)

I am not sure If I understood you proposal. having different behaviour depending on the value (i.e. >0.0) seams not a good solution for me but probably I didn't get your point right.

BR,

BastelBaus

[Marius Stanciu]

Hi,

In the initial post you said:

Machine should first go to endxy and then to endz (which might for example be z=0).

I assume that you want the move to endz to be after the move on the XY plane because moving at endz = 0 will scratch your surface until the destination.

having different behaviour depending on the value (i.e. >0.0) seams not a good solution for me but probably I didn't get your point right.

If treating the particular case of endz = 0 is not the reason for the requested change can you explain the reason for wanting the endz move to be after the endXY move?

Best regards,
Marius

[Bastel Baus]

That was exactly my case. But generalizing if sombody else might have for example a gemoetry where some hights are higher than endz, the same problem would occur. So in my understanding at least movez should be the lowest movement height.

[Marius Stanciu]

I am reluctant to add an extra parameter at this stage in development. The travelz parameter is supposed to be chosen so it avoids any obstacle. Yet, it can be a bit to slow to move between that height and the cutz depth of cut so for avoiding fixtures on the table I have added the Exclusion zones which help either to pass over the obstacle or can go around.

But I agree that the endz = 0.0 case should be treated, one possible way is like I suggested above.

[Bastel Baus]

Dear Marius, in the end it is of course your decission. I would just not check for a fixed valuer (i.e. “0mm”=. Let’s assume someone want to part at z=1mm but has for example some screws / holders in his PCB which have a height oif 2mm. so probably his movez is something like 5mm and doing the last move then at a height of endz=1mm seams dangerous. So most important to have a crystal clear docu. Second best I would still propose to add either a parkz or move first at endxy and then to endz.

BR, BasterBaus

[Marius Stanciu]

Hello Bastel,
Currently, I am struggling right now to find the determination to finish the tasks that are still outstanding. I want to make a release asap but somehow I do not find the time and motivation so that’s the reason that I am not that open for new changes. If you really think that this is needed and you feel up to implement a new parameter for the final move and you propagate the change to all preprocessor files then by all means….
Best regards,
Marius

‌

[Bastel Baus]

Thanks Marius,

I can believe this is quite some work to keep such a SW running and doing the release. It is realy a very nice tool and I enjoyed working with it a lot!

I will give the implementation a try. Just in advance is there any reason why every preprocessor implements all methods from scratch and they are not deriving their implementation from e.g. the default preprocessor ?

‌

BR,

BastelBaus

[Bastel Baus]

So I tried to reverse engineer the current implementation (At least for one special case). What' seams additionally strange for me that the startz is also ignored if there is a toolchange (see 1). Do you know what the intention of startz was ?

So before implementing something, I try to draft some sketch how it could look like. I personally have not understood the startz function so would ask if we need this. I drafted two proposals one w/ and one w/o the startz functionality. What do you think ?

‌

[Marius Stanciu]

I will give the implementation a try. Just in advance is there any reason why every preprocessor implements all methods from scratch and they are not deriving their implementation from e.g. the default preprocessor ?

Hi Bastel,

The default preprocessor was the one that was first added and should not be seen as the one to derive from but as an example of something that works. The Abstract class that it inherits is the one that creates the sketch.

So I tried to reverse engineer the current implementation (At least for one special case). What' seams additionally strange for me that the startz is also ignored if there is a toolchange (see 1). Do you know what the intention of startz was ?

I think that someone asked for it because it had an fixture on the CNC table that could be hit (maybe something like a tray to hold water into which to cut).

Regarding of your proposals, right now I do not have much time for FlatCAM or to start digging but it is good that we have it here so we can start working on it in autumn.

Best regards,
Marius