The latest 1.1.4 update to the Creator software is now available! Thanks to everyone who has been helping us test some of the new features. The full list of changes is below:
Added 230400 bps baud rate option (i.e. for Type A Machines Series1)
Added G-Code library to display your most recent prints and easily access previous builds
Added X/Y/Z position readout and ability to zero each axis independently
Condensed Machine Control Panel to allow for easy visibility on small screen sizes
MakerBot printers are now successfully detected with direct control coming soon!
Added warning for non right-hand coordinate systems to ensure correct convention is maintained
X3G files can now be generated for combined FFF processes
Added warning if trying to activate without an active internet connection
Several big improvements to core slicing engine
Continued improvements to default M2 and Replicator 2 profiles
Added [primary_extruder_temperature] and [bed_temperature] placeholder variables for start G-Code script
Added [previous_Z_position] placeholder variable to layer change script and [current_Z_position] to layer change and ending scripts
Firmware configuration has been condensed and reorganized
Improved profile management by adding remove button and not listing the entire filepath in the drop down menu
Updated labels so that advanced FFF settings are easier to find
Added ability to rename macro buttons with custom labels
Enabled duplicate temperature identifiers between the bed and an extruder (i.e. for Replicator 2X)
Fixed bug with temperature identifiers not being correctly implemented for multiple extruders
Updated Sailfish/MakerBot firmware config to use M140 for HBP temperature and M6 for stabilizing (better compatibility with RepG and GPX)
Streamlined some of the mesh repair tasks to be quicker to use and provide more feedback on their success
Updated infill angle inputs to allow for negative numbers
Small fix for making very thin builds with start/stop printing at height settings
New addition of experimental concentric infill pattern for outer surfaces
Improvement for very tall multi-layer skirts to avoid intersections with model
Further stability improvements for very large previews
You can download the latest update the same way you downloaded the original. Just follow the instructions in your confirmation email
Thanks for the continued refinements. We all appreciate your efforts. However, the file management upgrade for 1.1.4 is causing problems for me.
I like to keep related files in project folders. My usual practice is to keep profile and the Gcode files in folders below the stl and other source files related each object. As the project develops, I name versions of things, so I can go back when necessary. With 1.1.4, I'm having trouble getting control of where files are are placed. For example, there is a directory for GyroCubes that holds several versions of variant models. Each variant has profile and Gcode folders to hold the string of versions I want to keep. The new setup makes it difficult to do this. For example, how do I get a new sliced .../Gcode into GyroC/Gcode/CRev3.gcode ? I can get as far as GyroC, then Creator insists on placing the new sliced file in GyroC. It also prevents me from moving things around, renaming, or deleting files without entering the Mac password in my own file structure. That is when I can do it at all.
Now, I appreciate the fact that there are lots of files created that can get confused. Also, that is would be great to be able to explicitly relate Gcode with the applicable profile. Many folks may welcome more automation for file management. But I'm having trouble with it. So, please help. I suggest the following:
a) First, please explain your scenario for managing projects. If I understood it better, maybe I could work with it.
b) Where are Gcode files placed by default? I'd like to, potentially, make copies, rename them, and place them in my own structure.
c) If none of this works, I'd like to have an opt-out option, or a way of relaxing your controls.
d) File management could be simplified if for every Gcode file, you wrote a similarly named, viewable, and reusable COPY of the exact profiles used to create the Gcode. Then it would be possible to make incremental changes to the profile as development progressed, but still be sure of having an exact copy to return to if the latest profile is not an improvement.
e) It would also be great to keep an automatic log file of all builds that recorded the Gcode and profiles used. Also, it should be possible to enter notes for each build, to record for example the printer, feedstock, and bed material used. Explicit columns for the bed, extrusion, and cooling temp settings would be a wonderful help.
File management and accurate record keeping is a big issue that Creator could easily solve. Repeatability is a weak spot with the current situation.
I think the method used in Creator is the "last accessed" method, per type. So if I generate a .gcode file in Creator and save it to a folder, it remembers that folder and uses it as the starting place to save the next .gcode file. Similar (but separate) for Factory files, getting STL files, etc., etc. Each type has an associated "last folder" remembered for next time. That's great if you want a folder with all your STLs (where your CAD software saves them, perhaps?) and a folder for all the gcode files (for copying to an SD card, perhaps?), and a folder for FFF files (for when you are calibrating or dinking with settings trying to find the "sweet spot" for that brand of black PLA), and a folder for Factory files (for attaching to a support e-mail when there's an issue, perhaps?).
(BTW, the defaults after a Linux install are in the /opt/S3DCreator area and not in the /home/(user)/Documents space, so the first save/open of each type involves a bunch of clicking..... I'd like to see Creator be more "user-aware" in Linux and start each user's storage somewhere in his/her home/Documents structure.)
But the "last accessed folder" method can be REALLY annoying if you are used to working in a Project folder structure. I think what you (pc) want is to have a Project container with subfolders for all the file types --- one for gcode, etc. --- and have the ability to open a "project" by name to get to all the associated stuff. (A project, of course, could consist of multiple "parts" --- with STL, gcode, etc. for each.) Say I'm working on "StatueOfWife", and within that project perhaps I have places for gcode, STL, fff, factory, etc. --- or just all in one folder even, for a small project. I finish my progress on that project and close it, then open the "ToyForDog" project and work on that, with all the files for that project structured the similarly, but only for that project.
At least that's the sort of direction I THINK you'd like to see it go, right?
I think there are benefits for each. The former (S3DC default) works well if your workflow involves getting something from Thingiverse, loading it, applying your standard process, slicing, saving gcode to SDCard and printing from SD card. (The saved STL location could be the output folder of your CAD package, and the gcode location could be the SDCard mapped drive letter...) The latter works better if you have multiple projects active at a time for multiple customers and need to work on one, then put it to bed and work on another.
I think Creator uses the former layout to make it easy for new users to get up and running slicing and printing objects found on the Internet. I agree it would be nice to have a selection for which way to structure files, "NewUser" (remember folder for each file type) or "MultiProject" (use a standard structure and offer to open and close "projects"). I can live with the method used because I'm new at this and not developing multiple objects for multiple customers under project deadlines --- I'm just a hobbyist building enclosures for microcontroller projects and other "nifty" stuff, like presents for family. But I can foresee a need to have multiple "projects" in the future so I can better keep track of all the neat stuff I want to make.
I guess it's just up to Clayton et al to decide whether they want to keep the current file structure or add a "project" structure option. Some software vendors do this by providing a pricier "professional" edition..... So I guess the real question is: How much are you willing to pony up for this feature?
And about your last comment, you guys already supported us so we'll do whatever we can to add these requested features. We just have to be cognizant of the tradeoffs for other users. You hit the nail on the head Dale when you said it's a good system but there can be situations where it is not ideal. I want to make sure I mention something that sounds perfect for some of these scenarios you are talking about. The .factory file that we include is really intended to be the complete project file containing your STLs, placement information, FFF profiles, support structures, etc. It literally includes every single file type you mentioned wanting to save, and that's the idea! Instead of trying to manage 5 different files in a nested folder hierarchy, we make it easy to export a single file containing the entire bunch. And better yet, we compress the result so that it saves hard drive space. If you want to create the corresponding .gcode file, just open your .factory file and press Prepare. That also ensures that you'll get the latest software improvements integrated into the gcode.
Just a suggestions for those that might be looking for a good way to save the entire project all in one place
Hmmm. Maybe just renaming "Factory" to "Project" (to make it more obvious what it contains for us old fart engineers who are used to working on "projects").....
Actually, wouldn't it be WAY cool if you could parameterize the extension and the descriptive name of each file type!? You want ".factory" and "Factory File". I want ".Proj" and "Complete Project"... You want ".gcode" and ".gcode file", I want ".g" and "G-Code File" and so on.... The bad part is dealing with parameterization of file extensions with the Windows Registry -- or Mac or Linux equivalent.... I know, just a silly suggestion. (I have lots of those.)
I think many of us would like to see a "factory" file be treated (visualization-wise) like a folder. (Your description makes me think it's not much more than a zip of a folder structure anyway...)
I'll have to start playing more with factory files. I'll admit, I haven't gone through the tutorial video yet. I'm the kind of guy who looks for a PDF user manual, prints it (I'M A TREE KILLER! I KNOW!), then parks it on the nightstand for bedtime reading.
I have another feature request, but I'll start a new thread for that.
Thanks for your kind compliment and followup, Clayton. Much appreciated!
The problem I'm running into is that new constraints have been added to the workflow that conflict with my previous methods. These cause the the Mac OS to become quite testy. Worse, even when I override it, I'm never quite sure if I'm burning my bridges and creating other problems down the line. That is why I'd rather be able to get into the structure and extract copies, instead of renaming and moving, and otherwise screwing things up profoundly. I'm not against change and adapting to new structures, especially at the start of projects such as Creator, but I've already got a large body of legacy files and folders that are all under active development.
Dale's characterization of the problem as a single serial workflow contrasted with parallel projects is extremely helpful, by the way. I'm someone who needs to use Creator on many projects at once. The beginner likes to deal with a single project. In trying to help teachers, for example, I'll need many projects, where each project represents one beginner student.
Yes, the concept of a factory file is excellent for a controlled production setting where all the variables are nailed down and unchangeable, cast in stone or more likely plastic in this case. Introducing changes made in the default profiles may, however, introduce undesirable changes into the engineered process. It just depends what the effect of those particular changes are. Such changes just might have the opposite effect of the intended stability.
In a development setting one almost never wishes to exactly replay a previous build. The next build is the last build with a few tweaks, e.g., a slightly different stl with the same profile as before; or, the same stl with a few profile tweaks for the new feedstock; or just a slight tweak for the new bed material; etc, etc, etc. So, with the bundling function, development also requires an unbundling function. This isn't a dissolution of the previous factory file, but a way to peek into it and extract pieces to use in the next build with some incremental changes. The previous factory file is still there as a security blanket just in case a roll-back is needed. Compaction may complicate the unbundling tool. It may be better to have an separate compaction tool that can be applied to a decomposable factory file when it is ready to be preserved for production. At this stage in 3D Printing, we are almost always in development mode, very seldom in production mode.
(I spent many years engineering early software configuration management tools, e.g., UNIX make, DSEE (Apollo/HP) ancestor of ClearCase, ancestor of Rational, and others. 3D printing problems are pretty simple by comparison, but still not easy.) One last comment. The parameters of FFF 3D printing have many interactions. The web of interactions sometimes depends on the design of each type of printer. It would be almost impossible to come up with disjoint sets of independent parameters. It is better to just try to save the whole set of parameters of each build, brute force.
I'm willing to help you kick around some of these ideas if it will help. However, my personal agenda is somewhat different.
I see Dale's juices are already flowing. It may be best to write down all the components of a build, decide how to treat each of these with regard to the workflow and come up with some sort of plan that is not a patchwork.
I have a Replicator X2 and I have a trial version of Simplify. I'm having issues with slicing anything below .17; when I slice at .1 I get alot of violent shaking when it prints curves and the extrusions are blobby. Also the default settings for temperatures were lower than I expected. Is there a reason for that? I see there are other Replicator2/X2 users here any suggestions?
