So our team has been compiling a list of the skills that we have and need to be passed on and I was hoping that all of you here at CD could check it out and make some suggestions/comments/edits in this thread or on the doc to improve it.
In respect to building a robot, it’s fairly complete (or maybe overboard: You guys have to convert your STL to G-code? That’s what the printer’s own software is for, sort of thing). Maybe a little wonky in organization (fabrication/assembly are two branches of the same tree, suggestion would be Hand Tools and Machines instead) but overall pretty good.
But I think you’re missing a couple areas entirely. Here’s a sample to get you started along those lines of thinking.
General Team Skills
–use of team communication platforms
–understanding of where and how FIRST HQ passes stuff to teams
–knowledge of how to access team protected stuff (password or padlock, either one)
–How to contact all current sponsors
–What potential sponsors have been contacted in the last couple of years
–Current outreach programs and plans for future ones
–Keeping the team budget…
That sort of thing is, dare I say it, more important than the mechanical skills to pass on. If a mechanical skill isn’t passed on, the team simply can’t use that particular tool until skill is reacquired. If, say, the team protected stuff access isn’t passed on, EVERYTHING in that area (possibly including the list of stuff to pass on) is blocked from use. And in some cases, that could sink the team. At best it’s a minor inconvenience while someone contacts an alumnus for the passwords. At worst, you can’t contact your current sponsors and can’t fund competition…
What? Converting an STL to Gcode is one of the fundamental requirements for 3D printing. Some printers come with software that removes the user interaction with this process but this only happens on some very expensive machines designed for people who don’t know how to use them.
I work with printers that are under $2,000 USD, and they have software for this process. Other printers, even cheaper, have their software as well. Granted it runs on a computer, but going from model(s) to Gcode is as simple as placing the models in and pressing the proper buttons. This software is included with the printer, and/or made available on the manufacturer’s website where anybody (including yourself) can download it. And there isn’t an option to view the Gcode.
Those aren’t “very expensive” machines–I’d consider Airwolf to be “very expensive” at $3K+, or more likely the midsize Stratasys machines–and yet they have the software.
Most people who use a 3D printer these days wouldn’t even know what Gcode was unless they were already familiar with it*. They’d just know that they placed the model, adjusted a couple of settings, and hit “print”. For normal fabrication, that’s literally all you need (though it does help to know a few tricks for orienting the parts you’re printing to make it easier to remove support material). For someone with a home-built/hobbyist/tinkering system, yeah you might need Gcode knowledge. Vast majority of people using 3D printers don’t land in that category anymore, and don’t see any code. (Matter of fact, when I was working on a printer in that category, I only used the Gcode viewer a couple of times–needed to find a particular command and see what was happening around it as I recall.)
I don’t know which machines you are using, but most low-mid tier printers I have used have either built in g-code converters or a program you install on the computer that does all of the work for you. I believe there are even a few open source options for generating g-code, but I am sure a lot of those are machine dependent.
I think you’re splitting hairs here. You have to run STLs through slicing software to use it on basically any modern 3D printer. There are to my knowledge no 3D printers which just accept STL files directly and figure the rest out on the machine. Using a slicer properly and configuring the settings to match the requirements of the part is indeed a skill and needs to be taught in order for it to work properly. No, the students aren’t literally hand-writing G-Code to do this, but it’s not unreasonable to call this process “Converting STLs to G-Code”.
It’s not unreasonable, no, to be technically accurate.
But it’s not what people see. They see “model in, press go”. There’s got to be a better way to put that on the document: maybe “set up build” or something like that. See phil’s comment for more on where I’m going on that.
If you were to apply the same thing to a CNC machine, would you call it “generate toolpath” or “generate G-Code”? (Both are correct, but I suspect that most operators would use “toolpath” as their primary lingo unless they were discussing the code itself.)
You were just arguing that this wasn’t a skill that was necessary to teach kids because it was easy and most printers have software to do it. I was responding to that argument, by saying it’s a skill. Now this is apparently a discussion about how the terminology is a problem, and you’re arguing it does take skill. I’m a little lost, and I’m not really sure what to respond to.
As for the CNC thing, I have heard both used interchangeably throughout my time in robotics and industry, but more the latter than the former.
Thank you all for the great advice. Regarding the STL -> GCode conversions I believe that was more just putting an STL into a Slicer and then auto generating the gcode for the printers use. Sorry for the confusion.