VFD communication timeout when job is finishing

[gcormier]

I have modbus working well between grblHal and a Durapulse GS20.

With my VFD comms timeout set to 0.7 seconds, I can run the spindle well.

However, when I run a job, when the spindle turns off at the end of the job, my VFD faults on a timeout.

If I change the VFD comms timeout value to 2 seconds, I do not get any errors when the job finishes.

Is there any configuration on my end I need to change? I'm using gSender if that is of any relevance.

Additionally and to be clear, gSender is not error'ing out, nor am I getting an error 14. It is my VFD that is basically seeing a lack of communications on modbus for longer then the timeout value I have specified, and I've told it to fault in this case. It's very nice so that if grblHal has an e-stop, my VFD will also fault out very quickly. Obviously I'd prefer this timeout be as quick as possible in the event of a fault.

[terjeio]

With my VFD comms timeout set to 0.7 seconds,

So this is a setting on the VFD end, not $375 in the controller?

Is there any configuration on my end I need to change? I'm using gSender if that is of any relevance.

Please post your controller settings, I am not able to replicate this on my end (with ioSender). It could be gSender pausing status requests on program end that is causing this, if I send M30 after turning on the spindle and coolant I do not see any delay in requests when using ioSender.

Obviously I'd prefer this timeout be as quick as possible in the event of a fault.

The controller turns off the spindle on alarms, reset and estop so this would only help if the controller crashes or if you want the spindle to stop on sender disconnect or crash. The latter might in fact be dangerous since there may be queued motion that then would potentially be executed with the spindle stopped?

[gcormier]

With my VFD comms timeout set to 0.7 seconds,

So this is a setting on the VFD end, not $375 in the controller?

Correct. $375 is 50ms I believe.

Obviously I'd prefer this timeout be as quick as possible in the event of a fault.

The controller turns off the spindle on alarms, reset and estop so this would only help if the controller crashes or if you want the spindle to stop on sender disconnect or crash. The latter might in fact be dangerous since there may be queued motion that then would potentially be executed with the spindle stopped?

Good point on e-stop. I guess this only matters if there were to be a controller that crashes.

I will try with ioSender, but also I think based on your points, it is less critical of an issue. E-stop's might happen 10% of the time, which is covered. A controller crashing is probably more like a 0.001% occurrence, so the spindle ruining the workpiece less of a concern.