PID -Hardware needed for a software fix

It is also common for insurance companies to not really understand the risks and just assign an absurdly large cost for insuring some products. This isn’t UL listed and it uses AC wiring. Just those facts mean it probably isn’t worth the sales price for Ryan to sell them. There would need to be a lot of them sold to pay for even winning a lawsuit. If he ended up settling for a burnt house or someone killing themselves with it, it would be game over. The insurance companies can’t really measure the risk, so they give out a “not an option” price.

2 Likes

Yeah that makes sense. Is it really a UL listing that is the problem? Seems odd since lots of products aren’t UL listed. Though I know Insurance companies make their own rules.

Seems like a missing ansi rating would be a bigger deal :slight_smile:

IDK what specific cert would matter.

1 Like

I will say, insurance issues aside, that the components Ryan has in the shop do allow for a workable “roll your own” solution if you’re comfortable with a perf board and a soldering iron to create the arduino nano board. In my case, when I did something stupid, there was a large “snap” (or a small “bang” I suppose) and the triac board failed with no AC flowing any longer. I was able to repair the board with new components from digi-key and it is now what runs my DW660. Since the circuit has been installed in an enclosure there have been no more stupid mistakes on my part and it has been operating reliably.

2 Likes

When we did renewals on small group health insurance(self funded), we’d run all the standard analysis, then the edge case stuff to understand why they were wherever they were on the beta curve for that block. If they were over a certain % increase, the reinsurer would usually end up arguing with the administrator about the value of keeping the group, and would push for a rate so high they had to go find another insurer. My boss called it the MGA rate (make go away).

The phone call was a long time ago but they did not ask any real questions. Self Branded Mains devices where just another tier I guess. It tripled my yearly cost if I remember right. So I told them I would not pursue it and they did not raise my price.

Wow thats pretty crazy… I guess that means you could sell the perf board and a preprogrammed nano and just tell people that they should use it with “x” board right? Then your selling digital level equipment only :slight_smile:

had this idea after reading another thread, and wanted to elaborate on it more here.

this mod closes the loop between the router and the control software. couldn’t we implement a safety similar to the thermal runaway protection on 3d printers. have the MCU monitor the RPM (because its doing that anyway) and if the program has issues maintaining the set RPM (within a tolerance of course) it pauses the job, stops the router, moves it to a safe position and throws an error. i haven’t observed what happens when the collet get berried in the material. but in my mind it would cause a substantial drag and result in the router slowing down. at best it could help prevent some serious fires, and at worst it would cause some nuisance pauses that are likely the result of poor CAM setting and could save time, material and add an extra safety when working on other things while the CNC is running a program.

2 Likes

I like the safety idea!

Even something as simple as the bit being a bit loose, pulling out of the collet, and digging itself into the material causes substantial RPM loss. This definitely didn’t just happen to me yesterday…

4 Likes

@jeffeb3 what do you think would be the best way to send an error/pause signal from the nano to marlin?

i was thinking just a simple digital output from the Nano, read by the control board, if it is 1 all is fine if 0 then there is a problem. leave the processing of the error (parking the tool, displaying an error code, etc.) to the main controller. sound about right?

i know that in GRBL there is an input for an enclosure door switch, that would work well for this kind of error code, does Marlin have something similar?

Not @jeffeb3, but my vote is for ye oldde break in mains power… :wink:

i would like to avoid that if possible, the nano has plenty of outputs so i could always set up a second failsafe output for killing mains via an IOT relay (for instance it sends the error to the control board, if problem persists for another 30seconds kill main power). but there is a lot of room in this for false positives, and it would be really frustrating to get 80% the way through a project and having a knot in the wood cause your entire system to shut down.

Hmmm… I guess I wasn’t clear…

I know I’ve been quiet lately, but sheesh, why you gotta be takin’ me all serious-like? :smiley:

