DaHai8

Just to double-check: Did you rename this folder prior to installing different Cura versions: C:\Users\[YOURNAME]\AppData\Local\cura

So...you're saying that manual control over WiFi or Ethernet is impossible with any interface (Pronterface or otherwise).... When did I said that? I said it makes sense that UM doesn't add it by default since isnt officially supported. Ok, perhaps I'm reading too much in your comment. But you seemed to imply (and I inferred) that the reason 'manual control' was dropped was because USB support was dropped, so therefore I followed that Manual Control was only possible over USB - othewise why would it not have been implemented for Wifi/Ethernet connection (as on the new UM printers)

So...you're saying that manual control over WiFi or Ethernet is impossible with any interface (Pronterface or otherwise)....

A San-Serif Fonts work better (this is a real pain with Chinese Characters!) Notice how the narrowest parts of the lettering are not being rendered - they are smaller than your nozzle or extruder line width. Like the others have said (and new for me as well), you can print narrower lines by setting your line width down to as low as .25mm for a .4mm nozzle. And printing with a Wall Line Count of 1 also helps (as you have discovered).

Have you checked with beeverycreative.com? Since they recommend Cura (among others) as slicing software for their printers, they may have a profile already built.

The limitation is probably your printer, or more exactly your printer's nozzle size. Check the width of the lines in your characters. If they are narrower than your nozzle size, they will not print - no matter what slicer you use. Most printer use .4mm nozzles, so your lines must be at least that wide. You can fudge slightly by telling the slicer you have a .39mm nozzle and that will help print lines that are exactly .4mm wide, but not less. So basically, the only way to print small letters with narrow lines is to use a smaller nozzle size, eg: .2mm, .25mm, .3mm

If you put a speed of 0, the retraction will not move. So the printer will just sit and wait for it to finish forever. It's like waiting for your car to back out of the driveway without starting it.

LePaul: Thanks for sharing! This is great stuff to know.

fnorkn: I've written ('I wrote' ?) a simple little post-processing script to replace every occurrence of M109 T1 with M104 T1. It should do what you want, providing the gcode generated formats the command as M109 T1 Sxxxx Since I don't have a dual-extruder (or single extruder with dual heaters) printer, I have no way of testing it. The script is shown below, but if you could provide some examples of how the M109 command is formatted for T1 temperature changes, and what the M104 format should be, I can modify this code to account for that (I'm asking because the M104 command is deprecated and so documentation is sparse and there is no mention of at Tx parameter in it: M104 Set Extruder Temperature) NOTE: python script formatting is VERY picky, so just copy/pasting probably won't work because the indents will be all horked up (technical term) from ..Script import Scriptimport reclass HeatnGo(Script): def __init__(self): super().__init__() def getSettingDataString(self): return """{ "name":"Heat 'n Go", "key": "HeatnGo", "metadata":{}, "version": 2, "settings": { "warning": { "label": "WARNING!", "description": "Replaces EVERY occurance of 'M109 T1' with 'M104 T1' - USE AT YOUR OWN RISK!!!", "unit": "", "type": "int", "default_value": "" } } }""" def execute(self, data): for layer in data: index = data.index(layer) layer = re.sub("M109 T1","M104 T1",layer,flags=re.M) data[index] = layer #Override the data of this layer with the modified data return data

I don't think that will change all the M104 commands throughout the gcode file for each time the print head changes filament for the T1 heater

Well, bummer. I would have thought the triangles would have held up better. Guess you can't believe everything you read on the Internet :(

I think this could easily be done with a custom post-processing script to change all the T1 M109 to T1 M104.

This article suggests the second-best option to hexagon (honey comb) is Triangular (Triangles): How to Choose an Infill for Your 3D Prints

Did you try with the H1 to designate which heater the settings were for? M301 H1 P25.78 M301 H1 I2.26 M301 H1 D73.40 M500

I believe that would cause the printer to start printing with the new nozzle before the correct temperature is reached. That could cause jams or the printer firmware fail-safe to kick in and just not extrude any filament until the correct temperature is reached...it'd be printing 'air'. Are you sure that's what you want it to do? Or am I missing something?

wigginx: Yup, that's pretty much exactly what I do as well. No disallow areas required and can also be set in other slicers.

Please, please, PLEASE, make it possible to run several versions in parallel. Separate the settings into unique folders for each build and ask the user if they want to copy over their old settings when installing a new version. Why? Well, for starters we've already had cases where a new version is completely broken without removing the old settings directory. And secondly, for those of us working with support, it's super valuable to be able to match the version the customer is using. Not to mention that after spending a good deal of time tweaking all the settings to get them just the way I want it, from printer / material / profile / Settings, I have to start over again with a new release. Is there a migration tool? I'd love to be able to test this beta, it sounds like it got some really nice features rivaling those in S3D, but short of writing some hack to switch back/forth between beta and stable, I'm not wanting to risk it at the moment. IMHO, the easiest/quickest short-term solution is to change Cura to name the AppData 'cura' folder the same as its Program Files folder: C:\Program Files\Cura 2.3.1 -> C:\Users\[YourUsername]\AppData\Local\Cura 2.3.1 C:\Program Files\Cura 2.4 -> C:\Users\[YourUsername]\AppData\Local\Cura 2.4 Then you could then at least have both version co-existing on the same computer and be able to fall back to a stable release while still testing a beta...all while migrating your settings over (sans having a migration tool). (I think I suggested this before...)

You can try sending the setting individually, waiting for an OK from each one, and then send the M500. You also might try specifying the heater number. M301: Set PID parameters IE: M301 H1 P25.78M301 H1 I2.26M301 H1 D73.40M500

Just a few seconds

You should have received an OK back from the printer on the M301 command.

I've not used Pronterface, but if it lets you send gcodes directly to the printer, then Yes.

I have a Prusa I3 style printer as well and found this wiki on PID Tuning very helpful: PID Tuning - RepRapWiki After you have found the correct PID settings, you can save same to the EEPROM via the M500 command (its all covered in that Wiki). So there's no need to put them in the startup g-code. Hope this helps.

nevermind

Ok, I think you may be running into that old Cura 2.x v 2.3.x compatibility issues. Installing Cura 2.3.x on top of an older version can cause issues. To test this theory, try this fix: Renaming old Cura Appdata folder

There is nothing in this box? And you've selected a printer? Which printer did you choose? Did you have a previous version of Cura 2.x installed before?