We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
Here’s the scenario:
I have a 2 stage carve to perform here it is for reverence: Easel - 2 stage sample carve
the roughing carve went fine and returned to work origin 0,0.
I swapped the bit and I want to probe, but I want to move the spindle back and right so that I can probe on the board a bit and not hanging over the corner. Like it shows in the photo for probing, with a fully supported probe… :
I finished Probing and the next step is Setting X,Y…
So this is where my actual question starts: I’ve moved it inward a few inches when I probed.What do I do next? Normally I click “Use Last XY Zero” and I run the carve and it works just fine. Would you do something different in this scenario? What and Why?
Here’s what the next screen look like for reference:
.
**Note: I have locked the motors for the bit swap, nothing moved and the X,Y, work coordinates are perfect as they were with the roughing carve. The problem is all contained within Easel and one tiny difference between the first workpiece and the 2nd workpiece in that project I linked. (the 2nd will carve perfect in my scenario, but the first will not)
** BTW I know exactly what’s causing the issue and how it can be fixed within Easel post processor (it’s actually already fixed in the Fusion360 Easel Post Processor, the Vetric Post Processor, and the Carveco Post Processor) … but I want to know other ppls take on my process sequence before I push the issue. Because I’m being told that I’m doing it wrong even though my method works 99.9% of the time. @NeilFerreri1@RussellCrawford@BrandonR_Parker
@SethCNC I don’t use Easel as a sender, but I do know post processing and gcode and tool change procedures. The only difference in the gcode is the location of the peck drill.
What doesn’t work the the second one? I don’t have time to run tests with Easel.
This actually makes the potential issue more likely to occur when one uses a separate sender (I usually do as well), because there isn’t even a prompt there to tell the user to re-position back at work zeros before starting a carve, which is what I was told was the correct process (support email exchange).
What happens is when a drill function is placed at 0,0 is that The Gcode does not re-position to 0,0 before plunging, instead it just plunges wherever the spindle is when the carve is started.
So IF you set X,Y to the front left, then you re-positioned near the middle of the workpiece to set Z zero and then you send the carve, well that 0,0 drill doesn’t happen at 0,0 instead it happens where ever the spindle was when you send the carve… it will then position the remainder of the carve properly, but not that initial drill plunge…
I ended up also running a poll over on FB with about 75 replies so far indicating 90% of them also doing it the “wrong way” (my words as interpreted from an email telling me how to do it the right way) and the way we are doing it will work 99.9% of the time. With that 0.1% problem only happens IF there is a drill placed at 0,0
So if 90% of the people are doing it “wrong” and the “wrong way” works 99.9% of the time. Wouldn’t it be easier to fix the single case scenario of a drill at 0,0 then instruct thousands of users to do something differently than they are used to? Just my opinion on how to resolve an issue, granted its a very small amount of people who will encounter it (who really puts a drill at 0,0 and doesn’t start the carve from work zeros?) , but they will certainly be unhappy when their workpiece is left ruined as a result of something that could easily be fixed… again all My Opinions.
By default, and as programmed by Easel, the gcode in in G90 (absolute position) mode.
If you, or your sender, doesn’t change work zero, there should be no difference between the two workpieces other than the location of that peck drill.
Are you seeing otherwise?
EDIT:
Ran to a PC to clarify. @SethCNC As I suggested, Line #2 in both detail gcode files is G90. That makes sure all moves are in ABSOLUTE positioning mode. It’s the grbl default, but it’s good practice to include it in the header of the file. In both files, peck drilling completes on line #23 with a 25.4mm retract. That is followed by a move (still in absolute mode) to X42.080 Y41.655. That is the same position in both files. The location of the peck drill is irrelevant.
That’s why I asked…are you seeing something different?
Soo, they fixed it and pushed the fix out sometime within the last 9 hours…
This line (green in photo) was not here earlier this morning when I posted a poll into a FB Group, where 90% of the respondents (about 80 people in all) answered with a response that indicated that their carve would have also not gone as intended, the drill would have occurred at the incorrect location.
I simplified the scenario before I posted it over there, and used just a single drill hole…
@SethCNC I gotta be honest…I thought maybe you were crazy.
But…the bug persists.
Your file has the drill point at -0.00, 0.00 and the gcode includes a rapid to that location. G0 X-0.000 Y0.000
If you change the location to 0.00,0.00, it will NOT include the rapid position to start the drill. This is a bug, 100%.
Yeah, and I was basically told to kick rocks, in 2 seperate replies to my very detailed emails with video walk through of the issue…
Then had a different staff member who has a solid head on his shoulders reply to my FB poll then DM me who acknowledged there appears to be a valid bug there and he will carry forward with the issue…
So at this point I’m giving the official support reporting route a rest and allowing him to carry forward.
I mean its not even something that I need fixed for my own uses, its the other users that I’m more concerned about.
