Not that I don't like learning new skills, but I'd rather be printing than learning all the ins and outs of programming Arduino code.
You should reconsider this - you are missing a lot of funny stuff.... 
Now, I just need to tweak the PID settings
Maybe coming soon...
Until then - stick to pronterface and start the pid autotune by hand.
Not that I don't like learning new skills, but I'd rather be printing than learning all the ins and outs of programming Arduino code.
You should reconsider this - you are missing a lot of funny stuff....
Now, I just need to tweak the PID settings
Maybe coming soon...
Until then - stick to pronterface and start the pid autotune by hand.
I'm getting familiar with pronterface - used it to figure out my x-y dimensions prior to using your firmware, and also ran the PID tuning commands. One question for the more knowledgeable - I had the command run 8 cycles, should I use the last values output, or average them together? As the test ran, it displayed each one in the terminal window - being a science-type, I copied all of them down and averaged them together - aggregated results are better than a single test, right? But as I am thinking about it later, I am wondering if it is actually a series of approximations, getting closer and closer to the 'real' values... those that know more about what the m-codes are actually doing - which one is correct? Again, I'm relatively new in this field of the tech landscape.
Best,
GD
...aggregated results are better than a single test, right?
AFAIK the last output is already the best approximation.
But if you want to do some fine tuning, you can start the autotune several times (even with different target temperatures) and take the average of these.
Edited by Guest
My request is : can you read one of these free pins (PC7 or PD7) and, if it goes low you pause the printer until it go back high (... maybe you can define it INPUT_PULLUP) ?
Hi Guglielmo,
that's nice - i read about this months ago and couldn't find it anymore... now i have back the link
It sounds like you have already bought one of these? Have you already made some explorations with it?
It's basically the expensive (but complete...) version of the thoughts that Nils recently had (@NBroenner).
He already discovered the right mapping for these pins on the ATmega2560 - it should be PC7 = 30; PD7 = 38
Setting the pinMode to INPUT_PULLUP and detecting the LOW-state sounds pretty simple and should be possible without harm to other users... like me....
I'm inclined to give it a try...
I think, this behaviour should even be compatible with your idea - because both sensors use the same pin with the same intention (your idea is a lot cheaper of course...). What do you think?
Hi @tinkergnome,
sorry have been away for some time, waiting for an enclosure to get available and to be able to print again :-). But it is still not available ....
You guys already tested the filament outage with the tunnel sensor. What is the procedure if the sensor detects the outage ? The buildplate will stay heated and the noozle will cool down ? How it the recovery procedure ? Have you already tested it with a cut filament ? Do you see the recovery position in the finished print ?
Thanks and regards,
Nils
You guys already tested the filament outage with the tunnel sensor. What is the procedure if the sensor detects the outage ?
With the Tinker firmware, when the sensor put LOW the PC7, triggers the pause menu (... exactly like if you choose "pause" from the control panel). Solved the problem, you have to push the "reset" button on the filament monitor and to manually resume the printer.
You can read from HERE 
Guglielmo
Edited by Guest
1
I'm having a really odd problem. Fan control in my UM2 works fine in every combination I try, except when slicing with recent Cura versions and selecting UltiGcode (using Tinker's 15.10.1 at the moment, but earlier Cura versions had same problem). If I set Cura to use RepRap style gcode, it works fine.
The symptom is that if I use UltiGcode (with Tinker firmware) the fan seems to run at 10% of the desired speed. If I set 20% at layer 3, I get 1% at layer 2 and 2% at layer 3.
I can see the appropriate M106 commands in the GCODE, but they just don't seem to work correctly within Cura's UltiGcode. I have noticed that recent Cura versions use M106 commands that look like:
M106 39.5000
I've wondered if the firmware is misunderstanding that for some reason, because earlier Cura versions, and every other slicer I've ever seen, generates only integer values in M106 commands?
Edited by Guest
I have noticed that recent Cura versions use M106 commands that look like:
M106 39.5000
I've wondered if the firmware is misunderstanding that for some reason, because earlier Cura versions, and every other slicer I've ever seen, generates only integer values in M106 commands?
Hi Richard,
there's a missing "S" between the numbers, but i assume this is only a mistake in writing. Marlin ignores the digits after the point, but works just fine if you send a "M106 S39.5000". Your example sets the fan speed to 15%.
Although floating point numbers in this place are odd, this is not the problem here.
My suspicion:
For UltiGCode the value of the M106 command will be multiplied with the fan percent setting of the current material of the printer... A value of 10% there would explain your symptoms. Can you check this?
BTW:
I published a release 15.10.2 yesterday with a small bugfix for the "pause issue" you reported.
Till then!
waiting for a new release so the boring "printing with usb" text on the display is replaced with essential print progress and status information
thanks already @tinkergnome 
1
tinkerGnome - I love your version of Marlin! Just had to mention that. I think i found a bug. Or a feature I don't think I like:
I sell temp sensors and I test each one because the variation is pretty bad (about 1 in 10 are off by more than 8C). I test them using my printer - just disconnect the existing heater and temp sensor and plug in my "reference" sensor and heater and those go in an aluminum block with an extra hole for the sensor to be tested.
The problem is that after a minute (maybe 3 minutes? 2 minutes?) the temp suddenly goes to 0C. I didn't use the preheat feature - I used the "set nozzle temp" in "advanced" (not sure exact wording).
Is this a feature? Some kind of timeout? I looked for a place where I can adjust it - possibly in advanced preferences, but no luck.
edit - by the way I built the code from scratch from your latest github source as of last weekend.
Edited by Guest@gr5 it's apparently a feature since version 15.07.3
From the github releases page...
changed in this release:
Configurable heater timeout to prevent carbonized residues in the nozzle
- cool down nozzle after a configurable period of inactivity (Preferences -> Heater timeout)
- (re-)heat nozzle if necessary (to resume a paused print or change material)
edit - by the way I built the code from scratch from your latest github source as of last weekend.
You should do those things with caution - sometimes i commit changes and test it later...
...but last weekend should be ok...
As JohnK said, you can disable the heater timeout (Advanced -> Preferences -> Heater timeout). Just reduce the value until it shows "off".
And here is the source of your inconvenience....
One thing I've come across while using this great firmware... When the printer generates a "heater error" and stops printing, the nozzle just stays where it is and it's like the feeder continues to try and extrude filament endlessly, I had to turn the machine off to stop it. I'm not sure whether this happens in the standard firmware.
Is there a reason the printer doesn't home the head when this happens ?
Edited by GuestThe compiled hex file monitors the PC7 input pin and triggers the pause menu if it is pulled down to LOW (during printing from sdcard *). Resuming the print is done manually via the menu.
* during printing via usb one could probably also pause the print - and resume automatically if the state goes back to HIGH - but this is not implemented (yet).
Hi tinkergnome,
as I am a heavy octoprint user, is this already implemented for USB printing? Thanks.
One thing I've come across while using this great firmware... When the printer generates a "heater error" and stops printing, the nozzle just stays where it is and it's like the feeder continues to try and extrude filament endlessly, I had to turn the machine off to stop it. I'm not sure whether this happens in the standard firmware.
Is there a reason the printer doesn't home the head when this happens ?
As far as i can see - it's the intended behavior. It acts like a safety switch. On any error all motors and heaters are stopped and the display shows the error message until you shut it down.
You can start from here, if you want to explore...
Edited by Guest
as I am a heavy octoprint user, is this already implemented for USB printing? Thanks.
@markusmaker - you quoted the filament sensor support, it's there - but not related to octoprint or usb...
I assume that you wanted to reference to the announcement of @frederiekpascal?
He asked me yesterday if one could replace the boring "Printing with USB..." message with some useful informations. I promised to put it on my virtual todo list...
So regarding this, the answer is: no - not yet - be patient - stay tuned..
Or are you even interested to contribute...?
1
tink nailed it with my fan control issue: when using UltiGcode, the Fan % in the UM2 Material settings is MULTIPLIED times the fan % set in Cura, which is buggy, undocumented, hidden behavior, and wasted a lot of my time.
(Buggy because 20% x 20% does not = 2%, which is what was displayed on the printer)
Big shout-out to tinkergnome for the assist!
1
as I am a heavy octoprint user, is this already implemented for USB printing? Thanks.
@markusmaker - you quoted the filament sensor support, it's there - but not related to octoprint or usb...
I assume that you wanted to reference to the announcement of @frederiekpascal?
He asked me yesterday if one could replace the boring "Printing with USB..." message with some useful informations. I promised to put it on my virtual todo list...
So regarding this, the answer is: no - not yet - be patient - stay tuned..
Or are you even interested to contribute...?
If you can give me a starting point for development :-)
If you can give me a starting point for development :-)
mm-hmm, what is your starting point / previous knowledge?
Some links:
1
OK then, what exactly is "Babystepping" in your 15.11.RC1?
Are we talking microstepping >16X? That would be sweet!
i send a email tonight tinkergnome..sorry for the delay...
OK then, what exactly is "Babystepping" in your 15.11.RC1?
Are we talking microstepping >16X? That would be sweet!
I don't think so.... this would be called "nanostepping"... (probably...)
Here is a short explanation from the original inventor:
It's "hidden" behind the Z-position on the printing screen. @rooiejoris pointed me to this recently. If you like, try it out.
1
OK then, what exactly is "Babystepping" in your 15.11.RC1?
Are we talking microstepping >16X? That would be sweet!
I don't think so.... this would be called "nanostepping"... (probably...)
Here is a short explanation from the original inventor:
It's "hidden" behind the Z-position on the printing screen. @rooiejoris pointed me to this recently. If you like, try it out.
Now that's awesome! With that and a large linear calibration print I could calibrate the two heads of the magnetic head changer really fast.
1
ArunC posted a topic in UltiMaker Cura,
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Dustin posted a topic in Firmware,
Recommended Posts
Top Posters In This Topic
112
33
29
29
Popular Days
Jan 1
13
Nov 23
11
Dec 31
9
Dec 30
8
Top Posters In This Topic
tinkergnome 112 posts
ultiarjan 33 posts
rigs 29 posts
gpb01 29 posts
Popular Days
Jan 1 2015
13 posts
Nov 23 2015
11 posts
Dec 31 2014
9 posts
Dec 30 2014
8 posts
Popular Posts
chiz
Yup, it's the first run wizard. Ok, I'll try it and let you know what happens. Thanks a lot! Update: You're right! I need to complete the first run wizard first. After installing cust
Posted Images
tinkergnome 927
That's ok - you owe it to your printer to take a break from time to time.
Now i have a reason to order a second extruder motor for myself... let's see... the christmas holidays are near...
Link to post
Share on other sites
gadavis99 0
Just found out about this firmware branch, after having x-y positioning problems after going to an E3D hotend, and trying to customize the firmware myself :angry: Not that I don't like learning new skills, but I'd rather be printing than learning all the ins and outs of programming Arduino code.
Now, I just need to tweak the PID settings to match the new heater, and hope it still works. But having the positioning adjustments 'live' is such a great feature - thanks to all who have contributed to this over the years!
Gary
Link to post
Share on other sites