Losing Variable
28 Oct 2017 10:34 #100917
by Nitram
Losing Variable was created by Nitram
Hi.
I use a G30 to set a Z position for my tool change position.
I did a tool change a few days ago and the tool cycle did not lift the Z out of the way before turning the tool carousel causing a crash (this is what the G30 was doing in the past).
After investigation it turns out that the variable table (linuxcnc.var) had dropped the 5183 offset (G30 Z offset).
I reinserted the offset and carried on.
Today I rechecked the .var files just for interest and the 5183 variable had again been rewritten as 0.0000!!
Lucky I checked as it prevented any crashes, but I am at a loss as to why this variable being sometimes overwritten?
It has persistence as it usually stays in the table but it is worrying that it could simply disappear at random.
I noticed that the linuxcnc.var.bak table had the 5183 parameter as 0.0000 as well although I'm not sure of the relationship between these two files.
Thanks for any help on this issue.
Regards,
Marty.
I use a G30 to set a Z position for my tool change position.
I did a tool change a few days ago and the tool cycle did not lift the Z out of the way before turning the tool carousel causing a crash (this is what the G30 was doing in the past).
After investigation it turns out that the variable table (linuxcnc.var) had dropped the 5183 offset (G30 Z offset).
I reinserted the offset and carried on.
Today I rechecked the .var files just for interest and the 5183 variable had again been rewritten as 0.0000!!
Lucky I checked as it prevented any crashes, but I am at a loss as to why this variable being sometimes overwritten?
It has persistence as it usually stays in the table but it is worrying that it could simply disappear at random.
I noticed that the linuxcnc.var.bak table had the 5183 parameter as 0.0000 as well although I'm not sure of the relationship between these two files.
Thanks for any help on this issue.
Regards,
Marty.
Please Log in or Create an account to join the conversation.
30 Oct 2017 23:42 #101034
by andypugh
Replied by andypugh on topic Losing Variable
I don't know what is going on.
But, is your tool change sequence controlled by G-code? If it is. then I think that in your position I would have the G-code check the value of #5i83 before moving _anything_.
The ...var.bak file is a backup of the .var file, created any time that new values are written to the .var file. So the fact that both have zero is rather interesting. Is it only #5i83 that is being zeroed-out?
But, is your tool change sequence controlled by G-code? If it is. then I think that in your position I would have the G-code check the value of #5i83 before moving _anything_.
The ...var.bak file is a backup of the .var file, created any time that new values are written to the .var file. So the fact that both have zero is rather interesting. Is it only #5i83 that is being zeroed-out?
Please Log in or Create an account to join the conversation.
31 Oct 2017 00:37 #101038
by Nitram
Replied by Nitram on topic Losing Variable
It is hard to tell whether other variables are being zeroed out as all except one are zero anyway. The 5183 is literally the only one (except one other which is a1) which has a non binary value.
I like your option of checking the value of #5183 before a tool change. I also think I should re-write the value of 5183 to the variable table at the start of each tool change macro routine as well (#5183=96.52), as this variable is not dynamic in any way, and thus force the variable to have the correct value each time despite any unknown interim re-writing.
Another option might be to use G53 Z96.52 with the tool change move in lieu of the G30 as it is non modal and absolute for that one move.
Do you have any thoughts as to any preferred option on the above?
Thanks,
Marty.
I like your option of checking the value of #5183 before a tool change. I also think I should re-write the value of 5183 to the variable table at the start of each tool change macro routine as well (#5183=96.52), as this variable is not dynamic in any way, and thus force the variable to have the correct value each time despite any unknown interim re-writing.
Another option might be to use G53 Z96.52 with the tool change move in lieu of the G30 as it is non modal and absolute for that one move.
Do you have any thoughts as to any preferred option on the above?
Thanks,
Marty.
Please Log in or Create an account to join the conversation.
31 Oct 2017 01:03 #101039
by andypugh
Replied by andypugh on topic Losing Variable
I would hard-code it in the toolchange routine if it never changes. I have never 100% trusted G30 even when things are working properly.
I would also suggest setting something else that is meant to be persistent (but which you don't use) to a particular value to see what is going on. It actually sounds like it is possible that LinuxCNC is re-creating the var flle from scratch. Possibly a permissions problem, but I am not sure what sort of permissions problem.
I would also suggest setting something else that is meant to be persistent (but which you don't use) to a particular value to see what is going on. It actually sounds like it is possible that LinuxCNC is re-creating the var flle from scratch. Possibly a permissions problem, but I am not sure what sort of permissions problem.
Please Log in or Create an account to join the conversation.
Time to create page: 0.071 seconds