"Scan" feature to move around maximum boundaries

More
8 years 2 weeks ago #118981 by lars
Yeah. I also thought it would be easier to get the boundaries. But it's just a feature of the GUIs to parse the loaded program and calculate the boundaries, so I don't see how this could be a standard variable of the LinuxCNC core.

Although it would be nice if the GUIs exported this in a more easily accessible way.

Please Log in or Create an account to join the conversation.

More
8 years 2 weeks ago #118982 by andypugh
Maybe it would be easier to use a standalone HAL component (it only needs to be a HAL component so it can be wired to a button press)

It could get the file name from the linuxcnc.stat().file
linuxcnc.org/docs/2.7/html/config/python...ding_linuxcnc_status
The run through each of the lines of G-code noting the max and min X and Y values.
(this might be inaccurate for arcs)
Then it could send the moves by MDI.

Please Log in or Create an account to join the conversation.

More
8 years 2 weeks ago #118985 by lars
I'm definitely not an expert at this, but I see some problems there:

1. What happens if the file changes? The boundaries should only be updated when the GUI reloads the file. How would an external component detect that?
2. The coordinate system offsets may change. I think this would be possible to detect from the component but it would not be really trivial.
3. Just getting min/max X/Y values from the G-Code also neglect cutter compensation and maybe other things? I think the values should be precise when they are used to ensure that the program won`t go through your fixtures.

Please Log in or Create an account to join the conversation.

More
8 years 2 weeks ago #118986 by andypugh

lars wrote: 1. What happens if the file changes? The boundaries should only be updated when the GUI reloads the file. How would an external component detect that?


Nothing changes. When the component sees the "do your thing" trigger it then loads a copy of the current G-code fie into it's own parser and works out the extents.

2. The coordinate system offsets may change. I think this would be possible to detect from the component but it would not be really trivial.

The module can either work in the current coordinate system, or get all clever and have the parser consider the offsets (read from linuxcnc.stat() and calculate absolute sizes.


3. Just getting min/max X/Y values from the G-Code also neglect cutter compensation and maybe other things?.

Yes, including arcs. But I was imagining starting simple and then making the parser more sophisticated as required.

Please Log in or Create an account to join the conversation.

More
8 years 2 weeks ago #118990 by lars

andypugh wrote: Nothing changes. When the component sees the "do your thing" trigger it then loads a copy of the current G-code fie into it's own parser and works out the extents.


Mmmh. Wouldn't that be dangerous in case of a user error? User changes ngc-file, forgets to reload in GUI and checks the boundaries with the component. Component would use the new file and the GUI would execute the old file. Or do the GUIs send the actual file and not the buffered/displayed version?

The module can either work in the current coordinate system, or get all clever and have the parser consider the offsets (read from linuxcnc.stat() and calculate absolute sizes.


I would think that using the current coordinate system may be problematic as the file may switch between coordinate systems. "Getting all clever" would work, of course.

Yes, including arcs. But I was imagining starting simple and then making the parser more sophisticated as required.


Yes. I was just thinking if this was worth all the effort. It's all implemented already at least in Axis. I guess other GUIs do the same. It would be a lot of duplicate work. Of course, I would not complain if there was a cleaner way to get the boundaries. Or even the actual outline while we are at it. :-)

Please Log in or Create an account to join the conversation.

More
6 years 8 months ago #157557 by jondale
This is a feature I use a lot on other lasercutters. I have implemented your solution here on our local hackerspaces laser that runs LinuxCNC. It has come in very handy but I've noticed that any time it is touched off on X and/or Y that the bottom left extent is still the bottom left corner. It still works properly for the top right extents.

The path in Axis shows a path from the homed 0,0 to the touch off point as the first move so I assume this is why. Is there something obvious I'm missing here that would make this feature work properly when touched off.

lars wrote:
This is to check if the coordinates and the fixtures are all setup correctly before starting the actual job. It moves to the bounding box (XY only) of the loaded program, goes around once and then returns to its old position.

It was a feature I liked in bCNC which I used with GRML before switching to LinuxCNC on my new machine.

This is my .axisrc

Code:
if hal_present: boundcomp = hal.component("boundaries") boundcomp.newpin("xmin",hal.HAL_FLOAT,hal.HAL_OUT) boundcomp.newpin("xmax",hal.HAL_FLOAT,hal.HAL_OUT) boundcomp.newpin("ymin",hal.HAL_FLOAT,hal.HAL_OUT) boundcomp.newpin("ymax",hal.HAL_FLOAT,hal.HAL_OUT) boundcomp.newpin("zmin",hal.HAL_FLOAT,hal.HAL_OUT) boundcomp.newpin("zmax",hal.HAL_FLOAT,hal.HAL_OUT) boundcomp.ready() if vars.metric.get(): conv = 1 else: conv = 1/25.4 # this function is called at [DISPLAY]CYCLE_TIME interval def user_live_update(): min_extents = from_internal_units(o.canon.min_extents, conv) max_extents = from_internal_units(o.canon.max_extents, conv) boundcomp['xmin'] = min_extents[0] boundcomp['xmax'] = max_extents[0] boundcomp['ymin'] = min_extents[1] boundcomp['ymax'] = max_extents[1] boundcomp['zmin'] = min_extents[2] boundcomp['zmax'] = max_extents[2]

and this is goes in $SUBROUTINE_PATH/boundaries-scan.ngc
Code:
O<boundaries-scan> SUB (-------------------------------------------------------------------------------------------------------) #<_UseInches> = 0 ( set to 1 to use inches here, or 0 to use millimeters ) #<_TravelFeed> = 3000.0 ( feedrate used to travel to and along the boundaries ) (-------------------------------------------------------------------------------------------------------) M70 ( save current modal state ) G[21 - #<_UseInches>] ( use inches or millimeters as required here, units will be restored on return ) G30.1 ( save current position in #5181-#5183... ) G90 ( use absolute positioning here ) G40 ( turn cutter radius compensation off here ) G94 ( use feedrate in units/min ) G61 ( follow exact path, don't round corners ) ( Move to first corner of bounding box ) G53 G1 F#<_TravelFeed> X#<_hal[boundaries.xmin]> Y#<_hal[boundaries.ymin]> ( Drive around the block ) G53 G1 F#<_TravelFeed> X#<_hal[boundaries.xmin]> Y#<_hal[boundaries.ymax]> G53 G1 F#<_TravelFeed> X#<_hal[boundaries.xmax]> Y#<_hal[boundaries.ymax]> G53 G1 F#<_TravelFeed> X#<_hal[boundaries.xmax]> Y#<_hal[boundaries.ymin]> G53 G1 F#<_TravelFeed> X#<_hal[boundaries.xmin]> Y#<_hal[boundaries.ymin]> G53 G0 X[#5181] Y[#5182] ( return to where we were in X Y) M72 ( restore modal state ) O<boundaries-scan> ENDSUB M2

Then I created a new line under [HALUI]
Code:
MDI_COMMAND = O<boundaries-scan> call
which I have mapped to a button on my pendent.

Please Log in or Create an account to join the conversation.

Time to create page: 0.148 seconds
Powered by Kunena Forum