Maslow Home Maslow Community Garden

Maslow Defender - Idea


#1

Here is a brain dump of an idea I’ve been cooking up that I call the “Maslow Defender”.

I’ve ordered a @MakerMadeCNC kit that should ship in December 2018 and I have yet to build my Maslow frame. I’ve been going through the forum topics to catch up on what people are making and issues they are running into. I have found several different types of issues that Maslovians have experienced while cutting out a project (assuming calibration is dialed in):

  • Excess heat & fire
  • Z-axis depth not correct (depth different than specified in gcode)
  • X,Y-axis movement not correct (movement different than specified in gcode)

When any one of these things happen there is a risk of:

  • Damaging the work piece
  • Damaging the equipment
  • Injury or Death
  • Fire
  • Damage to property

Since the severity of some of these consequences could be catastrophic, that seems to be the reasoning for recommending to stay and monitor the milling while in progress. While I plan to be there in person to monitor the milling process, I think I’ll be too slow to recognize and react to prevent anything but the more catastrophic consequences. This is where I think I could use the speed of computers to help enhance my ability to respond to issues and reduce risk to the work, tool, humans, and my property.

I envision a system that monitors the active milling task for anomalies and takes different actions based on risk and severity. I haven’t fully thought through what it would take to do all of the following but here are some of my thoughts so far.

X,Y,Z Position Issues

I imagine that several rotary encoders and wires could be utilized, in a similar configuration as the motors to move the sled, to calculate the current bit position. Example from amazon -> 41mxSBq68EL
http://a.co/d/asOXNXa
That current position could then be compared to the expected position to see if the bit has been moved to where the gcode specified it should be. If it’s not within an acceptable range, the Maslow Defender could trigger Ground Control to pause or cut off power to the Maslow and the router.

Excess Heat

I imagine having several different temperature sensors on the sled, router, and Maslow CNC motors. If temperatures go above an acceptable range, the Maslow Defender could trigger Ground Control to pause or cut off power to the Maslow and the router.

Abnormal Milling Vibrations or Sled Issues

I imagine having an accelerometer on the sled and router to monitor for abnormal vibrations or movement potentially indicative of issues with the milling end, feed rate, material, sled catching, sled coming free of one of the chains, etc.

Thoughts & Questions

If it all came together like I imagine, it would help reduce the number of ruined cuts while helping reduce some of the potential risks of running a CNC machine. I would create a dashboard view showing the status of all the sensors and acceptable ranges along with the current gcode line. This could enable sub second reactions as opposed to my sub minute reaction time.

I’m not sure how I would have this system get the same gcode that ground control is sending to the Maslow. I’m not familiar with the feasability of being able to recover a milling job after it has been paused or Maslow has had power cut to it.

Has this idea come up before? What do you think? Would there be a better way to accomplish this? Would it be worth the effort? What hurdles is this going to face?


#2

aux ports 5 and 6 allow for sensor input so that would accommodate your temperature and vibration sensor. but I am not sure if the software knows what to do with those signals so a pull request would have to be made on GitHub and then someone would have to volunteer their time to code it I think. I’ve never gone through the whole process, but that is my understanding of how it works.

of course all of this assumes the errors are not do to a haywire Arduino mega.

people that have suggested smoke/fire safety devices have always suggested NOT using the maslow Arduino, but I think given how cheap temp. sensors are it would be better than nothing. a $10 smoke alarm would server as a back up, and a fire extinguisher could back that up.

While I think it is a good idea, the hard part is implementation. Most people aren’t going to be electronic/code savy, so unless it is prepackaged and easy to implement it wont’ happen. Just look at all the good intentioned ideas on this forum that take “forever” to get implemented.


#3

Here are my thoughts:

As @aluminumwelder pointed out, having the Arduino within the safety monitoring loop is a concern - a firmware malfunction is one of the scenarios that could cause the danger being monitored. Best to keep the safety systems separate from the system being monitored.

This is almost always a mechanical issue with the Ridgid R22002 router adjustment or a configuration issue with a non-standard z motor. There’s a discussion about triggering an alert when the z axis doesn’t move as fast as it should, similar to the alert “The sled is not keeping up with its expected position and has halted…”. More testing is needed to choose a setting value to trigger the alarm (PM me if you’ve got a non-stock Z axis setup and can do some simple tests :grin:) The “sled is not moving” alert has caused come confusion and is a show-stopper when it crops up, and I would hesitate to introduce another show stopper setting unless it is wanted. Thousands of users have made mountains of wood chips without needing it yet.

The firmware does a very good job of reporting exactly where the sled is, within the limits of the calculations that handle the chains. GC plots the gcode file in one color and the sled’s position in a different color and you can watch as the cut runs to see how they track - or get the “sled…” alarm if they don’t :disappointed:. There’s a mimic mode you can compile to play Maslow while you wait for your parts or frame. (Is there any interest in having that mimic mode available as a GC setting instead of needing to re-load the firmware? When in ‘preFlight’ mode, the motors would not run, their positions would be stored while working with the file, then their positions restored when leaving pre-Flight mode). In the mean time:

