I have a PWNCNC spindle which I absolutely love.Once you use a spindle, you’ll never go back to a router. It has one slightly annoying issue and that is the protracted time it takes to spin the spindle down to a complete stop after a carve/cut or tool change. It can be 45+ seconds.
If you’re using Vectric and have a PWNCNC spindle, this time can be greatly reduced by editing the post processor file and adding a few lines of code.as shown in the attachments. Spin down time can be reduced from 45+ seconds to less then 6. Huge improvement!!
Logically one would think this code could be inserted from the OF Settings under “Tool Change” or “Program End” but that doesn’t work because that code is actually executed outside the G-Code that processes your carve. The code needs to be inline with the G-Code processing your carve and that’s what the post processor does.
If you’re having this issue, take a look at these files or import them into your Vectric software.
Onefinity (inch) (!.ngc).pp (4.8 KB)
Onefinity (mm) (!.ngc).pp (5.0 KB)
Add a braking resistor to the VFD
According to PWNCNC - who supplies the spindle I’m using, braking resistor doesn’t work with their product on a OF cnc.
Besides, why add hardware when 3 lines of G code gets the job done.
If you want plug-and-play, upgrade your enclosure to V5. Otherwise you can wire it yourself if you have a V4 (or likely any enclosure version) with the same Delixi VFD.
The braking resistor bleeds off extra power/heat (energy) and works regardless of your GCODE. So if you can modify the GCODE to slow down the spindle, the braking resistor will just make it slow down even quicker.
What controller are you using? The first link mentions the older OneFinity Buildbotics. The second mentions the third party/OpenBuilds BlackBox controller. Is the information on PWNCNC mixed up? BlackBox isn’t the same controller as BuildBotics.
I don’t have any experience with either of those controllers as I’m running Masso, so I don’t know how their settings tie into spindle control at all. Just that a braking resistor universally allows a VFD to expel excess energy generated by the spindle as it slows down.
I think you may be mixed up.
Both articles clearly state “Buildbotics” controller which is commonly referred to as “black box” because the controller is packaged in a black box. It is the controller supplied by OneFinity before the recent introduction of the Masso controller. The Buildbotics (black box) controller uses RS485 to communicate with the VFD and control the spindle speed and activation…it’s all digital. This is more of an industrial form of interface not commonly found on hobby grade CNC’s, which use a 0-10 volt signal to control the spindle. It is electrically different in many ways and one does not equal the other. Even though both methods of interface do the same thing, it’s how they do it is what’s different and what works with one type of interface doesn’t necessarily work with the other. That’s where the issue is, as pointed out by PNCCNC’s web website. The braking resistor works with all the other machines they’ve tested EXCEPT those using the Buildbotics (black box) controller. I reported the issue of long spin-down time several months ago but there was no solution in sight to resolve it. I just happened to do a deeper dive and found that adding 3 lines to the post processor significantly shortened the spin-down time to under 6 seconds. It’s a workaround that I thought I would share for those of us who are using the Buildbotics controller.
No one’s trying to downplay your effort and your contribution, so don’t take it that way.
As “BlackBox” is a trademark for a specific product maybe you see how PWN’s page above is misleading. I’ve never heard anyone call the BuildBotics controller that, but I don’t follow BB threads here.
My PWNCNC VFD, in manual mode (which works without a controller), can use a braking resistor. I didn’t get the braking resistor from PWN nor did I consult them on how to wire it. Its second benefit is absorbing any back-fed power generated by the motor as it’s stopping, possibly causing over-voltage and damaging the VFD.
Understood, and thank you.
Would love to implement breaking resistor, that would be a simple solution but unfortunately doesn’t work with Buildbotics and spindle. It’s not a show stopper in any event as much as it’s a minor annoyance to have to wait so long for the spindle to wind down. Any solution is better than no solution.
Apologies if I’m missing something obvious here, but reading through this post made me curious. I use OF Buildbotics controller, Vcarve, a Hitachi VFD controlled through RS485 and Chinese spindle. When I set up the VFD two of the first basic parameters were spindle acceleration and deceleration times. Default 10 seconds.
I’ve left it at default for now so it takes 10 seconds to get to 24K RPM and then 10 seconds from 24K RPM down to zero. Are you not able to set acceleration and deceleration times in the VFD? I don’t see what it has to do with Buildbotics, Vectric, Gcode or postprocessors.
You’re correct about the Acceleration/Deceleration parameters. PWNCNC sets theirs to 6 seconds but that only seems to be honored when a speed change is issued from G-Code, ie: S22000 → S15000. If the speed change is set to S0 or M5 (spindle stop) the spindle free-spins to 0rpm, which takes several 10s of seconds. It acts as if you pulled the power plug from the spindle. VCarve writes an M5 near the end of their G-Code to stop the spindle and also where there is a T4 (tool change).
The change to the post processor file is this:
“S100” - Change spindle speed to 100RPM. Just an arbitrary reasonably low number
“G4 P5.5” - Pause execution of G-Code for 5.5 seconds to give VFD time to execute speed change
“M5” - Stop spindle
The pause (G4) is required because if M5 executes directly after S100, it seems to cancel the S100 and the spindle free-spins to zero rpm from whatever rpm it was spinning at, which takes a long time.
With the pause, spindle speed decreases to 100rpm in ~6 seconds. Then a spindle stop (M5) executes which causes the spindle to free-spin down to zero from 100rpm. This only takes a second or less.
This will make your head itch, but these have been my observations.
The Buildbotics controller provides a place to insert G-Code which can execute at the start of a program, at tool change and at the end of a program. These macros can be found under the “Settings” menu. I’ve tried to install the above code there but couldn’t get it to function. Installing it in the post processor causes the code to be copied directly into the G-Code that VCarve generates.
There might be a better way to achieve this, but at this moment I don’t know what it might be.
Oh, One other thing…Let me be clear…Everything I describe here only applies to OF CNC equipped with Buildbotics controller configured for Omnibus over RS485 and using PWNCNC VFD and spindle. If you have any other hardware or configuration, none of this may apply.
Ok, Tom, thanks for explanation. So it’s a quirk with how that particular VFD handles M5 and spindle “0” commands. I haven’t heard of any other VFDs doing that, but maybe there are some out there. I believe they’re Delixi brand, right? Seems like an odd way to design the VFD if there’s no user way to change that.
I’m sure PWNCNC would have figured this out by now, but are there no other parameters that would influence that action? Nothing like below?
Either way, sounds like you have a good and creative solution to make it work for the time being.
Yes, You are correct on all counts!
VFD is Delixi and PWNCNC is aware of this peculiar behavior. I just discovered a bandaid to get around the peculiarity.
I’m going to check out the “Stop mode selection” you sent me…that sounds awfully similar to the issue I’m having. Not sure that’s an option on Delixi.
I suppose probably not too likely or one of the smart people around here would have already found that setting, but doesn’t hurt. It’s always interesting to go through the VFD manual anyway and see what parameters are available. I’m assuming this happens as well when you go on manual control and push the stop button on the VFD panel? Good luck!
Delixi VFDs have that too and it defaults to the deceleration option which is also needed when you have a braking resistor.
I combed through the manual on the Delixi VFD and sure enough, there’s a parameter as you pointed out:
It was set to default to “0” which should use “Deceleration” in lieu of “Free Stop”.
I tested the spindle in manual mode and it worked precisely as you suggested. Just for sanity, I changed it to “1” and the spindle did a “Free Stop”.
Works exactly as you pointed out.
Just doesn’t work with OmniBus over RS485.
Further down in the manual they describe some parameters that can be sent from the controller (Buildbotics) that, the way I understand it, can change the “Stop Mode” characteristics on the fly. I don’t know if Buildbotics is doing this and I don’t have a way to sniff the communications between Buildbotics and VFD to verify what is actually going over the line.
I think my hack is going to have to stand for the time being.
I don’t think Daniel at PWNCNC would have missed this and has more than likely already been where I’m at now…he’s a pretty sharp guy.
Hey, Just want to give you a big thanks for helping out on this. It’s been very educational.
Yeah, that’s strange that it wouldn’t apply the P1.0.16 setting only when getting a stop command from Gcode over RS485. I took a quick look at the manual on the PWNCNC site. VFDs are tricky enough, but the non-native English takes it to another level!
The RS485 communication looks like it allows “Shutdown By Speed Reduction” which seems to be the same as a deceleration stop, but apparently the M5/S0 commands make the VFD respond as “Free Stop” instead no matter what. Doesn’t seem like the user can change that communication, although I’m not a VFD expert.
This parameter looks interesting. Apparently you could set P5.0.01 to “1” and use the stop key on your VFD panel to stop the spindle even while using RS485 communication. But I doubt you would want to have to push a physical button frequently.
I believe the OF controller can also control VFD/spindle run/stop, direction, and speed through pins 15,16, and 17 on breakout board
as a PWM signal insead of RS485, but whether or not that would solve your “stop” problem I don’t know, and would take some work to set up. Probably not worth it.
In the end, I’m sure you’re right and Daniel would have come up with a solution already if one existed for this VFD. I do think it’s an oddity of the VFD though, because I use a very similar set-up to what you do with a Hitachi VFD, and haven’t ever had this issue.
And your solution is great
. Just a bit annoying with all the complex parameters in the VFD they overlooked such a basic function over RS485.
Yes, I believe you’re right about setting up VFD to utilize PWM. Matter of fact, I believe RS485 requires an optional board to be installed in the VFD.
The VFD manual is written in Chinglish. Haven’t heard of that language yet?
Yes, adds a couple layers of interpretation - good for Daniel slogging through those things