Feature - Configure Spindle Delay

[gcormier]

On my shapeoko, spindle takes a bit longer to spin up - currently I have my own custom post processing that inserts a delay.

It would be nice to have the spindle delay as a parameter we can set in the configuration.

[J-eremy]

Things that happen when the program starts is really the responsibility of the post processor exactly how your using it. The only things that need intervention after a program (gcode) start is stuff like the tool change stuff because GRBL doesn't have the ability for a tool change and has to be intercepted and dealt with on the sender side because of that, which is also one of the reason why almost everyone is switching to GRBL HAL.

A G4 P3(3 second pause) should be sufficient for the spindles carbide3d sells as they did not tune the startup speed at all in the VFD, or anything really besides locking you out of tuning it yourself, and they are tuned for people who put them on anything other than dedicated 15-20 amp breakers. The 120v spindles and VFD's they sell (extort) are amperage queens anyway.

I wont go too deep into the issues with the carbide bulk buy 20$ spindle and VFD's, and the noise they put out to everything in your house that they are charging almost a grand for but you are doing it the correct way already. I am currently using a 220v water cooled 2.2kw spindle on my 5 Pro and it spins up in about 1 second to full speed without much amp draw at all and I use G4 P1.

[hamanjam]

PwnCNC tuned their VFD for a 5 sec spinup so I had to adjust. I agree that some things are part of the post processor, but I have a number of projects that I created a year ago and routinely re-run for someone. Those older projects were when I had a Makita so no delay was necessary and now that I upgraded, I have to either remember to edit each gcode file to add the delay or allow gSender to add the delay now that I updated gSender to work with a spindle. the post processor shouldn't necessarily care what machine settings you run within reason but the spindle delay is one that is best kept on the controller.

I worked with the team earlier in the year to add the delay if it does not already exist which makes it more flexible where you add the delay. I do agree that having a user configurable delay would be optimal just for those who need a longer delay

[gcormier]

@J-eremy While I don't disagree about post processor, there's already the spindle delay in gSender.

As for the Carbide3D spindle, I agree, but found this - https://www.reddit.com/r/hobbycnc/comments/16r6jpu/the_pin_for_the_carbide3d_spindle_kit_vfd_is_3630/

So the pin was found by someone.

[J-eremy]

PwnCNC tuned their VFD for a 5 sec spinup so I had to adjust. I agree that some things are part of the post processor, but I have a number of projects that I created a year ago and routinely re-run for someone. Those older projects were when I had a Makita so no delay was necessary and now that I upgraded, I have to either remember to edit each gcode file to add the delay or allow gSender to add the delay now that I updated gSender to work with a spindle. the post processor shouldn't necessarily care what machine settings you run within reason but the spindle delay is one that is best kept on the controller.

I worked with the team earlier in the year to add the delay if it does not already exist which makes it more flexible where you add the delay. I do agree that having a user configurable delay would be optimal just for those who need a longer delay

@hamanjam In my opinion the post processor is strictly machine dependent, not manufacturer. Its only purpose is to compile the gcode based around those parameters about the hardware and configuration for that specific machine. Issues arise when the sender, Gsender in this case start adding layers of complexity on top of the generated gcode as that can have unforeseen repercussions. GSender is strictly a gcode sender that sends that gcode TO the controller, it is not the controller itself. It is merely the interpretation layer between the serial connection on the controller and the UI. For instance say I have some custom gcode thats been customized to delay the spindle at specific points, how should GSender interpret those?

PWNCnc is a great company, but they also tune their spindles for 5 seconds as a safety feature for those exact people that don't know about the amp surge on startup, and they don't want people blowing their breakers, or worse.

This is exactly why it is my belief that GSender should literally stick to sending the gcode and not get in the practice of molesting the code if at all possible.

You SHOULD ABSOLUTELY have a custom post processor for each machine, My Shapeoko will absolutely not work as well with your post processor as it does with mine, because it is uniquely machine dependant, and should be.

@J-eremy While I don't disagree about post processor, there's already the spindle delay in gSender.

As for the Carbide3D spindle, I agree, but found this - https://www.reddit.com/r/hobbycnc/comments/16r6jpu/the_pin_for_the_carbide3d_spindle_kit_vfd_is_3630/

So the pin was found by someone.

@gcormier That is great news! as now that opens up the ability for other signals besides the hack job adapter board carbide puts in the case with its half baked noise filter that is THE weak spot in the whole system. Pair that with the ability to fine tune the acceleration curves and you still have a kit that isn't close to worth a grand but you definitely get more value for the price. Even if its still a ripoff. Well until they change the code.

[hamanjam]

I added a specific use case where gSender having the delay is useful as the only thing that changed for me was the upgrade to a spindle but everything else stays the same so why would I need to reprocess potentially hundreds of perfectly jobs when all I need to do is include the delay. gSender does a lot more than simply a dumb interface sending gcode to the machine.

There's a whole lot of "in my opinion" and "in my belief" in the response but all of that is absolutely irrelevant. The request to be addressed is simply that if gSender has the option to add the delay, it should be user configurable.

[J-eremy]

I added a specific use case where gSender having the delay is useful as the only thing that changed for me was the upgrade to a spindle but everything else stays the same so why would I need to reprocess potentially hundreds of perfectly jobs when all I need to do is include the delay. gSender does a lot more than simply a dumb interface sending gcode to the machine.

There's a whole lot of "in my opinion" and "in my belief" in the response but all of that is absolutely irrelevant. The request to be addressed is simply that if gSender has the option to add the delay, it should be user configurable.

