GRBL Hang on PWM VFD

Hey kids - long time?! 4 years, yeesh.

(Move this to ‘Unsupported’ if VFD talk is off limits…)

Anywho, building out a new S3XL and hooking up a VFD to the PWM pins on my board, standard stuff, done it before. Control all works fine, life is grand, except…

Any time the VFD is on, at gcode end, GRBL will hard hang and need to be powercycled. Happens no matter the gcode or PP used (even straight from CC), nor the gcode sender. Running CM521 and GRBL 1.1f.
If I leave the VFD off (either powered off, or just “Stopped”, ie, not accepting PWM input for speed), all programs finish just fine and live to fight another day.

Am I forgetting something simple in the VFD setup? I don’t believe I’ve had the issue with the two other machines I’ve set up this way.

Any help’s appreciated!

Weird…I don’t think it’s anything in the VFD setup, especially since PWM is an input to the VFD / output from GRBL so it must be some indirect electrical effect. Have you tried opto-isolating the PWM signals to see if the problem persists ?

Silly idea of a test to determine what is going on: insert a long delay as the second to last line of G-code (e.g. G4 P60.0) and check whether the hang happens right after the final M5 command that stops the PWM, or at the end of program execution after the 60 sec delay)

1 Like

This was my thinking as well.

I’ll monkey with the gcode, some further testing tells me it’s happening on spindle spool down, so def could be some EMI gremlin. My favorite. I’ll test and report back.

1 Like

so you might want to test various spindle deceleration time values (PD015 on HY VFDs) ?
Well, it won’t tell you WHY it wakes up the EMI Gremlins, but it might allow you to find a workaround.

Read my mind. I’m winding it down pretty fast, and those chinesium spindles are EM dirty to start with.

1 Like

K, lunch hour testing: it’s totally the spool down. M5 will cause a lock up nearly every time. If I let the spindle continue to run, programs all run to closure without issue.
Monkeyed with M031 (braking, def 2.0, tried 1.0 and 0), no effect. I’ll dial back the decel times in a little and see if that helps.

1 Like

One thing you could try while debugging is decelerating in G-code. Instead of a plain M5, do something like:

; Starting at 20000 RPM
S18000
G4 P0.1
S16000
G4 P0.1
S14000
G4 P0.1
; etc...
M5

By no means perfect but at least saves you the pain of dealing with the VFD parameters while you figure it out.

1 Like

Alright… dare I say it, I think I got it. Adjusted my decels (P015,17,19) all to 6 seconds and I think it’s fixed…I had also previously rerouted my PWM pairs away from the USB connection, with no success. I think I’m good. Will still come back later and replace that PWM pair with some shielded wires and properly ground everything too.

Thanks for the quick suggestions gents! I’m working on a new set of post-processors for vCarve for the S3, I’ll post them here in a bit now that I’ve got my test machine happy.

1 Like

This is pretty common. It might be worth looking into a braking resistor for your VFD to take the extra voltage.

I have found shielded wire makes a difference, although making sure the VFD and spindle are correctly grounded will.

4 Likes

@Luke I remember you! :-p

Makes all the sense in the world now I’ve thought on it a bit. I’ll probably throw a diode or two into the mix when I replace the wires carrying PWM as well.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.