The Shop > Electronics & IC Programing

Raspberry Pi, Arduino, Shield, GRBL, CNC, etc.

<< < (2/7) > >>

backofanenvelope:
Next thing you'll be building one of these Steve :D

https://www.youtube.com/watch?v=Jq5nrHz9I94

I have a couple sitting around I really must put them to use.

TomC

gerritv:

--- Quote from: vtsteam on December 26, 2014, 01:46:55 PM ---A little more reading seems to be answering some questions -- Grbl seems to include a graphical interface and jog controls, and seems to run on the Rspberry Pi.

In the hardware project linked above, it looks like an additional computer(laptop) is used for an actual physical display for the headless Raspberry Pi through VNC via a (wireless) network. But the Pi is running the GRBL program, not the laptop.
In the project, an Alamode board hooked to the Pi provides a Real Time Clock  and does the G-code to motion translation (I think). Finally a CNC Shield board seems to provide stepper drivers.

My questions now are,

1.) if I already have drivers, can I eliminate the shield board?
2.) Does GRBL provide look ahead buffer capabilities for motion control -- how square would corners be if this system was running a mill, and does the feed rate slow down from a straight line on doing arcs an circles made of polylines?

--- End quote ---

Grbl is a Gcode interpreter that runs on an Arduino UNO. In the article he uses an Alamode which is similar to the UNO. It drives stepper drivers, eg. the usual 25 pin drivers from Mach3 or individuals ones such as Gecko or drivers on a shield as in the article you linked to.
Grbl does not have a GUI built in, you need to feed it lines of Gcode from some other program that reads the file and pieces it out.
In the article he uses a Windows PC running Remote Desktop (or VNC) to connect to the Raspi which is running one of the myriad of Grbl feeders.
Personally I see no benefit to using the Raspi in this scenario other than satisfaction in wiring it all up :-) And I definitely would not want yet another layer between me, the button pusher, and the machine being controlled.

Grbl has a planner that holds 16 gcode commands. It is very efficient at driving machines. Yes there are some missing gcodes such as canned drilling cycles but those are easy to replace with simpler codes. File size is not the limiting factor that it was with paper tape!

I wrote a GUI that is more machining focused, https://github.com/gerritv/Grbl-Panel/wiki . It show cases many of the features of Grbl. At least one user is driving a Bridgeport mill with Grbl-Panel and Grbl. I use CamBam to create gcode, there is a post processor for it that is geared to Grbl.

The Grbl wiki contains a lot of info on its capabilities, well worth a read.

Gerrit

DMIOM:
Just a small note of caution from experience - not intended to diminish the Raspberry Pi - if you wish to use the Pi for "anything important".  There can be issues with the reliability of SD cards in this type of application, but there is a workaround (just minimally boot from SD and then run everything, including the OS, from a USB key).

As Steve mentioned, the main (only!) storage by default is an SD card, and that holds the operating system, all application programs and your data.

SD cards contain "NAND flash". All of the bits in a NAND flash block must be erased before the data is written, or programmed, and the program/erase process eventually breaks down the oxide layer within the floating-gate transistors of the NAND flash. The life of a NAND flash cell is typically quoted as 10,000 - 100,000 cycles

To prevent premature failure, most general-purpose flash memory devices incorporate increasingly-sophisticated "wear levelling" techniques - as each block of a file is written, the firmware inside the memory device decides whereabouts on the chip to write it (although this does have speed penalties - when writing because it has to decide whereabouts the best place is for each block, and when reading because file chains are more fragmented).

In view of their target application for recording still photographs and video footage, the absolute goals for SD cards have been (a) absolute speed of writing, (b) un-interrupted writing, and (c) storage capacity; and with their use in MP3 players etc., a subsequent goal was retrieval and playback speed.  In all these applications though, the number of read/write cycles per hour/day is very low in disc terms.

To meet these performance goals, SD cards tend not to use any of the "wear levelling" techniques used in other flash-memory storage media (SSD drives, even USB memory keys) - they just lay-down blocks as fast as they can, preferably contiguously; and the block-oriented nature of flash memory fits well when saving high-volume still images or video files.

