Bug Report (Master): Incorrect halui.mode pins for manual tool change

More
16 May 2017 10:02 #93255 by hwylie
Since jogging and touch-off are not possible during manual tool change under Master 2.8.0-pre1-3124 (-g565cf0e on which the system was built, and upgrade -gcb74ca8 just installed), HAL watch was used to monitor relevant pins.

Using the intrinsic HAL component hal_manualtoolchange with Axis GUI, incorrect states of halui mode pins are observed while the user is prompted to change the tool manually:

halui.mode.is-auto TRUE
halui.mode.is-manual FALSE

This evidently accounts for inhibited manual and MDI functions during tool change, preventing jogging and touch-off.

The incorrect behaviour was also monitored using Gmoccapy GUI, while the correct state of these pins was verified during manual tool change under the existing operational release (2.5.2 for gantry router with slaved Y1 & Y2 joints).

INI and HAL files are attached, as well as pertinent screenshots which appear to confirm expected hal_manualtoolchange functionality.

While the motion performance and joints / axes functionality of Master are truly appreciated, it will be clear that Master is not usable for any job requiring manual tool change, at present - or have I overlooked a required (new?) pin connection in my HAL netlist?
Attachments:

Please Log in or Create an account to join the conversation.

More
17 May 2017 21:23 #93315 by andypugh
I don't think that this is an error. During manual tool change the system is just paused, but still in auto mode. (And in fact, the next few hours of machining might well be queued up to run, based on the tool offsets read from the tool table, which is part of why tool-touch off at this point is harder than it looks.

Please Log in or Create an account to join the conversation.

More
18 May 2017 00:14 #93322 by Todd Zuercher
Andy is right, for a manual tool change machine, that can not use predetermined repeatable offsets, it is generally better to just split the file up into separate files for each tool rather than one big file with tool changes.

Please Log in or Create an account to join the conversation.

More
18 May 2017 07:27 #93326 by hwylie
Thanks for your responses, Andy and Todd

Your standpoint is appreciated, from the perspectives of tool change algorithm design (consistency for auto/manual change) and system operation - although it may be argued that consideration of tool table offsets, even in the context of Gcode programme portability, is secondary to ease of use for a manual tool change machine.

As posted, the frame of reference was LCNC 2.5.2, unaware when spec for mode during tool change was revised. The possibility to change mode to manual/mdi during tool change (if not intrinsic functionality as in that old release) is still considered desirable.

Splitting CAM postprocessor output into multiple files is clearly do-able with a custom script or app, if an inelegant workaround. Something of a dilemma as a gantry router user for a number of years, considering (from system integrator perspective) that the strengths of current LCNC Master are must-haves!

Writing a new hal_manualtoolchange module is considered, but that of course cannot achieve the objective unless LCNC programme logic allows assertion of halui.mode.manual / halui.mode.mdi / halui.mode.auto inputs to effect mode transitions.

May I suggest consideration - as a desirable feature - that LCNC control logic be adapted to enable user control of machine modes during tool change, in conjunction with evolved hal_manualtoolchange, to emulate that feature of LCNC 2.5?

Warning messages might alert the user to potential risks of invoking manual / mdi modes during such intervention, while existing halui mode request inputs may need to be conditioned to inhibit mode transition during programme pause.

Hoping this perspective will stimulate further consideration
Hugh

Please Log in or Create an account to join the conversation.

More
18 May 2017 08:17 #93328 by andypugh
The built-in behaviour of LinuxCNC hasn't changed between 2.5 and 2.8
It is possible that your previous installation had a modified version of hal_manualtoolchange which did something clever.
I never used it, but do recall that it existed.
Here is the Wiki page for that file: wiki.linuxcnc.org/cgi-bin/wiki.pl?ManualToolChangeMacro

Dewey Garrett has been working on other ways to achieve similar results. There is a "moveoff" HAL component and an "external offsets" experimental branch that achieve similar results in a somewhat less fragile manner.

If you were using the modified hal_manualtolchange with the previous installation and can find that file, then it should still work just as well (and just as badly)

Please Log in or Create an account to join the conversation.

More
18 May 2017 08:49 #93329 by hwylie
Puzzling, the old system is an unmodified 2.5.2 installation (presumably without hal_manualtoolchange substitution) - but will consider the referred 'ManualToolChangeMacro'.

Aware of 'moveoff' component, will take your advice to look at 'external offsets' branch.

Thank you.

Please Log in or Create an account to join the conversation.

Time to create page: 0.082 seconds
Powered by Kunena Forum