I am planning on running mine with an IP camera watching it so I can be in the house with the maslow running in the garage (garage is attached to the house). I figure from my computer in the house I can watch the camera feed as well as VNC in and monitor ground control. This way I can work in the garage during the day and monitor it, but can still make cuts in the evening while hanging out with the wife.
1 Like
Brazz04,
That is what I was thinking it just would be great if an event could prompt you then check the remote camera and intervene as required. My shed is detached from the house about 5meters away.
Regards Stuart
I like the timer idea, but not to try and guess time left in the cut. I always forget to ‘time’ how long it took to cut. I would love a timer that gave you a total time for cut when it finished!
1 Like
another thing with trying to predict the time, the machine sometimes takes
longer to make a move than the g-code predicts.
CNC machines have a much higher straight-line velocity than they can maintain
when doing curves and changing direction abrubtly.
Currently the maslow doesn’t take acceleration into account, so it will fail in
some of the extreme cases.
but there is some overhead to processing each g-code line, and so if you have a
circle made up of 1000 short straight line segments, it will take a lot longer
to cut than that same circle made up with a single arch segment.
I’m developing a Ubuntu image with remote functionality on the Raspberry Pi 3. My purpose is to be able to operate cable free. Fault notification could be added if we had a way to detect them.
I.E. bluetooth accelerometer on the sled? I’ve already made 1000’s of connections to it. It is mostly complete. It allows you to run the Maslow over WiFi to a Remote Desktop. I’m working on headless WiFi setup now so no display, keyboard or peripheral is needed. It is the last step in getting this ready. It also backs up the software and loads updates automatically for the Maslow.
This will include a case mountable on the Maslow and cabled directly to the Arduino. I’m putting a website together for it now. It’s all in the works.
Thank you
2 Likes
Now that, and a round of beverage-of-choice could keep us going quite a while!
The time I came back from fetching a cuppa to find smoke billowing from the Maslow (router latch failed, bungee cord forcing the collet to friction-ignite the plywood) or the time I was out playing with the dog when I heard ‘something funny’ and came in to find the router trying to climb up to the same level as the motors, and making a pretty good go of it. That one cost me a new driver board… Or the incautious .nc file edit to change a z-axis setting in the middle of the file which tried to raise the router 100mm… Spare z-axis assembly parts on hand after that fiasco. Unexpected chain skips, computer issues, broken bits. Whew! Who has more fun? 
4 Likes
Bee,
That sounds very exciting. I am wanting to remove the need for the computer near the machine which will be located in my shed.
What I was thinking of was an adapter (Serial COMMS over Wifi) that way you could transmit the serial events from GC over Wifi without any change to the GC code that would eliminate the need for a PC locally. Is this what the Raspberry PI device doing? If so that is fantastic.
Kind Regards Stuart
1 Like
Did you mean a stiff drink Blurfl lol.
Sounds to me that there will need to be some additional fault detection mechanisms that will need to be incorporated over time.
In relation to the Bungee cord was this a scenario where the sled was at the extremities of the workpiece and somehow caught the cord??
One thing we implemented was software fences which allows you to define no go zones and if he software detects path movement that hits the boundary a halt signal is generated. This would also solve the excess z-Axis retract (not sure if there is a parameter in GC for Z-Axis stroke).
Software fences would be best done at the GC end so the G Code is not sent to the Arduino in the first place. It can also be done at the firmware level.
I am actually looking forward now to getting my system operational so I can evaluate some these use case scenarios to see what can be done.
Sounds like I better order some spare parts lol
Stuart
1 Like
No, it is a fully independent desktop running local to the Maslow. We can afford to have a WiFi stream of serial data. What will happen when packets drop? This is a PC the size of a pack of cigarettes or bar of soap. It is smaller than the Arduino foot print.I’ve worked hard to find a suitable solution.
Thank you
Even Better.
Thanks Stuart
1 Like
In relation to the Bungee cord was this a scenario where the sled was at the extremities of the workpiece and somehow caught the cord??
As I understand it, he hasa bungee cord over the top of the router to push it
towards the workpice (so that backlash in the Z nut isn’t a problem)
If the latch on the base is open (either forgot to latch it, or it popped open),
then the router can become detached from the Z axis, at which point the bungee
cord will push it towards the workpiece until it can’t go any further (because
the collet is pushing against the workpiece and the bit has drilled a hole it’s
full length)
One thing we implemented was software fences which allows you to define no go
zones and if he software detects path movement that hits the boundary a halt
signal is generated. This would also solve the excess z-Axis retract (not sure
if there is a parameter in GC for Z-Axis stroke).
In theory you are correct, but in practice that isn’t going to work that easily,
the zero on the Z axis depends on the bit length, and it’s very easy to have a
value that works for one bit length, but strips out the Z axis with another bit
length.
the fix is to have a physical zero and a logical zero, but I think we should
wait on that until we get some more grbl compatibility (which will include this)
But even then, there is no sensor to detect hitting a limit, so setting the
limits is going to be manual, and therefor error prone.
Software fences would be best done at the GC end so the G Code is not sent to the Arduino in the first place. It can also be done at the firmware level.
I think it should be done in the firmware, that way it’s not dependent on GC (I
am looking forward to being able to use grbl compatible g-code sending tools)
Apologies David,
You are correct the software fences are easily applied to the workpiece plane but agree would be tricky for the Z axis
Without some sort of physical limit on the Z-Axis it will remain a problem.
In terms of Grbl support would be you thinking soft limits for the Z-Axis or the Z-Limit functionality?
Are the software team looking to incorporate GRBL as part of the Maslow Firmware? Sounds like it.
The only simple thing I could think of in the short term is to move the sled over a conductive sensor wired back to the maslow shield. With the router spindle off jog the sled over to the sensor. Jog Z down till it touches then record the Zero reference.
Stuart
Kind Regards Stuart
Are the software team looking to incorporate GRBL as part of the Maslow Firmware? Sounds like it.
yes
The only simple thing I could think of in the short term is to move the sled over a conductive sensor wired back to the maslow shield. With the router spindle off jog the sled over to the sensor. Jog Z down till it touches then record the Zero reference.
unfortunantly that only tells you the effective Z zero with the bit currently in
the router (and this is available in the current code)
it doesn’t tell you where the absolute zero is where you start damaging things.
Too cautious, waste some time. Not cautious enough, overtime! Er, pain, suffering, maybe lifelong, which might really be lifeshort, or get to meet the fire department in your yard.
Take a book, your knitting, or run that fiber out to the shop and futz around on the Internet (using a different device, no interference that way). Haul that old sofa the SO’s after you to move, an old TV, and a Roku and rot your brain rather than roasting it. Plus then you can call it a man (or if appropriate woman, etc) cave
2 Likes
Moose you almost sound like a philosopher lol
Stuart
4 Likes
Is there a watchdog timer that could be used to detect a broken connection to the remote desktop? If a loss of connection is detected then the watchdog could send a stop command and turn off the router.
In theory there is a flow of packets that could be watched but I’m not sure you would want to stop the operation if the connecting router stutters, you can disconnect and reconnect. This is intended as a wireless connection. In theory in the same room. It is not intended for unattended operation. From my perspective you would just switch it off if you want to stop it. To make it more safe you would even use a deadman switch which is what I did to my sons soldering iron.
Thank you
Hey Guys,
It looks like it has been a minute since this topic has been talked about. I am very interested in getting a timer on how long a job will take!
a few reasons include,
- I was late for dinner one night because I underestimated time it took to complete…got scolded by the spatula boss…
- It would save energy and money! I run my woodshop “Chips” off of a Honda Generator that is pretty efficient and would like to put a timer on the power to the router and vacuum to save energy and turn everything off when complete. heres the timer I was going to get https://www.amazon.com/dp/B0776T26Q3/ref=pd_luc_rh_sspa_dk_huc_pt_sub_0?psc=1
with that i think you can even set up phone notifications…since you are controling it from your phone… - Turning off the roughter would help me identify when the job was finished via me listening close by.
- I currently do hand calcs for a guesstimation on when a job will be complete and while my calcs are getting closer, GC laughs away at my latest calculation failure
I think GC is capable of producing an estimated time till complete. I mean, we input all the known speeds and travel distances…add a little fluf and vuala!
here is a few ways Ive thought of to get an estimated time of cut.
Hand calc -
distance of (cut path / cut speed) x (material thickness / cut depth) + Maslows lag Constant
Example – (120" / 20" per minute) x (.8"/.1") + Maslows constant of 7 minutes. = estimated time of 55 minutes
As you can see, this is a pain in the butt and definitely two licked fingers in the wind. so far my weatherman has better success statistics than myself
GC calc -
movetime1 + movetime2 + movetime3 + … + (#ofmoves X avg. maslow lag time between operations) = time to complete
movetime1 =
if travel is on z axis motor:
dist = depth travel x plunge rate
else:
dist = distance of move / sled movement speed of that operation
what do yall think? would this small bit of programing be obtainable? accurate?
also, here is a picture of a whale!
3 Likes
'Call me anything, but don’t call me late for dinner!" - in that instance, the “Hold” button is your friend. For my experiences leaving the machine unattended, see here. Finally, I think there are so many steps with so much imprecision to a time estimate for each that the best way to estimate cut time is to guess and adjust the guess as you watch the progress. It will take longer than you thought it would 
Sherlock Holmes - Davy Crockett blue whale?
2 Likes
there is a limit to how many lines of g-code per min the arduino can process, if
the CAM system generates hundreds of line segments for a corner instead of an
arc or a simple square, it can change the time needed to cut drastically (see
the discussion of using kiri:moto inside onshape producing g-code that takes
twice as long to cut the same object as makercam)
make sure you take that into account
4 Likes