Cycle Start from Settings Page

[EmpyreanCNC]

I've found that pressing cycle start with a tool path loaded while the settings page is open leads to nothing happening until you click off the settings page. I'm not sure if this is a bug but it does feel a little opaque and I did nearly have an accident with it. Here's a video with this behaviour. https://www.youtube.com/shorts/1zC--DzN6R4
using ioSender.2.0.43

[andrewmarles]

What I have seen is that when the controller gets a CYCLE start via either real-time command (0x81) or from the pin it is essentially buffered and will be reported on the next real-time report (?)

With IOSender this means that you can get a situation where the sender has stopped sending its periodic ? command and so its processing of the 0x81 is delayed beyond what the user is expecting.

Just my own impression of what is going on. I have not looked at this with autoreporting enabled as that might make the behaviour more intuitive?

[phil-barrett]

Hmmm, agree that isn't a good thing. What do other Grbls do? What happens with other GCode Senders?

This is an unexpected behavior and should be disallowed/prevented. Even though it is unlikely to happen, it is not impossible.

[terjeio]

I've found that pressing cycle start with a tool path loaded

I assume this is a cycle start button that is connected to the controller.

With IOSender this means that you can get a situation where the sender has stopped sending its periodic ? command and so its processing of the 0x81 is delayed beyond what the user is expecting.

Correct. Note that the controller itself will handle the cycle start when streaming from the SD card, either when in feed hold state or when waiting for it in the tool change workflow.

I have not looked at this with autoreporting enabled as that might make the behaviour more intuitive?

ioSender disables auto reporting when in control so the behaviour should be the same.

What do other Grbls do?

When cycle start is pressed it is added to the real-time report in the Pn: element just as grblHAL does. IIRC a difference is that grblHAL will report it even if the key is not pressed when the report is prepared. With Grbl it is a hit/miss - if the button is quickly pressed it might not be included.

What happens with other GCode Senders?

I do not know, my guess is that most ignores it since not many users connect buttons to the feed hold/cycle start inputs?
ioSender obviously acts upon receiving the cycle start and IMO should continue to do so - but not when tabs are shown that cannot be used to start a loaded program. I'll try to fix this somehow - likely by telling the protocol parser to ignore cycle start in the first message received after leaving such tabs.

[phil-barrett]

Hopefully it isn't a hard fix. Part of Grbl growing pains.

[terjeio]

New edge versions uploaded that hopefully fixes this, or at least minimizes the risk. Please report back if anybody is able to replicate the issue - and then with exact details on how to do so,

[EmpyreanCNC]

New edge versions uploaded that hopefully fixes this, or at least minimizes the risk. Please report back if anybody is able to replicate the issue - and then with exact details on how to do so,

Thanks! I'll give it a check tomorrow

[andrewmarles]

This is what we found working on the SLB with IOSender 2.0.42:

While a job is running:

1. Halt a job using the macro buttons
   grbl.enqueue_realtime_command(CMD_RESET)
2. Cycle start using the macro buttons
   grbl.enqueue_realtime_command(CMD_CYCLE_START)
3. Unlock the machine in iosender
4. The file will restart running and eventually come to a stop

I believe that Sienci plans to handle this in gSender. I am sure we can get you an SLB if you feel it is helpful.

[terjeio]

While a job is running:
1. Halt a job using the macro buttons
grbl.enqueue_realtime_command(CMD_RESET)
2. Cycle start using the macro buttons
grbl.enqueue_realtime_command(CMD_CYCLE_START)
3. Unlock the machine in iosender
4. The file will restart running and eventually come to a stop

The latest edge build woks as it should, I'll try to prepare a release during the next few days.
I have also looked into changing the logic behind this on controller side but decided not to since it would, IMO, make it ambiguous.

I am sure we can get you an SLB if you feel it is helpful.

Yes, I think it would be.

[imechura]

Not sure if my issue is related to this or not but my iosender is frequently going in to cycle start without me clicking the button. I cannot leave the GUI up for even 5 minutes if a file is loaded because it will just kick it off and start breaking stuff. I already ruined one touch probe and broke more than one carbide end mill from this issue. I suspected that this was only happening while using the probe tab but that was wrong it happens on the main grbl screen too. Then I suspected it was my touch screen monitor so I unplugged the USB for it and it is still happening. I have since turned the system off and am searching for a replacement as I cannot use it in its current state, I updated to the latest version this evening and the issue is still present maybe happening even more than before.

Now that I am thinking about it, I wonder if its happening because the cycle start pin on my esp32 is not connected to anything. Does the code initialize all of the pins to a pull-up state or are they floating when not connected?

How does the GUI respond when the CS pin is activated on the uc?

Can the CS pin be disabled through configuration?

[terjeio]

Does the code initialize all of the pins to a pull-up state or are they floating when not connected?

For the ESP32 that depends on the pin since not all has an internal pullup. Anyway the internal pullup shuld not be relied upon as it is usually about 50 KOhm which is a rather high value. A properly designed CNC breakout should have an additional pullup with either a RC network or an optocoupler in front of it to minimize the risk of EMI triggering the input. An the swich current should be large enough to provide contact wetting.

How does the GUI respond when the CS pin is activated on the uc?

By starting a loaded program or a probing sequence depending on which tab is open.

Can the CS pin be disabled through configuration?

Not yet, short the CS pin to VCC or ground for now. And the feed hold pin as well if not used.

[imechura]

The issue was solved by shorting the CS pin to GND. Thank you very much for your help.

Ive run into a new issue. Perhaps someone can tell me what I am doing wrong. I am running the following commands through MDI (without the line numbers).
Line 20 moves the machine to its intended target (x=0.4)
Line 40 moves the machine to x=0.0280 and then stops, no errors are thrown
LINE 50 goes back to the correct x=0 location
ink.
So why does G38.2 not move the machine to 0.4? I have been using g38.2 for over 2 years now without issue and now today its flaking out on me. I did upgrade to latest ioSender earlier but this is happening on the older version x.2.2 I think

0010 G0 G20 X0
0020 G01 G20 F10 X-0.4
0030 G0 G20 X0
0040 G38.2 G20 F10 X-0.4
0050 G0 G20 X0

[imechura]

In response to your statement, I am not using any break out boards because the commercialy available ones I looked into initially where designed with integrated stepper drives which where fairly low powered and appeared to be targeted towards DIY 3d printers, I am retrofitting VMCs and other 10,000+ pound machines. Maybe there is more reasonable BOBs available now that I should look into. Ive just been using screw terminal boards and building everything else out with standard panel controls on DIN rail.

[terjeio]

So why does G38.2 not move the machine to 0.4?

Step/mm resolution is too low?

Maybe there is more reasonable BOBs available now that I should look into.

There are, a number of boards made for CNC use has proper output and input protection and signal conditioning.

[imechura]

Does G01 and G38.2 interpret the stepp/mm resolution different from oneanother? I had just assumed that the resolution would be the same between G01 and G38.2

[imechura]

I am going to open a seperate thread to continue this.