We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
I have been tinkering with using G-Sender instead of Easel to send g-code to the XCP. When I create a toolpath in V-Carve I use “x-carve inches” to save my g-code. After that I load the file into G-Sender, home my machine, set my work zero, zero my Z with the probe, and hit start. The spindle spins up but it seems as though it jumps right into the carve before the spindle has ample time to spin up. When I run a carve through Easel it seems to wait a second or two to let the spindle spin up before it starts carving. Is there something I need to do differently to allow it time to spin up?
This is true, BUT if you contact them they will provide the prior firmware before they made this change to fix (my approximate guess) 5% of the shipped XCP units having a connectivity issue by pushing out new firmware to all users, forcing them all to operate outside the design specs of GRBL…
When using Gsender (and openbuilds for that matter) I suggest using the “Grbl” post processor in mm or inches. . . and due to mm using less decimal places to express the same values vs inches, the mm option is actually preferred since many senders have a decimal place limit and using too many decimal places can cause issues, inches will use one additional decimal place versus mm. And I believe Gsender will allow you to still use the display in inches even if the gcode itself is the mm version.
. . . In Gsender you could setup a macro to start the spindle at a specified RPM near the normal operating RPM, start the spindle wait a minute, then start the carve. When the carve hits the line of the Spindle RPM, if that RPM is different than the Macro one, then the spindle will only need to slightly adjust RPM rather than ramp up from an idle state which should happen very very quickly.
Thanks for the input. Is there any difference in the firmware other than the baud rate change? Will this have any other adverse effects? What kind of problems would I see if I fall within the 5%?
I believe Neil is correct, with the only change being that baud rate. Unfortunately inventables doesn’t publicly release any revision change notes for their firmware or software, I haven’t compared the 2 firmware’s in detail.
I also agree with Neil on this, the problems experienced if you’re part of the effected few could vary across the entire spectrum.
BUT I speculate that the small percentage is the very first handful of units shipped and I believe that a wiring layout was changed inside the control box after the first production run discovered EMI issues once the assembly of the controller was outsourced. So, the takeaway of my story is that IF your XCP isn’t one of the first batch then I would bet (but I cannot say for certain) that you wouldn’t have any issue at all with the proper baud rate.
— Over in the unofficial XCP facebook group there are at least 5 people that I know of who have back rev’d their firmware in order to run at 115,200 baud and use a different gcode sender (usually OpenBuilds or GSender) and those 5 people report no issues at all.
So my startup code didn’t work. I’m not sure why I thought it worked initially but it doesn’t seem to now. What I ended up doing is editing the post processor file for grbl mm in V-Carve to add a dwell right after the spindle started. That seemed to do the trick. The problem I was having with the startup code is that it would just pause before the spindle even started up. After editing the post processor file everything seems to be working now.
Yup, that’s what you want to do. Be sure to add it everywhere you have a spindle start. For example, if you use tool changes, make sure you add the dwell after the M3 command there as well.