In the old days of single-user DOS or CP/M the only access to disc was when you wanted to open a new program or read/write data files; however modern OSes (unix derivatives, Windows etc.) made more & more use of the hard disk, and not just as a swap file - just watch the hard disk light flicker on your laptop or PC even when you're not doing anything yourself!

SD cards are a great commodity storage BUT they're not really intended for 'main system disk' use - they can - and do - wear out.

The Raspberry Pi was designed as an educational tool - and in that environment SD cards are fine.

Unless you're extremely careful and/or make intrusive modifications to the operating system, unix operating systems update a timestamp whenever they read or check a file.  So, even if you're not changing anything, bits of the file system can be updated as often as once a second .....

I've been involved with several projects where we've exploited the Pi but need it operating reliably, unattended. We found we could not get reliable operation (typical symptoms the Pi would crash and then no longer reboot, SD card was corrupt, so watchdog timers no help either).  The solution we found was to have an absolutely minimal boot on the SD card and the root system on a USB memory key.  This is much better but not infallible - remember you still need backups!

Dave

Edit - typo in upper number of cycles, had put an extra zero so it said 1000,000 when it should have been 100,000

Will_D:
Homebrewers use a product called the BrewPi. Its a Raspberry pi controlling an Arduino that controls the fridge/heaters

Why the Arduino? Because the Raspberry is viwed as not reliable enough and so if if fails then the Arduino just holds the fermenter at the last set point.

As in not reliable enough to switch a fridge and heater on and off over a couple of days/weeks.

What about if its controlling a CNC machine running a long program?

vtsteam:
Wow, extremely informative and well written information everyone!  :bow: :beer:

I have a lot of thoughts and it will take me a bit to look at the links etc. So there will be just a few thoughts here.

re. unreliability of flash memory:

1.) I did know about this in a general way, but didn't realize that SD cards were worse than thumb drives. If I do eventually use the RPi, I will definitely minimize the SD usage as you do, DMIOM

2.) Point of interest: coming from a Puppy Linux background, flash memory (thumb drive) minimization is planned for by running the entire OS and applications in RAM (since it is so optimized in size) and having a "personal save file" which is written to the drive with data and added apps only occasionally, or on shutdown.

Use of a non journaling filesystem like ext2 also helps. Running in RAM also makes Puppy very fast. Puppy Linux seems to be available for the RPi, (though only in Alpha testing. -- still, it might be good enough to run just the CNC applications)

3.) I use CNC just a few times a year, far less than a camera. I think that my using the typical hobbyist ancient parallel port desktop PC, left for months at a time in a subfreezing shop with a conventional hard disk drive and in a dusty environment would probably be even less reliable, than a dedicated RPi with no hard drive used maybe a dozen times a year. For me, a dedicated CNC computer would not be left powered continuously or used for other purposes.

4.) I typically auto-run fsck at startup so any any memory failure would have to occur during operation, rather than between.

5.) I'm running small CNC machines, and drive power is always off if hands are on the table. I don't depend on a computer to decide whether to move things I'm working on. I let a power switch decide that. This isn't a producton shop. True I can damage a machine if a program goes awry. But I'm far more likely to do a G-code or setup mistake and cause a crash  than memory expiring (unfortunately) and them's the breaks. Although if something does break, maybe the RPi can take the blame anyway!

But I didn't actually buy the RPi for a CNC machine -- I just received it for Christmas, and tried to think what to do with it, so there's no certainty I will build the project that started this thread.

For me the reliability issue could probably be solved. It's the usefulness for my purposes of Grbl and whatever control interface it uses that would decide me.

If it can't maintain a constant feed rate at decent speed through multi-segmented curves because it doesn't have a look-ahead buffer, I'm not interested. I don't care about fancy cycles and G-codes, but the ability to handle acceleration and deceleration intelligently is an absolute requirement, for me.

Navigation

[0] Message Index

[#] Next page

[*] Previous page