Well, sure, there’s a hint of paranoid safety guy in there; if you’re going to have one automated safety relay, have it kill mains. Then work on getting more sensitive triggers to halt the job before it gets to that point. Fail safe, then pause conveniently.

but that is at odds, if you only have one fail safe you want it to be as sensitive as possible. my thought with this is to add an extra safety blanket (like having a hose handy when having a bonfire). So start by pausing the machine, the operator should be there if it fails. then after a ridiculous amount of testing, once we are sure that it works as intended, add the mains kill.

or maybe to put it in car speak, have the car tell you that your drifting out of your lane, then only after you are 100% confident in that, have it steer you back into your own :slight_smile:

Well, then… I suppose there’s some soul-searching to be done. On one hand, you have a potentially fiddly bit of brittle code (let’s be honest here, neither Marlin nor GRBL do really well with unplanned pauses, if you want ultimate control, you really need Mach3/4 or LinuxCNC), on the other, you have a paranoid dead-man switch that will kill your current project when a given threshold is crossed (which you can set to be a bit more… generous, since the operator will still be in the room). So when it hits a knot, maybe it doesn’t trigger the kill switch, but when the Z-Axis loses it’s grip and the collet begins “polishing” the work surface, it finally gets Dalton’s attention, and he shuts the whole thing down. While being nice…

1 Like

oh i got it, lets just hook it up to an airhorn, i’m sure then someone will come in and turn the thing off :stuck_out_tongue:

1 Like

Unless it’s time to NOT be nice…

2 Likes

Jamie had a patch that would read a digital in an just immediately stop the whole rig. You’d also want to stop the router and be aware that stopping on a dime might mean skipped steps, and whatever you did is probably ruined the work anyway. So yanking the cord isn’t a terrible idea.

There are a lot of parts that have to work for this “safety” system though. And none of them are tested when things are safe. So I don’t have high confidence this will really stop any actual disasters. But it does seem like a nice catch sometimes.

To be clear, the way the PID is built, this would not work well on the output power (the output power would be maxed when the P was largest, so starting and stopping). But the Integrator is a measure of how wrong you have been so far. If that was high enough, that could signal a problem. But you should also be careful not to let it just ramp up forever.

I really wish there was a way to test that every time you started or something. There are just a lot of ways to screw up that system and you would need a way to make sure it worked before you gave an iota of trust.

i was not thinking of integrating it directly into the PID, rather comparing RPM to PID output, so if the PID output was at maximum, yet the target RPM was not reached it would trigger the error (at least to start). after that it would come down to tuning the a time and level of the PID output to the difference between set RPM and actual RPM. my hope is not to force an immediate halt (after all the wood doesn’t catch on fire the moment that the collet gets berried). at least with 3d printing the time for a normal interrupt is general less then a minute. i feel like if it is detected and less then a minute latter the router stops and parks that would be ok, or am i wrong?

but your probably right, if it gets bad enough to force an e-stop condition it probably has ruined the job and maybe i should just kill the main… has anyone developed a power out recovery for CNC yet? that might provide the best of both worlds.

EDIT: the more i think about it, the more it think it will be related to the integral of the difference between the derivatives the the RPM and the PID output. or in laymen terms, the comparison between the rate at witch the RPM is increasing Vs. the rate at witch the PID output is increasing over a set period of time… so if the lag time between the PID saying “we need more power” and the router actually spinning faster becomes to great, then that would indicate that there is to much friction between the router and the material and the program should be stopped (or paused).

I’ve stayed out of the conversation so far, but something @jeffeb3 said resonates with my feelings -

I truly believe “Murphy never sleeps.” If I take 3 minutes to run to the bathroom while running the 200th repeat of a part that has never failed, that’s when things will crash - and burn. Somehow the safety that’s supposed to stop the collet spinning won’t. The risk is too high versus the safety measure of simply not allowing the machine to run without supervision. I will not trust this.

Of course, that doesn’t mean that you shouldn’t pursue it, just means that I don’t have any interest in implementing it myself.

Good luck with your endeavors.