New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tool precall bug random tool changers only #330
Comments
On a non-random toolchanger machine (such as sim/axis/axis), when you ask Interp to prepare the currently loaded tool by running I'm not sure what the correct behavior is for a random toolchanger machine. I can imagine two options:
Option 1 is the most similar to the non-random toolchanger behavior, but I think my preference is for option 2. It seems like option 2 makes it easier to implement a random toolchanger correctly, since it doesn't have to special-case pocket 0. Thoughts? Comments? |
I just pushed a branch that reproduces this bug (and verifies that non-random toolchanger machines do not have this bug): https://github.com/LinuxCNC/linuxcnc/commits/reload-tool-330 |
Hallo Seb, unfortunately you are not right with your opinion, that non random tool changers does not have this bug! How toolchange should/must react: How it does work actually: So we have several bugs in the tool change routine. Please take in account three different tool change situations: 2. Rack Tool Changer 3. Random tool changer, i.e. carousel with changing arm If you compare all 3 situations you will find out, that we need to handle the pockets correctly and not use a index of an array in any circumstance. IMHO we do not even need to distinguish non random and random tool changers, as that must be done in the remap or comp file the user uses. There are too many differences between one and the other random non random tool changers, so we will not be able to take care of all situations. IMHO the interpreter or iocontrol should never modify the tool table, except if it is caused due to gcode commands changing offsets. The pocket should never be changed from the interpreter, that is part of the tool-changer or the GUI! chain changers of modern machines do have 200 and more pockets! Seb, are my comments understandable? Norbert P.S. I am not a friend of discussing this kind of bug with possible new behavior on dev-list. I have reported several problems on that list, tried to begin a discussion, but it newer showed any result. just see my posts about the tool number limit. That is why i am trying myself to solve that cases. But this are just work around for my own machines, that will not flow back to the community. IMHO that is a shame. All the above mentioned can be solved with a 100 line python script and 3 additional hal pin, but who will understand that. I think we should work all together and find a clean solution for the three "bugs" at ones (tool limit, pocket handling and wrong reporting to remap). So I am a friend of the sqlite solution rene-dev proposed. |
I just checked Bug 330, bug 400 and bug 409 do refer to tool change problems |
I'm not seeing the behavior you describe. I'm doing my testing on 2.7 with sim/axis/axis. Its tool table looks like this:
Preparing T99999 (by running
There's also this iocontrol parameter, maybe that's what you're thinking of?
|
I think part of the problem is a mix of pockets and tool numbers, just like there used to be the mix of joint and axis. |
@rene-dev you're right, that is confusing. We have three different ways to identify tools: the tool number (what the g-code uses), the pocket number (what the toolchanger uses), and the index into the internal tool table array (what most of the internal code uses). |
Is iocontrolV2 any better? (I have never even figured out how to select it) |
iocontrol is only a very small part of the toolchange related stuff. |
@andypugh no idea. It's terrible that we have two iocontrols. We should clean that up, merge them or something. |
correct me if i am wrong but i through option 1, is what the code is meaning todo as it now, but it fails to do it correct when you prep a different pocket/tool but DO NOT do the change (m6), then it fails to internaly handshake.. as on a random i tend to prep a pocket early normaly on drive on line. this is where i found the issue when i restart or rerun a tool g code section as the next pocket is preped but not needed as such.. so i think a quick fix to fix this issue if someone knows the workings better.. or the IOv2 i looked over quick, and it looks to be alot better throught out for all changers in question. as it also allows one to prep a pocket while doing motion which you can not do right now, i dont know why but its not possible as motion is halted untill you do a preped signal hand shake.. |
iocontrol 2 can be used by changing io to io_v2 in the ini. Seb, if each tool number has the same pocket number as the tool, all is ok, just test with
T1 will be OK , T2 not and try a T70 M6 Norbert |
sorry, I do not know why inserting the code does destroy the file |
@gmoccapy I edited your comment and replaced the "`" characters with the sequence: "~~~~~" |
Just as lets-step-back-question; why does linuxcnc need to know about the pocket position at all? Does IO-control-v2 allow for encapsulating the details of pocket position? In this way we could make sure random and non random tool changing works while allowing expanded tool info details, and any weird toolchangers. |
@gmoccapy The reload-tool tests I just wrote use a tool file like the one you pasted, where the tool numbers differ from the pocket number, and the pocket numbers differ from the "index" in the tool file, and all the numbers are out-of-order. And those tests pass fine on 2.7 and master. So I'm still unable to reproduce the problem you're describing. I see that you're using local modifications to LinuxCNC. Try to reproduce the issue on a stock version, and open a new issue for it if so. |
Hallo seb, just changing a few lines in iocontrol seem to have fixed the pocket handling part. We still have open, that we can not handle more than 55 tools, Have you tried the tool.tbl I posted. Try to load T70, you will get an error. And the remap bug is still there. I will comment on that isue. Norbert |
This only happens on a machine with random changer turned on(from setting ini value). machins with a non random do not see this bug
when running pre called tools on a program or MDI command but you do not follow it with a M06 , the next time you run a Txx and M06 line, if the tool call is the tool already in use/spindle then the M06 is performed when it should not be. putting the wrong tool into the spindle and the program will continue to run..
if you do not run pre calls then this bug is not seen. but defeats the object of random with pre calling.
Here are the steps I follow to reproduce the issue:
run this problem
N1 g91 g28 z0
N2 t1 m6
N3 t2 g90 g00 g43 h1 z100. (abort here or after it)
N4 g04 p20.
N5 g91 g28 z0
N6 t2 m6
N7 m30
if you run this program, abort on line 3 or 4t, then re-run from N1, the tool 1 will be changed for Tool 2
the T1 & M6 should be skipped as we already have T1
on a non ramdon tool changer machine this bug is not seen running this same program
checked on current stable 2.7.11 & 2.8-Pre, above happens
The text was updated successfully, but these errors were encountered: