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.
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.
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.
Martin -
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?
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!
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?
I’m not interested in an argument since I don’t have a horse in the game. My set-up works fine. But for the PWNCNC VFD/spindle package users in the community that might read this, I’m not understanding where you see this as a Buildbotics problem.
I use Vectric (VCarve Pro) w their post processor, OF Buildbotics controller to VFD over RS485. So I have the same M5 commands as Tom, but my VFD (Hitachi) honors the b091 parameter “decelerate to stop” I have set rather than free run stop. The Delixi VFD apparently doesn’t do that and always interprets M5 or S0 as free run stop over RS485. The difference seems to be the VFD, not Buildbotics. Have you heard of this problem with Huanyang VFDs or any others? I don’t think I’ve seen this problem with any other VFD, but I certainly could be wrong.
In the end, the idea is to get the PWNCNC users the best end experience, of course, and Tom’s solution is very helpful for the current situation
To be honest here, I don’t think we have enough information to determine whether it’s a Buildbotics issue or a Dilixi VFD issue. What we have are two black boxes that we’re not privy to peer inside of to determine what’s doing what.
I say that because in looking at OneFinity’s “Tool configuration” screen, you can see a whole list of various VFD’s from various manufacturers. The only reason I can think of why that is, is that because they may all fundamentally do the same thing, it’s the “how” that we don’t know. For all I know there may be a specific “driver” that’s unique to each VFD, so at this point it could possibly be either a bug in the Buiddbotics box or a bug with the Dilixi VFD. A driver is basically a translator that translates the language of one device to the language of another device. It’s like a printer driver for your PC…if you don’t have the right driver installed, the printer doesn’t work correctly.
I just don’t think there’s enough info to determine where the issue is at this point. What we DO have is a workaround.
Yes, you’re right. I suppose it could also be something with the Buildbotics controller in which it can’t fully speak the language of certain VFDs. Either way, your solution is a good one
