Author Topic: [V1 - 82] macros {$mop.first.X} ... don't take machining origin shift in account  (Read 17466 times)

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
Hello

When we try to use {$mop.first.X}{$mop.first.Y} macro, they always return the value for a machining origin = 0, if machining origine have been moved, the macro don't take the shift in account.

++
David
« Last Edit: May 27, 2025, 18:27:20 pm by dh42 »

Offline lloydsp

  • CNC Jedi
  • *****
  • Posts: 9074
    • View Profile
Is that even if you close CB and when open again, re-open the file?  I've found some settings don't 'stick' until you do a full 'reboot' of the application and the object file.

Lloyd
"Pyro for Fun and Profit for More Than Fifty Years"

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
Quote
Is that even if you close CB and when open again, re-open the file?

yes sir ;)

++
David

Offline dave benson

  • CNC Jedi
  • *****
  • Posts: 1886
    • View Profile
David
I am getting the start point values reported correctly, when I move the start point and generate the gcode again but not until.

Dave

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
Hello

It seems that you are confusing start point and machining origin  ;) it is the machining origin that is moved, not the start point.

on pic1, machining origin is at 0,0, so if the start point is at 30,20 as on the picture, it must be reported ... 30,20 in the Gcode .. it's ok, but on pic 2 machining origin is at 20,20, so the start point is at 10,0 ... but the $mop.first.... macro do not take this offset in account.

++
David

Offline dave benson

  • CNC Jedi
  • *****
  • Posts: 1886
    • View Profile
Ah I see what you are trying to do now, the machining origin and the start point are different
variables, I don't know if you can with a script, but your line might look something like this:

G0 X{$mop.first.X – $mop.machiningorigin.X}  Y{$mop.first.Y– $mop.machiningorigin.Y}
 
I don't know if cambams variable for machining origin is accessible at the scripting level.

I will have a poke around  later with VS Studio.

Dave

Offline dave benson

  • CNC Jedi
  • *****
  • Posts: 1886
    • View Profile
I could not find a scripting macro to suit, in c# you can access the machining origin in the machining folder or
at the part level, at the mop level you also have a get gcode origin.
I don't know if there's a way to do it scripting though.

Dave

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
Hello

Quote
G0 X{$mop.first.X – $mop.machiningorigin.X}  Y{$mop.first.Y– $mop.machiningorigin.Y}

Unfortunately CamBam don't allow math in the PP macros  :( ... and {$mop.machiningorigin.X} macro do not exists.

++
David
« Last Edit: May 29, 2025, 15:01:10 pm by dh42 »

Offline dave benson

  • CNC Jedi
  • *****
  • Posts: 1886
    • View Profile
When I had a look at the doc's for the macro's yesterday, I was focused on the mop first macro
it stays constant no matter what you set in the machining origin so it is calculated from the drawing
co-ordinates  at 0,0 not the machining co ordinates.

However when I changed the machining origin co ordinates at the part level and took look at the gcode it was correct and reflected the changes I made.
I tested a profile and an engraving mop both produced the gcode at the correct offset changes following the machining origin.

Dave

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
Hello

Ah ! strange ... On the test file I have, the result is always the same no matter if the origin offset is given in Machining or Part folder, and no matter if I produce the Gcode for the full file or only for the Part  ???

++
David

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
I have done a new test on a simplified file (only a line to engrave) and the offset is never taken in account no matter if it is set in the machining folder or part folder  ??? ... maybe it is the position where the macro is written in the PP ? it is in the MOP section.

the machining origin is set to NaN in the machining folder.

++
David
« Last Edit: May 30, 2025, 19:27:15 pm by dh42 »

Offline dave benson

  • CNC Jedi
  • *****
  • Posts: 1886
    • View Profile
I've downloaded the PP and will have a look tonight.
In short:
The start macro is referenced from the Drawing Origin at 0,0 and won't change with the machining origin.
There is a hierarchy.
When you start a new file, everything is at its default value drawing origin and machining origin
are at x=0 y=0.

When you change the machining origin at the part level, this takes the highest priority
and overrides whatever is in the machining folder. This is so you can have parts with different
machining origins.

If a part has not had its machining origin changed it uses a default value, or if the machining origin has been set in the machining folder it uses that.

I switched to the default PP and generated the code the engraving mops and their position in the gcode are correct for example the rectangle is drawn at X=10, Y=10 (drawing units).

For the part 2 engrave mop:   I set the machining origin to X = -3 and Y = 3.
For this mop the gcode starts at  X = 13 and Y = 7 and this reflects where you have moved the
machining origin in that part. 

Drawing units  X= 10 - -3  = 13
and Y= 10 – 3 = 7.

Part one is easy to as the Gode starts at X = 5 and Y = 5. and because you have moved the machining origin for that part from your drawing origin up 5 and across 5.

Something I just noticed is that (I have my stock visible the orange line) the stock follows the machining origin the stock object moves around
on the screen when changing the machining origin
at the machining folder.

David what is the reason you are developing this PP, do you have a specific need as I might have
one that suits your needs or one that might be easily adaptable.

Dave

Offline dh42

  • Administrator
  • CNC Jedi
  • *****
  • Posts: 7564
    • View Profile
    • Cambam V1.0 French Doc
Hello,

Quote
David what is the reason you are developing this PP

It's not me, it's a guy on a forum ; I'm not sure why He need this, maybe it's to move the XY before the Z.

++
David

Offline lloydsp

  • CNC Jedi
  • *****
  • Posts: 9074
    • View Profile
My experience with all PPs in CamBam has been that Z moves to the 'safe' height before any xy motion ever occurs, and after a job is complete.
"Pyro for Fun and Profit for More Than Fifty Years"