At the moment, Ground Control on the controlling PC pushes each command one at a time to the arduino.
Is there any chance (or conversely, any technical limitation) of a version that sends the entire GCode batch at once, and steps through it on the Arduino itself? Ideally, the Maslow would be cutting boards in the garage while I’m working on my laptop at the same time. It’s not convenient for me to be sitting in the same place as the CNC for various reasons (and it’s too far away for a long USB).
Is there any chance (or conversely, any technical limitation) of a version
that sends the entire GCode batch at once, and steps through it on the Arduino
Yes, the Arduino does not have the memory to store the entire g-code.
Ideally, the Maslow would be cutting boards in the garage while I’m
working on my laptop at the same time. It’s not convenient for me to be
sitting in the same place as the CNC for various reasons (and it’s too far
away for a long USB).
As a safety issue, you should be at least reasonably close to any CNC machine
while it’s operating. At least close enough that if it starts making strange
sounds or smoking, you can deal with it.
SD card support would take care of holding gcode, but not the fire or take off across the room.
If you don’t have the time to hang around wait for another day. Too many ways to go wrong. You might get away with it, or like the 3D printer where the extruder catches fire, come home (or worse, wake up) to a smoking crater. I’ve dealt with fire victims in my paramedic job, don’t end up being one.
Yes, you could use a wifi/bluetooth dongle to communicate with the arduino.
powering it through the mega power input won’t make any difference.
This would not be a ‘stock’ wifi adapter like you would use on your laptop, that
requires far too much support from the software on the device it’s connected to,
but there are a number of devices out there that people use for wireless
connections to arduinos, any of them will work
One of the other big reasons to go from the PC sending 1 command of g-code at a time is because sometimes computers freeze or go to sleep. I learned from my experience with a 3D printer in my house. If the computer thats driving the printer suddenly kernel panics or blue screens or decide it needs to reboot, all of a sudden the printer can be left sitting there for hours with the hot end being held at 500 degrees against some Chinese made plastic filament. Oh yeah, and don’t forget your 3D printer is not UL listed. When it burns your house down because of an incident like this, your home owners insurance won’t cover it.
Using a dedicated Raspberry pi and octopi to drive the thing takes some of the variables out of the equation, but still the better option is a smarter printer than knows how to print off the SD card and who has safety features built in such as “I’ve been running 5 hours and haven’t moved. maybe something’s up and I should emergency shutdown”
I feel like a lot of what’s already been learned from DIY 3D printing land can be applied to DIY CNC users. Sending in g-code 1 line at a time at the very least is increasing the chances of messed up cuts and wasted materials and could possibly lead to broken or burned up equipment.
I don’t know what the answer is, but this topic is relevant to me at the moment. I was having a great cut today, took this picture when it was almost done. Turned around, and it stopped. The USB had dropped the connection, and it wanted me to recalibrate. Ugh. I guess I’m hand cutting the last part.
I have no idea what the solution is, but this problem was a bummer. I understand it probably is something in my computer I need to find and turn off, not a Maslow issue. Still, just thought I’d share.
I wonder if some of these MaslowCNC problems we have on long cut times is caused by Windows power saving features ?
On Windows 7 Desktop press Right mouse key.
Select "Screen Saver"
Select "change power settings"
Select "change plan settings"
Make sure “put the computer to sleep” is never.
Select "change advanced power settings"
Under "advanced settings list’
under “hard drive”, “turn off hard drive”, “plugged in” change to “never”
change “USB settings” ,
"USB selective suspend settings ",
under “Plugged in” to set to “disabled”
under “sleep” , under “plugged in” , change to “never”.
If you are using a wireless feed then under "wireless adapter settings"
under “power saving mode”, under “plugged in”, make sure it is “maximum performance”.
At least we can try to make sure the computer, hard drive and USB do not just go to sleep in the middle of a run
@Jenna_Bobenna has a great description of the unattended CNC device problem. Add mechanical failure - heaters constant on because the control device fails (hot end mosfets often fail this way), router’s can overheat and burn (they aren’t designed for many hour continuous operation), etc. Seen lots of 3D fire pictures. People have died in CNC machine related fires. Insert stock never leave them unattended more than a few minutes at a time.
Amazon has some automatic fire extinguishers/suppression systems, or your local fire extinguisher dealer or fire department can help you find one.
This is one of my pet causes. I’m a paramedic and volunteer fire department MFR and have removed bodies from fires, fortunately never from a CNC device. Don’t win a Darwin Award.
Yeah, I’ve said this before and probably will again, gets tiresome I know.
A batched version could certainly add to the reliability . I’ve worked with a batched control approach on a kiln control, and it is nice to have the job continue when (insert OS here) decides to sleep/update/crash. It’s not a small undertaking, though.
will require some storage space, the on-board eeprom is limited to 4096 bytes and a chunk of that is used to store the machine position. Some of the signals needed for an SPI SD card were used for board ID, so some reconfiguring will be needed there. One reason for a v2 board. Some form of encoding might fit small-to-medium gcode files into available eeprom.
Not sure how the SD routines will affect operation speed, interrupt service, and memory available.
a different, remote version or mode of GroundControl will be needed
the remote version would lend itself to a web interface
a remote version would make a bluetoothBLE connection more feasible
once you start adding SD storage, display, controls, etc to the arduino, you
have started to add enough complexity there to make the chances of it crashing
(or otherwise failing) much higher.
far better to pick an OS that you can run on real cheap, low power hardware and
set it to not auto-update (which isn’t a big risk if it’s not on the network, if
it is, you just need to plan your upgrade schedule. for most people a
midnight-2am update will not bother their use), and disable all power savings
a raspberry pi running linux is pretty close to ideal for this sort of thing.
It’s GPIOs make it easy to add extenal buttons or other controls, it’s cheap,
and low power. There is a slight learning curve in getting used to Linux, but
for a single-purpose use-case like this, it’s not bad.
I agree that a Pi 2 or 3 would do a great job. I use a 2 to run the controller for my Ubiquiti gear and it just sits there and runs. I control when it updates, although REA (rural electrification society) controls when it reboots after the UPS runs down.
Ignore those $35 references, it’s more like $65 after you add a good power supply (those cheap USB chargers won’t cut it), case, and decent size/speed SD card. For an added benefit you can add a web server (apache), snmp monitor (mrtg), and even serve up a few pics of your kids. I had a Pi 1 out of the first shipment, too pokey to be all that useful, but the 2 and later are reasonable small computers. Doesn’t make the aforementioned REA smile at monthly bill time, either. Ubiquiti later released the CloudKey, a nicely prepackaged device, for around the same price so I wouldn’t use it again for my APs, but I won’t replace it either.
Mine is headless and I ssh in, otherwise add the cost of a monitor, keyboard, mouse, etc. Perhaps OctoPi’s web interface would work, or there’s something similar for non-3D printers.
Actually what Bar has built could be converted to a Raspberry Pi hat with a bit of work.
It is not a lot different than the Protoneer CNC Hat.
The CNChat just has the Arduino and the plug-in stepper drivers all on one custom board that plugs into the Raspberry Pi. There is even a separate board to plug in place of the stepper drivers to allow you to use larger size drivers.
The same could be done with the MaslowCNC board.
Controlling a motor/encoder with non-realtime Linux might be an issue on a Pi. There was an effort to port LinuxCNC to it some time back that fizzled. Maybe the much superior (for CNC) BBB did it in.
A little poking around pololu.com; the 2827 motor/encoder looks a lot like ours minus the worm gear, and they have lots of brushed motor controllers, although I didn’t find one with the common stepper form factor.