Problem: _current_tool values when using M6 Macro #1422
Comments
|
I can reproduce the problem. I will work on it when I get a chance. |
|
I made a mistake in my test. I meant to send M6T6. Here is the result. It looks OK to me. The Q value in M61 must be a positive integer. https://linuxcnc.org/docs/2.8/html/gcode/m-code.html#mcode:m61 I can add code to give an error in that case. |
|
I can no longer test this as my fluidNC board was exposed to my stupidity. To test this properly a M6 macro should be created that displays the current and selected tool At the start of the macro these values should be different. Selected Tool being the tool about to be loaded and current tool being the tool in the spindle... Traditionally my M6 Macro would do a M61Q<_selected_tool> to update the current tool on successful tool change... Selected too should be updated with the T# so the macro knows what tool to grab. |
|
You should not need to do an M61Qx after an M6. Look at last console session. M61 is used to set the tool number without doing a tool change. I only use M61 when I turn on my machine and the tool is already installed. It lets FluidNC know what tool is there. FWIW: M6 and T are separate commands, even if they are on the same line. T2 if the same thing as M6T2 M6 Is not the same. |
|
Okay so how does fluid know that the tool change was successful and to update the current_tool? I ask for M6T2 it should call my macro saying current-tool is the loaded tool and selected tool is 2. At some point I need to tell fluid the tool change was successful or halt the script and let the user take the appropriate actions to fix any issue. |
|
Yes T2 is a separate command and should be setting selected_tool |
|
From the linuxcnc docs: #<_current_tool> - Return number of the current tool in spindle. Same as #5400. |
|
It is probably best to let FluidNC handle the non failure case and you handle the failure cases. The failures cases are probably pretty complicated. The machine could generate an alarm (hard limit, probe fail), you could manually do a reset or the macro could generate an alarm. In many cases the macro will have been aborted. You will need to manually reset things How are you detecting the failures. |
|
So the m6 script is question is for the RapidChangeATC. It has a break beam sensor and we check to make sure the nut has either loaded or unloaded properly and currently issue an alarm on failures. Traditional on success I set the current_tool using a M61Q as it was meant to update current tool while T was meant to update selected tool. No matter what current_tool shouldnt be updated till the script completes and not before hand. |
|
|
If the tool can’t be loaded/unloaded an alarm is thrown. In case of failure, to my point of view values should stay the same before calling the macro as the alarm must be handle by the user. What’s your opinion on this ? Best |
|
Lets be honest on an alarm they are going to have to restart their program. that is my thoughts on it... Right now I couldn't tell you what the values are as I stated I toasted my FluidNC controller. |
|
I don't know. It depends on the state. What if the tool is picked up, but fails on toolsetter probing. You have the right tool, but are in alarm. Machine generated failures are harder to handle than macro generated failures because you can still send gcode before the macro generates the failure. We might be able to detect the failure of an ATC macro and do one common thing. More than that and you would have to use the class method. |
|
Bart, I'm a bit lost, sorry. According to you how should we handle those variables in a m6 macro ? I'm curious to read your suggestions on this. there is no generic way to handle that ? Thanks ! |
|
Just a thought. If the tool change is being handed over to the macro shouldn't the macro be the one to update current_tool or stop the script if something goes wrong.... or at a minimum have a way of informing fluidnc that it was successful. I don't think that behaviour should be part of the firmware. You are handing over the tool change functionality to the macro. |
|
This is a complicated issue. We also have to deal with our ability to change spindles via M6. A macro cannot do that by itself. We will need to think about our options. It will not be a quick fix. |
|
I wouldn't of thought multiple spindles would of mattered as they would have their own m6 script or use the internal handling. |
|
See this PR |
|
Hi Bart, I've tested out this PR and it works flawlessly! Changing spindle works also, it just needs to take care of current_tool when coming from a laser for example but that's the job of the M6 macro. Starting with a tool set at -1 is also a good point as it requires to call M61Qx before starting. Really appreciate your work on this ! |
|
@rvalotta are you able to test this? Let me know if you have any questions. |
|
@bdring Sadly no... I used my superpowers and managed to release the smoke on my fluidNC on one of the io modules and the ESP and just replaced it with a controller i had on hand. I have been working with xspy69 to make sure it works as its suppose to |
|
Just thinking out loud here more so people are aware than anything else Spoke with xspy69. His setup is a spindle with a m6 macro and a laser without a macro (tool 50). As he explains it When he switches from the Laser back to the spindle it is saying current_tool is 50. which is fine as long as they put the tool that is in the spindle away before switching to the laser or their macro makes sure the tool number for current tool is within range of the atc.. In my case it would trigger a manual tool change as the tool number is outside the valid pocket range. I don't think their is anything that can be done in the core to rectify this. I would suggest a note on the wiki for m6_macro saying if they are going to be switching spindles to ensure they only handle valid tool ranges or something to the like or if the tool has no m6 macro it sets the current_tool to 0. Maybe even disallow a spindle change is the current_tool is not 0 to make sure its unloaded? Anyways that is just some thoughts but as it is now it is working wonderfully... Thankyou |
|
The M6 macro will only be sent to the tool that has the selected tool within its range. Assume you have a VFD ATC spindle with tools 0-99 and a laser with tools 100-255. The laser has an active lens cap. If you want to sculpt a part with the spindle, etch with the laser, then cut out the part with the spindle, you would do something like this.
|
Wiki Search Terms
atc / M6 / M61Q
Controller Board
6x controller
Machine Description
CNC router XYYZ, external drivers, VFD, Laser
Input Circuits
No response
Configuration file
Startup Messages
User Interface Software
No response
What happened?
I’m trying to make use of the new variables introduced in 3.9.3 but I’m facing a strange issue.
Testing procedure :
Result : current_tool equals selected_tool ( y value) at the beginning of the macro, so no tool changed is performed.
I assumed that _current_tool should be manually updated by the user macro in that case.
Last thing, when I sent a M61Q-1 the spindle was changed to my laser (tool number 50 in the yaml).
Best
GCode File
(debug, begin Selected Tool: #<_selected_tool> - Current Tool: #<_current_tool>.)
Other Information
[10:47:58] [ ] [MSG:INFO: 10V spindle changed to tool:1 using m6_macro]
[10:47:58] [ ] [MSG:INFO: 10V spindle run macro: $SD/Run=tc.nc]
[10:47:58] [ ] [MSG:DBG: Macro line: $SD/Run=tc.nc]
[10:47:58] [ ] [MSG:DBG: DEBUG, begin Selected Tool: 1.000000- Current Tool: 1.000000]
The text was updated successfully, but these errors were encountered: