- Posts: 90
- Thank you received: 0
Possible bug or other issue
- yoshimitsuspeed
- Topic Author
- Offline
- Premium Member
-
I was machining this part with a bullnose cutter doing a 3D pocket. I also did the outside profile to see how it did with the bullnose but it was struggling so I went into CAM and selected a 7mm flat mill that I have used before.
I post processed the toolpath and went back to my machine and it said that the new program exceeded my y travel. I came back in and looked everything over, ran a simulation and posted it again. This time I could see the toolpath in the viewer starting maybe 100mm or so further -y than it should have. Sometimes when I open it in linuxcnc it seems to show that line, other times it doesn't.
I restarted and rehomed linuxcnc and it still did it. Restarted the CNC computer and then linuxcnc and it still did it. Restarted fusion360 and it still did it.
I have scanned through the code and I don't see anything that suggests that it should start where it is.
So first question is does anyone have any ideas or input?
Second question is whether anyone else is seeing the same issue on their linuxcnc?
The issue is right at the beginning of the code.
N65-70 drops down outside the machines travel and then N75 is a long line on the visual display going from 100mm away from the part over to the part.
Please Log in to join the conversation.
If you are having a Z issue, is your linuxcnc setup with a tool table for length compensation? if not, line N60 is going to mess you up.
as far as Y, are you setting your part origin at the same location in fusion as in reality?
Please Log in to join the conversation.
- yoshimitsuspeed
- Topic Author
- Offline
- Premium Member
-
- Posts: 90
- Thank you received: 0
Yes the origin is on the corner of my stock. It shows it's proper location in both F360 and in the view in linuxcnc.
It's just trying to start very far away from the part.
If I go out and mess with it today I'll see if I can get a screen grab where you can see the toolpath starting very far away from the part. But there is nothing in the code that would cause y to want to start ver far away from the part is there?
I am a noob at code but it seems to me it is saying to start at +22 which in this case would be directly over the part.
Please Log in to join the conversation.
or a shortened version again full gcode so that it can be run and show the errors
this is difficult without seeing the full code , so that it can be simulated and tested
Please Log in to join the conversation.
There are all sorts of things I am suspicious of, this bit for a start
Why is it moving Z to machine 0 and how does it know that is safe?
Normally the tool is touched off at G54 Z0 and a safe G54 height set for start and inter cut moves
G40 was not called on startup, so any existing compensation could persist
G43 is only applied AFTER a linear move has been made with the new tool installed but adjustment not made
The toolchange is unnecessary anyway, you can just touch off with the tool you will be using throughout and know it is right.
Attachment not found
Where is your machine programmed to do its toolchange?
What is the tooltable like?
(Why do you have a toolchange at all, when you use the same tool throughout?)
As you can see from the screen shot, the origin seems quite sensible and everything is within limits on my sim.
regards
Please Log in to join the conversation.
yoshimitsuspeed wrote: N65-70 drops down outside the machines travel and then N75 is a long line on the visual display going from 100mm away from the part over to the part.
Is there by any chance a Y-offset in your tool table?
Please Log in to join the conversation.
- yoshimitsuspeed
- Topic Author
- Offline
- Premium Member
-
- Posts: 90
- Thank you received: 0
First I'll report on the problem then try to answer a couple of the other questions.
It was in fact an offset in the tooltable. It is strange because over a period of time I had added tools into it manually with more information in the tooltable but when I opened it today there was only one tool that had the tool info like I had added manually for many others in the past. Then tool 13 had a 154mm offset on y or something with no other information. Had I manually added it then it would have had more information in the comments section but it just had a date like all the rest.
I am a little confused though because if it was a y offset then wouldn't the whole toolpath have been moved in that direction as opposed to just the starting point of the z drop?
Attached is a pic of the toolpath in my system.
A couple other things. I removed the offest in the toolpath, opened another toolpath, acknowledged the tool switch then opened the problem file again and it still showed this messed up toolpath. So I closed linuxcnc, ran system updates, re opened linuxcnc and then opened this file and it showed up fine and started a dry run and everything looked normal. For troubleshooting purposes I probably should have tried restarting linuxcnc without updating so I don't know if the update had any effect. Something about the linuxcnc toolpath something or another was updated.
So whatever the case it does appear to be fixed. It does seem like it must have been related to the offset in tool 13. I just can't figure out what happened to my manually entered tools or how, why or when that offset would have gotten there.
I wouldn't have suspected that because as said above I would have expected it to move the whole toolpath. Is that not correct?
Please Log in to join the conversation.
No, the machine bounding box will move, but the toolpath stays in the same place.yoshimitsuspeed wrote: I am a little confused though because if it was a y offset then wouldn't the whole toolpath have been moved in that direction as opposed to just the starting point of the z drop?
You can try this by using the touch-off button in the Axis GUI. Touch-of Y to 150 After selecting T for tool table in the drop-down and the tool will move, the bounding box will move, but the tool path will stay in the same place, because the actal XYZ numbers stay the same. You then need to re-edit and re-load the tool table, though.
I removed the offest in the toolpath, opened another toolpath, acknowledged the tool switch then opened the problem file again and it still showed this messed up toolpath. So I closed linuxcnc, ran system updates, re opened linuxcnc and then opened this file and it showed up fine and started a dry run and everything looked normal. For troubleshooting purposes I probably should have tried restarting linuxcnc without updating so I don't know if the update had any effect. Something about the linuxcnc toolpath something or another was updated
After editing the tool table you have to explicitly re-load the tool table (option in the File menu).
Please Log in to join the conversation.
- yoshimitsuspeed
- Topic Author
- Offline
- Premium Member
-
- Posts: 90
- Thank you received: 0
ArcEye wrote: I cannot see a problem with the code per se, albeit there is a lot in there that is far from ideal, typical CAM output.
There are all sorts of things I am suspicious of, this bit for a startCode:N10 G90 G94 G17 G91.1 N15 G21 N20 G53 G0 Z0. (2D CONTOUR1) N25 M9 N30 T13 M6 N35 S8000 M3 N40 G54 N45 M8 N55 G0 X-27.759 Y22.695 N60 G43 Z15. H13
Why is it moving Z to machine 0 and how does it know that is safe?
Normally the tool is touched off at G54 Z0 and a safe G54 height set for start and inter cut moves
Unfortunately this is the gcode straight out of fusion360. There was a thread on here a while back where someone from f360 was trying to get input on their software and gcode generation. There wasn't much interest or response from this community and the few suggestions that were made like changing the name from EMC to linuxcnc in F360 were ignored.
As to moving Z to 0 I have no idea. This actually messed me up good and crashed my machine initially. I don't know why but while setting up my machine I couldn't get Z to be up. Presumably just didn't get the right combination of inputs in the settings as I do have it corrected now. It ran fine with the first few CAM programs I ran though, then first time I ran Gcode from F360 it drove the cutter straight into the bed trying to go to Z0 at the bottom. I did have a thread on here about that a while back and you or someone else brought up the same concern. I brought it up on the F360 forum and they insisted this is normal behavior and a fairly standard way of doing it. So I just fixed my machine and set it up to work with their way of doing it.
ArcEye wrote: G40 was not called on startup, so any existing compensation could persist
G43 is only applied AFTER a linear move has been made with the new tool installed but adjustment not made
The toolchange is unnecessary anyway, you can just touch off with the tool you will be using throughout and know it is right.
No idea on that either. Perhaps for auto tool changers?
I don't know but I can be a bit of a space cadet sometimes so honestly I don't mind it stopping and saying to insert the tool at the beginning. It makes me double check my tool and whether I touched off everything properly.
Once it requests the tool switch once it doesn't again until I run a program with a different tool.
If anyone is interested in checking out F360 CAM or it's gcode output you can get f360 as a private user for free.
Or if we should start a thread discussing it or even if you had general notes that I could pass on to their dev team to be ignored by them I am happy to do so.
Please Log in to join the conversation.
- yoshimitsuspeed
- Topic Author
- Offline
- Premium Member
-
- Posts: 90
- Thank you received: 0
andypugh wrote: After editing the tool table you have to explicitly re-load the tool table (option in the File menu).
Okay thanks. I didn't do that so that would explain why it didn't work till I restarted.
Please Log in to join the conversation.
