MaslowCNC State of the Tech 2019

Technical Details
21

Good question

  • Checking the file at the start (in Ground Control) to make sure everything is within ‘bounds’. and then
  • Checking each move in the Arduino - because it doesn’t necessarily ‘see’ the whole file before starting operation.

Perhaps the operator wants to cut completely out of the side of the sheet of material they are working with. Within reason they should be able to do that. But once the move ‘exceeds bounds’ then what?

Here’s an idea - have the Arduino:

  • stop XY motion
  • raise Z to the travel height
  • keep processing commands until coordinates come back into bounds
  • travel to those coordinates
  • return Z to the previous height
  • resume processing
22

We agree in my opinion, I disagree with who is in charge, trusting our personal safety to a computer is a fools errand. My experience with computers runs back to the computers in charge of Apollo. Entering Program 00 rebooted the computer mid mission at an in opportune moment. My point is there was an option for manual override or we might not have ladened on the moon. What does this have to do with CNC? I’m smarter than a computer it’s faster at thinking how it is taught.

I’ll share two quotes -
The greatest mistake you can make in life is continually fearing that you’ll make one.

One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man.

Elbert Hubbard

My own -
I trust a man over a machine every time.

The more I learn about computers the less I trust them.

Look up error 1202 on Apollo 11. This condition is still the same on current computers, ask too much too fast and use too much storage the PC will stop.

I agree safety first. I will not trust the safety of my digits to any machine.

Agin this is my opinion, I have 50 years of making and using industrial equipment and not one accident of note. The biggest impairment, self imposed ,was long hair. Go figure.

Thank you

2 Likes
23

You have 15 years up on me in terms of programming, we obviously both have built systems on which peoples very lives depend, and yet we’ve ended up in different places. My background is industrial machines (including SCADA), engineering (as a practice - civil, mechanical, electrical, structural, gas, sewerage, fire & explosion), telecoms, emergency dispatch, emergency services, major disaster response and management, disaster planning, and those other disasters - finance, insurance, legal and government.

I agree very much with ensuring that manual override is always available. That’s why I want an emergency cutoff switch as a standard feature - slap that big red button, everything stops.

However, as humans we’re terrible at remembering and checking everything we should before we start doing something, that’s why so many professions have checklists. For example, the biggest bang-for-buck life saving for surgery has been a checklist used to record every item used in surgery, and make sure that it’s accounted for at the end.

But computers are really good at remembering stuff that they’ve been programmed to remember.

And so is trusting ourselves (without some form of verification like a checklist), and trusting that others have the same insight and understanding that we do.

Expecting that everyone else should measure up to our understanding of a correct ‘process’ to assess and ensure their own safety is, I’m afraid to say, naive, based on lots of experience in many different places. I’ve been there before and I have no desire to take that risk again for myself or implicitly impose it on others.

This machine is implicitly assuming a hell of a lot of understanding and commonsense that a lot of people just do not have, or more correctly they do have it, but in a very different cultural and language context that puts them at unreasonable risk due to the assumptions that have been made.

For example for the alternate view, I have a variety of tools with various safety features, such as thermal overload detectors, that let me work faster and safer. Some of these are computer controlled and yet I trust them. They aren’t perfect, but they are massively better than nothing. I do trust my digits to them, and I can vouch that their safety features work, when my slap-dash approach doesn’t.

I’m not suggesting that we can completely eliminate risk, with a tool like this, of course not. But we can significantly mitigate the risk, and that is worthwhile.

24

having software bounry checks in the firmware is a good idea, but wht should
happen is that the machine should stop when it exceeds the workspace limits (but
this will require that we add a way to know the limits to the firmware). This
isn’t as nice as what you describe, but is how every other CNC works, so I think
we are better off matching their behavior.

having GC run the entire job and check for bounds conditions is a neat trick, it
would also be useful for GC to determine the bounding box (min/max x/y
coordinates) and have a button to tell the maslow to run that rectangle (without
adjusting the Z) so that you can make sure the entire job is in the area you
want.

David Lang

25

And I’m not trying trivialise what that might involve or how it should/could be done.

I wouldn’t think so - I’ve only ever seen that behaviour on one other piece of old-school NC kit from the '80s, so obviously not impossible.
But really just something basic that matches ‘expected’ CNC behaviour.

Yep, and relatively quick and painless as a standard test

26

If the machine is poorly calibrated, GC would think all is well but the sled could still fall off the frame.

27

yep, this won’t solve calibration errors or the chains not being the length that
the firmware thinks, but haveing the OPTION of turning on soft limits (i.e.
calculated limits, not physically detected limits), is a good feature to have

28

And without soft tests (but still the bad commands), the sled will fall off the frame regardless of how well it is calibrated :sweat_smile:.

:curling_stone: ← because it kind of looks like a sled, and weighs about the same.

29

The firmware does prevent movements outside the extents of the frame. It checks the target coordinates and if they are off the board, the movement doesn’t occur… Is this what you are talking about as soft limits?

1 Like
30

The code is called on every move and limits the target coordinates so they don’t exceed the limits of the board/bed/whatever.

1 Like
31

hmm, I know I’ve driven the sled well off the side of the workpiece before, so I
don’t think these checks are working properly

David Lang

32