@hamanjam You know why there is a lot of "in my opinion" and "in my belief"? Because this is hobby territory and you can do whatever you want. Its not like the hobby space sticks to industry standards or they wouldn't be using an Arduino still.

I understand you want things a certain way, and have your own opinions and beliefs about how you would like it to run I just state that they are my opinion and not law or standard.

Gsender is an amazing piece of software, probably the best I have seen for hobby level CNC but try not to get confused on what it is. The CNC controller is an Arduino, and Gsender effectively is a Gcode Sender, hence the name. It feeds the controller the gcode line by line via serial port, or usb -> serial adapter. It does not, and should no "process" any gcode for anything other than the visualization and estimated times and such.
It also gives you some buttons to jog and adds in other things like tool change interception because GRBL itself on the controller doesn't support it due to lack of programming memory for new features. Which is also why GRBL itself hasn't been updated in about a decade, and also why the swing to GRBL HAL is happening that runs on newer 32 bit boards with superior memory.

I am familiar in exactly what GSender is, and what role it plays believe me, sorry if you dont. GSender is not even close to the same league as motion control hardware, neither is GRBL. Nor is it designed to be.

What you are asking for is for it to intercept more code, not only that but code that is supported already on the controller and modify it on the fly before it pushes it to the controller, which not only can but WILL have unintended consequences with some peoples gcode.

Lastly, about your comment about reprocessing "potentially hundreds of perfectly jobs". This should probably be done anyway after switching from a trim router to spindle because the feeds and speeds will be drastically different.

So yea, IN MY OPINION and ITS MY BELIEF that GSender needs to stick at what its good at, sending gcode and not dive to far into the overly complex territory of gcode modification.

Have a great day.

[hamanjam]

And again, the purpose of this request is to say the feature that is ALREADY THERE be updated to a user configurable value. Not asking for a complete new parser. I am very familiar with the delay process and the reasoning behind it because if you look back through issues, I worked on this same issue when it was added. The gSender surfacing process has a longer delay which shows there needs to be a standardization in what delay is added.

Other than that, a 1/8" bit is still a 1/8" bit whether it's a trim router or spindle. Same as a 1/4" or various v-bits the bit determines the speed more than the router if you configure properly. I didn't change to a spindle to go faster than the bits can handle

You must be using gSender at a very basic level because it has many more features than just a spooler. Things like feed/speed override, workspaces and macro, tool change interpretation can all alter the operation of how the gcode is being spooled. Now that I have the new grblHAL, there are even more things that can be controlled.

[J-eremy]

And again, the purpose of this request is to say the feature that is ALREADY THERE be updated to a user configurable value. Not asking for a complete new parser. I am very familiar with the delay process and the reasoning behind it because if you look back through issues, I worked on this same issue when it was added. The gSender surfacing process has a longer delay which shows there needs to be a standardization in what delay is added.

Other than that, a 1/8" bit is still a 1/8" bit whether it's a trim router or spindle. Same as a 1/4" or various v-bits the bit determines the speed more than the router if you configure properly. I didn't change to a spindle to go faster than the bits can handle

You must be using gSender at a very basic level because it has many more features than just a spooler. Things like feed/speed override, workspaces and macro, tool change interpretation can all alter the operation of how the gcode is being spooled. Now that I have the new grblHAL, there are even more things that can be controlled.

Ok, I see the confusion.
The GSender surfacing process generates the gcode from scratch for the surfacing operation for width, height, pattern and feed and speed which if that's what your talking about then I get the confusion. Setting delay at time of generation is a different story, it uses its own generic "post processor(gcode generator)" kind of.

Spindles/bits aren't about speed but more about chip load. If your using a 1/8 inch bit only, a spindle might be overkill in the first place. Reaching bit manufacturer chip load is near impossible on most hobby machines because of many things, like chatter.

Not sure what you consider basic level but I'm currently using gsender using about 4 workspaces across 2 CNC's, along with spindle, dust collection and custom macros for my touch plates and bitsetters with bits from 1/16 all the way to 1/2(pushing it) with a 2.2kw 220v water cooled spindle. I also use it for my laser cutter. CAD from Vectric Aspire to Fusion 360. If you consider that basic.

A lot of the features you mention are baseline GRBL and have little to do with the UI other than sending the command.

The real time feed/speed modifier is controlled by the GRBL controller also by sending a set of extended ASCII characters to tell the controller to speed up/slow down and that's about all it does with that feature also.

The G54-G59 workspaces are all controlled and saved by the eeprom on the GRBL controller, GSender has little to do other than sending G54-G59 to select that workspace and then another short string to save offsets.

GSender does not do any tool change interpretation, the offset is measured by G43.1, Like I said I have custom macros I wrote to do that for me. What it does it save the current offset in a variable and then add or subtract the new measurement for the difference, then save that z offset.

The macros are very nice, but pretty standard and the backend API would be fantastic if there was some documentation on it, but its a fork of CNC.js at its core and there wasn't much documentation there either. If there was I would have already wrote my own companion interface to improve workflow.

What GSender accels at is it is an uber simple, aesthetically pleasing interface for pretty much any GRBL controller out there, I haven't tried it with GRBL HAL yet so I don't know of any of the additional things that can be controlled other than proper keyboard jogging, but I do see its compatible with some of my 3d printer boards so I may give it a spin on some side project if I get around to it. It still operates under the same idea tho.

Good luck getting the feature implemented, I was just giving my .02 which is what this whole public forum is about.

I think we both are clear on each others opinions at this point and it can be put to rest.