Router turns on then immediately off

Hi everyone,

After a few months away from the tool, I got back to it and had a major success (for me at least) earlier this week. Produced a toolpath file with VCarve, and it cut perfectly several times on some scrap using the FabMO interface.

So today I loaded up the exact same toolpath file in FabMO. I hit go, the router turned on very briefly, then turned itself off, but the the tool continued to move along all 3 axes as if it were cutting -- except of course the router wasn't spinning! I was able to quickly pick up the machine before the bit snapped.

I checked the Gcode and there's the C6 command that you'd expect to turn on the router and no C7 command immediately following.

I tried turning the tool off then on again. I tried other toolpath files...same problem. But interestingly, the demo sketch me app in FabMO worked fine.

Please help!

Brian,

I would first recommend updating the software on your tool--or at the very least downloading and installing the new macros (which control spindle on/off and more). The macros can all be installed at once by downloading and running the app located on our docs page: [github.com]
Just open the app and click "install all macros"

Aside from that--I'd like to have a peek at the header of the file just in case there's something that catches someone's eye here as being out of the ordinary.

Brian

I will start with the updates. I will post the GCode when I get back in town later this week. Thanks.

I've been running into this too lately. At first with Fusion360, but updating to the latest handibot software seemed to fix it, but now with VCarve. The only thing that I've found to work is to restart the Handibot when it starts to happen.

Ok, so I got back to it today. Ran the exact same job that worked the first time but wouldn't work the second time because the router shut itself off. And now this time everything was back to normal. Perfect cut.

Hanbibot folks, there's a glitch in the firmware somewhere. When I was having trouble last week, I did turn the machine off and then on a couple times, and it didn't help. But today, running the exact same file right from the job history in FabMO, no problems whatsoever.

Any ideas what's going on? I am planning to use the machine as part of a parent/student program in late April, and it's a little frightening to think that it simply might not work for no apparent reason on the day I really need it.

Brian

And by the way, my firmware was up to date and I didn't even instal the macros. So literally nothing was different from the last time.

Can anyone from Handibot chime in??

This past weekend I spent more time with the tool. When I first booted the tool and set everything up, again the router turned off right after turning on and I quickly canceled the job. I turned the machine off for a few minutes, reset everything, and then it worked great.

So is there any advice other than being VERY careful on the first cut after booting up, and continuing to reboot until the problem goes away? I would hope that a product that has been in the wild for 3+ years wouldn't have this kind of inconsistency.

Brian,

Let me ask a couple of questions that might help us narrow down where this bug is coming from.

Is your router turning off in the middle of a cut--with the handibot continuing to move through the toolpath?
Or is the router powering up and the beginning of a file, then immediately turning off before starting the cut?

When the router turns on, you'll hear a "click" sound as the relay flips on to supply power to the router. When your router turns off unexpectedly--are you hearing that same "click"?--which would indicate that the software is telling the router to power down for some reason.

Sorry for the late reply...

To answer your questions, the router will turn on at the very beginning of the cut before the Handibot starts moving along its 3 axes; but once it starts moving as if it's making the cut, the router turns off. The whole on/off sequence happens in less than 3 seconds from pushing the green go button on FabMo.

I don't hear a click when it turns off unexpectedly.

I have been able to manage this problem by restarting the machine. I just have to be ready to push the emergency stop on the first cut up so that I don't break the router bit if it turns itself off unexpectedly.

Brian,

After having this problem with a handibot i was testing here in the shop--I've got a new suspect for this issue--the ribbon cable that connects the fabmo board to the interface board (and also sends ON/OFF signals for the router). I'd like to get a new one sent out to you to swap in for the current one.

This is still a very limiting problem for me as well. Most often coming out of vcarve now, when the problem occurs it will:

1) Turn the spindle on
2) Pause
3) Turn the spindle off
4) Fabmo then closes the running job UI as if it completed
5) handibot then executes the gcode as if the spindle is on, usually cratering the stock and sometimes snapping the bit
6) There is no stop control on the ui anymore since fabmo thought the job was done, so I hit the red stop button on the machine and inspect the damage
7) At this point, there is a disconnect in state between the machine and fabmo interface: no actions taken on the UI will be executed by the handibot until either a) Handibot is power cycled, or b) you start an action in fabmo that requires the green button, but then cancel it in the ui instead. This snaps the handibot back to life and I can manually lift the bit to start over.

This is really, really frustrating and is costing a lot of time and material. My handibot is up to date as of this posting.

One more clue... I get the best results by hand-editing the gcode to remove these lines:

&Tool =2           'Tool number to change to
C9                   'Change tool

Josh,

I've been working on something similar to this with another customer and have been helped in his case by recovering the tool log--to diagnose what exactly is causing the shut down.

I've put together a document to explain how to recover and send the tool log here: [workbench.grabcad.com]

If you could turn your tool to "G2" level logging, and open the log after running one of the files that causes the error--then email it to me--that would help a bunch. my email is brian.owen@shopbottools.com

Brian

One other question--when you start your toolpath--does it prompt you with a warning about a toolchange that you then have to accept to resume the cut?

Also! just got reminded that updates to the software do not update the macros that run spindle on/off routine. New macros are installed using a macro installer app available on our docs page (handibot website). Just install the app and then run the "install all macros" option inside.

Yes, I get prompted with a toolchange that I have to accept before the cut starts. I will update the macros. Thanks.

I too get that message...

Turned my logging up... but wasn't able to recreate it today. I'll send the logs next time it happens. If I remember, it prompts me the first time I try the job for the tool change. If run the macro updater, do I lose custom macros?

Thanks for the suggestions!
Josh

The Macro updater will only overwrite the basic macros. If you've edited the default macros on your tool then you would lose those settings. However, the app allows the installation of individual macros--the main one that needs to be updated is Macro 90 (the bug in that macro can cause Z zeroing issues).

Trying some new designs and running into this again. Captured and sent the log files to your email.

> If you could turn your tool to "G2" level loggin
> g, and open the log after running one of the files
> that causes the error--then email it to me--that w
> ould help a bunch. my email is brian.owen@shopbott
> ools.com
>
> Brian

Thank you! I've been combing the log with some other folks here today. I'll get back here as soon as I've got something useful for you.

Josh,

It looks like the problem that you're encountering is only going to be reliably fixed in the next version of FabMo (not what you wanna hear, I know...) but in the meantime, if you save you files out of VCarve in G-Code...the spindle startup should work just fine.

I'll pop back in and let you know as soon as the new version is available.

Brian

That's too bad... makes for some tense moments at startup if I'm using anything nice

Really appreciate you all looking into it so quickly. Doesn't seem like it's an issue for everyone, any idea if there's something different about my sbp files, or just sbp files in general?

Brian Owen, ShopBot Wrote:
> It looks like the problem that you're encounter
> ing is only going to be reliably fixed in the next
> version of FabMo (not what you wanna hear, I know.

The slightly mysterious term that a programmer used was "race condition"--which is the unfortunate situation that occurs when a system tries to perform two operations simultaneously but needs the output of those operations in a specific sequence in order to function properly. If one calculation finishes before the other and the outputs come out of order--it can lead to a bug like what you're seeing--and it will be very hard to troubleshoot!

That's why I was assured that a new release of the software, plus running G-Code only for the time being, will be the most reliable solution.

Where do I get a generic g-code post-processor for V-Carve? Mine only has mm/inch shopbot options. There are no other definitions in the applications folder, and a cursory google search didn't reveal it.

I've put them up here: [www.dropbox.com]
Here are vectric's instructions for accessing post processors: [support.vectric.com]

OK--feel free to throw tomatoes at me--I just talked with sales and the version of VCarve that we've worked out with Vectric to sell at a lower price comes with the stipulation that only ShopBot post processors can be installed. So--those post processors that I just linked to will be impossible to install in your software. Back to the drawing board with software guys...

We are looking into this, and have a candidate fix in the works. This issue has unfortunately been entangled with a number of other issues that we've had to resolve all at once, and so the update has taken longer to put together than we had initially hoped. We've got the release candidate installed on our machines here, and once we're confident that things are working well, we'll push this update you you guys, which you'll be able to apply to your tool manually, or through its automatic update system.

We really appreciate the patience. I know this issue is frustrating, but the update will offer a fix for it, as well as other improvements that will make the tools more reliable, and easier to update.