If a separate monitoring system is interesting, take a look at the " Big Z-value display" in the CommunityGarden - @HansPeterHaastrup did a great job of tapping into the communication between the firmware and GC to make information available in a separate monitoring system. He was interested in the position values that the firmware reports to GC - but the error values get reported as well…


#4
  • Excess heat & fire

as others have said, this needs to be separate from the system, and your
detector is guaranteed to fail the one time you trust it and leave the shop.

As long as it is moving, you are very unlikely to start a fire, the problem is
if motion stops and the bit is in contact with the wood. This is very hard to
teach a computer how to detect, but very easy for a person to detect.

  • X,Y-axis movement not correct (movement different than specified in gcode)

If we could detect that the movement was different than specified in the gcode,
we would change the movement to comply with the g-code.

David Lang


#5

I agree a temp sensor should not be your Only fire prevention measure, But used in conjunction with other safety precaution it makes sense.

Those temperature sensors are about $2 . I think it would be better to hear an alarm when the bit is hot then wait until you smell smoke or see fire. Even if one is in the same room as the maslow they could be on a phone call, other project or some other distraction.


#6

the maslow makes a very different sound when it’s moving and cutting than when
it’s sitting still. As soon as you hear that change in sound, you should be
paying attention to it (especially if it happens long before the job is expected
to be finished)

David Lang


#7

This is awesome! Thanks for all the feedback.

I do plan on this running on a completely different Arduino or raspberry pi so that it’s isolated from the Arduino running the Maslow.

I’ll have to order an arduino mega to start playing around with GC and Maslow.

The “Big Z-value display” is something I’ll have to check out. Thanks.

Having lights blinking and some alarm beeping/blaring is a great idea.


#8

Nice! One of those things I figured I’d be missing by not having built and run Maslow yet.


#9

if you play music and/or wear hearing protection it’s hard to hear change in noise IMHO. piercing alarm IMHO is way to go.


#10

There is some great input on this here.

I believe that this is an important principle.

Along with it, simple, parallel/independent failsafe interfaces; I’d personally like a big “Pause” &/or “Stop” button to hit and will be looking for a way to add that next.

If the emergency interrupt button is a simple dry contact, then any Safety Monitor circuits can be stacked in parallel to it and run independently as blurfl & others have suggested.

Some of my next steps will be searching the forums for:

  • Hardware Pause Button,
  • G-Code & Ground Control implementation of Router speed/on-off,
  • Power cut-off relay for the router.

#11

A cheap monitor might be a smoke detector above the Marlow.


#12

Also visual alarm, red blinking light.
Also great as mood indicator


#13

I’m also thinking that I would wire up several emergency stop buttons around the shop so I always have one close by.


#14

You can use this IoT relay:

You can run a wire from the Aux connector on the motor shield to the trigger port on the power strip. This will let you use the Gcode spindle control to turn on your router and dust collection.

Running it this way would let you put an E-stop switch in line with the IoT trigger wire to kill router power. Or you could find a way to put it in line with the arduino and it would turn off your motors and router.


#15

Be careful of cutting power to the Arduino - if the Arduino loses power while the sled is in motion it will probably require a chain recalibration to get going again. Cutting power to the motors but leaving the Arduino running will avoid that.


#16

good to know


#17

That’s gold! How did you know that?


#18

It’s bitten a few folks in the past. Here’s @bar’s explanation.
It can also be caused by the computer going into low-power or sleep mode and shutting down the USB ports during a long cut session.


#19

The ideas around a separate datalogger seem reasonable. I would expect that, as a multi-variable system with noisy measurement data … it would take some computing horsepower to chug through the data. Perhaps more than an Arduino can do … perhaps not.

If the data can be logged to MySQL, or even a text file in a standardized format, there are ‘big data’ tools to correlate what would be considered ‘normal’, so that noises, vibrations, and measurements that fall outside that range (given the input G-code) could be flagged as ‘bad - alarm’ or ‘bad - shutdown’.

Heck, you could even train a rudimentary AI on what is ‘good’. It would be interesting to process the data in multiple ways and compare the results.

I don’t know how to get examples of ‘bad data’ though.


#20

That’s an interesting idea. The position data and the chain position error data are available from the log.txt. The position data is in the lines containing “MPos:XX.XX, YY.YY, ZZ.ZZ…” and the chain position error “[PE:LL.LL, RR.RR…” in the next line below.
With a gcode file that traversed the workarea in various directions one could automate collecting a chain error value pattern for the areas of the workarea. The amount of error would be affected by the direction and speed of travel, so more than one run would be needed.