Interesting… I can readily think of few things that would allow the sled to exceed the boundary of the frame but still pass the _verifyValidTarget check.

  1. Calibration is incorrect
  2. Chain lengths aren’t set correctly (i.e., the controller thinks its one thing and in reality its something else). I personally suspect this happens frequently during the calibration process.
  3. Encoders aren’t working properly (missed steps, or just not reporting steps)… This happened to me during testing the 4-motor sled.
  4. Issuing a command that moves the motors but does not use kinematics (e.g., B09)

One idea to help improve the safety (and I apologize for not thoroughly reading through everything and maybe this was suggested) is to have an option for the the sled to physically move to two opposing corners of the bounding box of the gcode to let the user verify everything is good. It’s relatively easy to calculate the extents of the gcode and then issue that move. This allows the user to at least do this test with the router turned off and not running.

2 Likes
33

Interesting… I can readily think of few things that would allow the sled to exceed the boundary of the frame but still pass the _verifyValidTarget check.

  1. Calibration is incorrect
  2. Chain lengths aren’t set correctly (i.e., the controller thinks its one thing and in reality its something else). I personally suspect this happens frequently during the calibration process.
  3. Encoders aren’t working properly (missed steps, or just not reporting steps)… This happened to me during testing the 4-motor sled.
  4. Issuing a command that moves the motors but does not use kinematics (e.g., B09)

in my case, calibration wouldn’t have been perfect, but not bad enough to cause
running as far off the edge as I ran it. I was doing full width moves and
accidently told it to move a few hundred mm off the edge and it happily moved
about that far.

One idea to help improve the safety (and I apologize for not thoroughly
reading through everything and maybe this was suggested) is to have an option
for the the sled to physically move to two opposing corners of the bounding
box of the gcode to let the user verify everything is good. It’s relatively
easy to calculate the extents of the gcode and then issue that move. This
allows the user to at least do this test with the router turned off and not
running.

running the perimeter of the bounding box is a common feature, two corners is
slightly faster, but not as common, so I think running the box is a better thing
to do

David Lang

34

My only thought is that since the frame is rectangular if you can safely go to top left and bottom right, could you not also assume you can go to top right and bottom left? (Assuming you are reasonably well calibrated) Now, if you want to use it to also make sure your gcode will fit on uncut portions of the board, then I agree four corners makes more sense.

I don’t doubt it… just really not sure how it could happen if those two code lines were called and everything else was correct… /shrug

35

Let me say I respect your opinion. How long one of us has been doing something was not meant to imply it made it a better Idea. A good idea is just a good idea. Both of us have engineered many solutions from slightly diffrent vantage points.

SawStop is an impressive technology, it detects flesh. It might save a limb. It can’t detect gloves. An operator improperly told it will protect your limbs could make a devastating assumption. A friend of mine reached in to a punch press in the 70’s loosing his 3 middle fingers because he leaned on the activation button while trying to reach deeper into the machine for a part that had fallen. I think it highlights both our points. That is if there were a checklist telling him to not do this type of activity he might have not had the accident. From my training I would have installed a mechanical stop or disabled the hydraulics before ever reaching in. I want people to have well developed respect for the potential of things and another deeply developed sense of self preservation.

My favorite activity is, when I was employed by a superior with less experience to do something dangerous without safety in mind, was to tell them to do it themselves, I’m not risking that for any price or any repercussion up to loss of employment.

My point is I understand your point and accept it. I will state again I respect you.

I want the operator to understand operating a saw is risk, I want the operator to understand and be aware of the risk of not being clear and focused. I want the operator to learn to never put their hand in a position the saw can hurt them. If they need to put their hand into the saw in a way of that could be a dangerous manner, I want them disable the saw to eliminate the possibility of the risk, unplug it put a stop in the blade. Job Done.

I have seen testimonials of the Sawstop working. I have not seen one demonstration of someone purposely sticking their hand in the saw to prove it works.

It would be trivial to add limit switches to the Maslow physically decoupling the power leads to the motors. To my knowledge know one has.

Maybe up to now CNC has been this way because it’s basic design was from the 50’s machinist that learned it as a trade.

I’m open to all input, I think we have a well rounded group from 9 to mid 80’s I have met here and they have operated the Maslow up to this point with great success. I think we can always work on improvement.

Thank you

36

How would limit switches be implemented on the Maslow? I’ve struggled to figure out a good solution.

37

My only thought is that since the frame is rectangular if you can safely go to
top left and bottom right, could you not also assume you can go to top right
and bottom left? (Assuming you are reasonably well calibrated)

correct

Now, if you want to use it to also make sure your gcode will fit on uncut
portions of the board, then I agree four corners makes more sense.

and this is the most normal reason for people doing this check

I don’t doubt it… just really not sure how it could happen if those two code
lines were called and everything else was correct… /shrug

I was doing this just from the GC/WC jog arrows

38

Those buttons just send G0 commands… one thing that could be done to test it, safely, is to reduce the bedwidth setting (say from 8 ft to 6 feet) and see if you can actually go past a foot short of the edge.

39

G1 gcodes give the same result (hooray for FakeServo mode…).

_verifyValidTarget(&xTarget, &yTarget) only changes the target, but triangularInverse() still calculates a movement. Instead I think that movement and spindle should stop and an alarm pop up. – Stop the cut rather than damage the sheet stock.

40

Put loops on the 4 sides of surgical tubing around 2 pins sort of like a big pinball bumper. Each loop would snag the side of the sled. Put a common roller contact switch in contact with the loop. The switch would go to a board with 3 DPDT relays. The 6 motor hot leads run through the relays on NC. The switches trigger the relays to open.

Down, Dirty, Quick.

Thank you

1 Like