bdring / PendantsForFluidNC

Pendants for controlling FluidNC CNC firmware
Other
34 stars 13 forks source link

Turning off spindle in lib/GrblParserC/src/GrblParserC.c #14

Closed ColPaulR closed 8 months ago

ColPaulR commented 8 months ago

Thank you so much for writing this code! Huge amount of work I can just drop into my project.

As I'm using this code with FluidNC, it is picking up the "A:" out of the status line. Unfortunately, when I issue an M5 to stop the spindle, the code does not address this as there are no further "A:" lines reported. If I turn on mist or flood, FluidNC responds at the next frequency with an "A*" message where there is no "S" or "C". However, if neither the mist nor the flood are turned on, the spindle never reports as off.

I suspect if only flood or mist were on and then turned off that the status messaging would not include "A:"

Maybe a status message counter in GrblParserC.c that turns off spindle, mist and flood after several (say 10) messages with no "A:*" reporting? Alternatively, remove the if at line 609 of FluidNC/src/Report.cpp to report "A:" at the required frequency if the spindle, mist and flood are off.

bdring commented 8 months ago

Are you talking about this? "|A:S"

<Idle|MPos:50.000,150.000,52.000|FS:0,1000|Ov:100,100,100|A:S>

That is a weak point in the grbl status protocol.

Would the $G info work for you?

[GC:G0 G54 G17 G21 G91 G94 M5 M9 T0 F0 S1000]

Most senders rarely have a spindle or coolant toggle button because the protocol is weak.

ColPaulR commented 8 months ago

I'm implementing code and hardware to connect a USB pendant (https://github.com/ColPaulR/GRBL-USB-CNC-Pendant) to a FluidNC uart_channel. I need to keep track of the FluidNC state using uart_channel. Your GrblParserC saved me lots of time processing the status messages.

Unfortunately, we don't get notification via the "|A:" response to "?" when something turns off if there is nothing else turned on. I had not thought about also issuing the "$G" query and including that response. As I thought more about the scope of your GrblParserC library, I came to the conclusion that GrblParserC is doing exactly as it should, it is just my overrides of reporting functions that aren't handling the condition when the spindle (or mist or flood) is turned off when nothing else is on.

Thanks for the rapid response and pointing me in a better direction.

bdring commented 8 months ago

If you have report_interval_ms: set in the channel you will get automatic status updates. This includes changes to the modal values.

$report/interval=100
[MSG:INFO: uart_channel0 auto report interval set to 100 ms]
ok
<Idle|WPos:10.000,150.000,52.000|Bf:15,128|FS:0,0|WCO:0.000,0.000,0.000>
[G54:0.000,0.000,0.000]
[GC:G0 G54 G17 G21 G90 G94 M3 M9 T0 F0 S0]
M5
ok
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]

show_gcode_modes(&new_gcode_modes) is called every time the GC report received. You can use that for your project.

ColPaulR commented 8 months ago

Perfect solution. I did include "report_interval_ms:" and "all_messages:" in my yaml. I'm implementing the weak override show_gcode_modes now to respond to this.

When using GC report, will M7 and M8 be mutually exclusive. It looks like you implemented both fields M7 and M8 to the same character pointer "coolant". I believe that *coolant will point to either "Mist" or "Flood" depending on which is last in the GC report. I'll have to test tonight. My setup has vacuum on M7 and air assist of M8. I often use both together. There is some discussion on the LightBurn forum that both together is an allowed configuration with the NIST standard cited.

bdring commented 8 months ago
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
ok
M7
ok
M8
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M7 M8 T0 F0 S0]
ok
M9
ok
$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
ok
MitchBradley commented 8 months ago

You can try #15 . Instead of .coolant, it has .mist ("On" or "Off") and similarly .flood . It also lets you handle the GC report anyway you please by implementing an override for show_gcode_report(const char*); Some aspects of GCode are stupid, for large values of "some".