Open DougCoffland opened 4 years ago
12/28/10 -A second customer has asked for this via the forum.
I was just thinking about this and remembered that the controller will check to see if the loaded g code will go past the max extents of the machine and give the over flag on the axis in question.
seems like you could use that to make a box in x and y pretty easily with the info the controller already calculates.
I put together the attached python script for making the g-code for a bounding box but I don't have the slightest clue how to implement it in the controller.
I would welcome any help on implementing it!
I've created a new firmware release which sets bounds variables in GCode v0.4.13-rc6 You can upload the firmware via the ADMIN -> General
page.
G0 X#<_x_max> Y#<_y_max> Z#<_z_max>
Go to the farthest corner.
This is super cool! Now we need the macro button to get the full effect where we can check all boundaries in sequence without typing. For now I added it to my start sequence with a message to ask if it'll fit. Really digging your platform!
G0 X#<_x_min> Y#<_y_min> G0 X#<_x_max> Y#<_y_min> G0 X#<_x_max> Y#<_y_max> G0 X#<_x_min> Y#<_y_max> G0 X#<_x_min> Y#<_y_min>
The variables don't seem to update when switching to a new program. When moving from a custom program back to buildbotics demo it still gives me the same bounding box from the previously selected program.
I'm 0 for 2 today. After a long power cycle (had to rewire the touch probe for a new setup) this seems to be working. I had previous hard power cycled so not sure what changed, but this seems to work as expected now. Sorry for the noise!
Seems it's due to simulation. If I wait for the simulation to complete, it works. Just a good note for others.
Also I've noticed the simulation seems to be using the absolute Z height as a starting point Buildbotics Controller - Web interface.pdf and not the offset, making the depiction very inaccurate, and even messing up the over/under warning on the control page. Given my 0 for 2 status today this could be a "me thing" but it seems consistent even after a long/hard reset.
I'm on 0.4.13rc6 to add context. I do not recall this issue previously though I cannot be certain it's new.
Yes, the simulation has to complete before the controller can know the bounds of the GCode path. Only by running the GCode can it know where the tool will go.
Makes total sense. I think what was happening before the reboot is previously simulated code wasn’t filling the variables. Seems to be working now, will let you know if it happens again so we can troubleshoot. Thanks again for this feature!
@jcoffland Just wanted to say a quick thanks again for this! It came in super handy today, avoided 2 clamping crashes and one slightly over material cuts. Working awesome (now that I'm patient enough to wait for the simulation to complete).
Also wanted to add that this works great for me!
Only thing now is to either have a button to run the fixed gcode parameters or allow for custom M codes
A customer has requested the ability to press a button and have the machine physically move through the bounding box around the extremities of the G-Code program. The idea is that the machine would do an air-cut rectangle on the bounding box around the current program.
The purpose is to determine whether there are conflicts with clamping devices, so he can adjust his clamps before actually running the program.
This was a feature that he had on his old controller.