Arduino Due and Ramps-FD #define HEATER_PINS_INVERTED

I'm bench testing Arduino Due with Ramps-FD. The heater is on when it should be off and vice versa. The #define HEATER_PINS_INVERTED doesn't seem to make a difference whether it is in or commented out. Any ideas?

Found the answer. Needs this patch [github.com] However the section for ui.cpp does not seem to apply with the latest version. I hope that these inverted heater pins get integrated to Repetier Main branch soon to support RAMPS-FD

It is private fork and the modifications were never included in the original version, which explains why I never heard about this. Will see that I include a fix for that problem soon.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Ok, latest patch now includes inverted heater control. Hope it works as expected.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote
repetier
Ok, latest patch now includes inverted heater control. Hope it works as expected.

Thank you I will try that one. I have noticed some very occasional stuttering/pausing with the 0.91 version I pulled around Feb 24th from github. I will pause and start stuttering for a few seconds then resume printing as normal. This is with a delta config. Is there a thread for feedback on the ARM version of Repetier?

No there is no special arm thread.

With your stuttering, make sure you increased buffers to something like 32 with 100 subsegments. We now have ram to prevent underruns:-) A bit stuttering directly at the start is normal. That happens when the buffer is not filled up fully but already gets used.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote
repetier
No there is no special arm thread.

With your stuttering, make sure you increased buffers to something like 32 with 100 subsegments. We now have ram to prevent underruns:-) A bit stuttering directly at the start is normal. That happens when the buffer is not filled up fully but already gets used.

Thanks! Specifically are you talking about "#define MOVE_CACHE_SIZE 32"? What about "#define MAX_DELTA_SEGMENTS_PER_LINE 22"? I am running a DELTA configuration.

With subsegments I meant MAX_DELTA_SEGMENTS_PER_LINE :-) You can go up to 255 there if you like. You have enough ram to do so. 32/100 is what I had running on my delta the last week with great success.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote
repetier
With subsegments I meant MAX_DELTA_SEGMENTS_PER_LINE :-) You can go up to 255 there if you like. You have enough ram to do so. 32/100 is what I had running on my delta the last week with great success.

Excellent. I will try that.

I am having a weird issue with the end stops. After doing a g28 I could normally extrude and then start a print. After the last firmware update the printer now doesn't respond to extruder commands when it is homed and sitting on the end stops. I have to move the z down and off the endstops and then I can extrude. It also won't let me Run a print job when it is sitting on the end stops. I need to back it down off the end stops and then start it. I double checked all my configs and they are the same as the previous version with respect to the end stops. The end stops are working as it does a g28 properly. I don't know what I did to trigger this new behavior.

Edited 1 time(s). Last edit at 03/04/2014 12:17PM by xnaron.

That is weird, but I think I have the same problem. Didn't think enough about it when it happened after a print. Reconnected and extruder worked again. But my prints also home and there after the extruder works. So I think it is not G28 but some state we come into that prevents extrusion. For me it was homing after an aborted print. Will investigate that problem along with my other problems :-) But I think it is the extruder position. There is now a safety check to prevent unwanted long extrusions. So I guess the last position of the print in combination with relative extrusion is a problem here.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Quote
repetier
That is weird, but I think I have the same problem. Didn't think enough about it when it happened after a print. Reconnected and extruder worked again. But my prints also home and there after the extruder works. So I think it is not G28 but some state we come into that prevents extrusion. For me it was homing after an aborted print. Will investigate that problem along with my other problems :-) But I think it is the extruder position. There is now a safety check to prevent unwanted long extrusions. So I guess the last position of the print in combination with relative extrusion is a problem here.

Thank you and weird for sure. It started working normally again after another firmware flash.

Now that we have the power of the ARM are there any other parameters for the delta that can be modified to increase the quality of the printed object?

Edited 1 time(s). Last edit at 03/04/2014 02:41PM by xnaron.

Yes, we can increase the doubler frequency to perhaps 50000 hz. Perhaps even more. The avr trick to do two steps in a row is not needed for due at 12000hz. But that will have no real impact on quality as your print speed is normally below. YOu can also increase the numbe rof segments per second to 600, so your approximation is closer to reality.

You can user higher microstepping, also I'm currently searching for a problem when stepper speed goes >65000 hz, whcih happens then faster. The only other thing is highe rbuffers which you have already done.

All other parameter have to effect compared to avr version. Same math same result.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Thanks. I have 0.9 deg/step steppers installed on x/y/z towers for the delta. I replaced the 1.8deg/step ones at the same time I upgraded to the DUE ARM setup. I will try increasing the #define STEP_DOUBLER_FREQUENCY to 50000. I had previously tried increasing #define DELTA_SEGMENTS_PER_SECOND_PRINT from 180 to 600 but it had stuttering issues. This was most likely due to the doubler frequency being 12000hz. I will try it now with 50000. Would you recommend #define ALLOW_QUADSTEPPING be set true or false? I am thinking maybe false as we shouldn't need this with the speed? However I may not understand that parameter fully.

This is a lot of fun pushing the limits Thanks again for the tips!

MAX_DELTA_SEGMENTS_PER_LINE has a greater impact if you increase DELTA_SEGMENTS_PER_SECOND_PRINT as you need to store more data. Thats why I increased it from 21 to 100. Perhaps I will even go to 200. I have more ram then needed anyway.

You can disable quad stepping. At 65000 hz you currently get problems with unpredicted speed changes. So you should not go beyond 100kHz anyway. I'm currently trying to increase that limit for due, but haven't found all overflowing computations. So if you see such jumps happen you know you were too fast for the moment.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

...

Edited 1 time(s). Last edit at 03/05/2014 09:23PM by xnaron.

Here is what I am running so far on my delta with 0.9/deg steppers...

Running the Repetier 0.91 From Feb 24th that I patched with the inverse heaters patch. Configuration.h attached

DELTA_SEGMENTS_PER_SECOND_PRINT 200 (tried 300, 400 and 600)
DELTA_SEGMENTS_PER_SECOND_MOVE 70

MAX_DELTA_SEGMENTS_PER_LINE 200

STEP_DOUBLER_FREQUENCY 50000
ALLOW_QUADSTEPPING false

MOVE_CACHE_SIZE 32
LOW_TICKS_PER_MOVE 250000

I seem to be doiing ok at these settings and printing about 80mm/s with 200mm/s travel. I do very occasional have this microstudder. It is different than before. It almost sounds like the stepper is stalling for 1/2 a sec. I don't loose any steps and it doesn't seem to affect the print. It doesn't seem to matter what I have DELTA_SEGMENTS_PER_SECOND_PRINT. I have seen them at low and higher settings. I haven't checked the github to see how much has changed since feb24th. I know you patched for inverse heaters.

I think there are definitely some bugs in the latest Repetier on the ARM DUE version. I occasionally get a major stutter during a print. It seems to happen more frequently on long prints (more than 2 hours). Sometimes it loses steps othes it crashedsthe head on the delta into the print. I was using the latest version from github. I went back to the previous version I am running as it seems to maybe do it less. I'll keep a close eye on the github for newer versions. The pains of early adoption

Edited 2 time(s). Last edit at 03/08/2014 09:27PM by xnaron.

Yes there are some issues. I'm working at it and my private release can already run 600mm/s without stuttering, which it did before. There were some problems and when I'm convinced it works stable i will release the update.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Awesome! Very excited