TeaCup Maximum_Feedrate units

Stenfast, You can limit the Z max speed in skeinforge under the limit tab. It doesn't have to be done in teacup.

I'm also having trouble with retraction in Teacup. Initially I had the M101 and M103 commands commented out in my GCode, but it would appear that these are necessary to the retraction detection. However, when I uncomment them in the GCode my Mendel just hangs at the first M101. Any suggestions? I'm running version b39a7b8

Thanks,

James

---

--
Check out my blog: AdventuresIn3-DPrinting

I would try this commit [github.com] a lot was changed after it.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Thanks Sublime,

I switched version, but still no joy. It still hangs on the first M101 command.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

Is your max E speed set to a speed your extruder is capable of?

How many steps is your E_STARTSTOP_STEPS set to?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Which temp sensor are you using?

Extruder speed settings appear to be fine for all other movements. I've set the Start/Stop value to 500 steps (to match the 1.2mm I was using with Skeinforge).

Interestingly, I've found that the M103 commands work for retraction, it's only the M101 commands that cause the thing to hang.

I've also found that if I run in Absolute mode the M103 retracts then instantly returns to where it was before. I suspect that this is due to the G92 E0 that comes close by.

I've switched to relative mode and the M103 appears to work fine now, it retracts correctly, but of course it doesn't restart since I have the M101 commands commented out to prevent it hanging. This results in sparse threads at the beginning of a new thread.

I'm digging in the code, but I don't see anything obvious.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

I've figured it out. When it gets round to processing the M101 command in 'gcode_process.c', it performs this check on temperature first:


if (temp_achieved() == 0) {
enqueue(NULL);
}

Not sure why it thinks the extruder is not up to temperature yet as it has been at the correct temperature for an age, but it might be to do with prepping it in RepSnapper, then switching to Send.py for the actual print. However, I did leave it for 5-mins, so I'm not sure why it never reached the correct temperature and was allowed to continue.

I've commented out these lines and M101 now works for me.

JB

Once again the problem seems to come down to the host not the firmware. I abandoned graphical host side talkers early on and have had little to no problems since.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

The problem occurs with Send.py. I can't use RepSnapper to print, I just use it to keep the temperature on the extruder stable between prints, since Send.py shuts down the extruder when it completes.

The issue is definitely in the Teacup firmware. If it is checking the extruder temperature prior to an M101 command (not sure why, it doesn't do it for a M103 command - possibly because it is going to extrude), it should execute the command when the extruder reaches the correct temperature, not just hang.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

Strange I use GTKterm with Xon/Xoff enabled and have never had your issue. Thats why I said its with the host.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

There is a regression at the moment where the code that waits to achieve temp waits for far too long. Just now I think I've had an idea as to what it might be!

Investigations show that a misunderstanding about the units passed to setTimer cause it to check every 256 seconds instead of every second. I just pushed a patch, please let me know if it fixes the problem

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I'll pull it and test it tonight.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

I just pulled version e05e12c and tested it. Unfortunately, it still hangs with M101 commands on my Gen6.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

jim_blag Wrote:
-------------------------------------------------------
> I just pulled version e05e12c and tested it.
> Unfortunately, it still hangs with M101 commands
> on my Gen6.
>
> JB

I have the same issue. It was actually reported earlier. I never figured out what causes it - I just replaced the M101s with "G1 E1.7 F1500" and the M103s with "G1 E-2.0 F1500". That worked without problems.
My extruder actually never reaches it's set temp. The PID settings are probably somewhat off. However, it does reach stable temp approximately 5 ºC below the set value and that's why I never bothered to fix the PID settings.
Of course if M101 actually checks for "temperature achieved" then it will never happen, if we never achieve temperature.

JB:
Have you checked if your extruder ever reaches your set temperature within allowed hysteresis? If it doesn't, that would explain why you and I are having this problem and others don't.

ST

stefanst Wrote:
-------------------------------------------------------
> My extruder actually never reaches it's set temp.
> The PID settings are probably somewhat off.
> However, it does reach stable temp approximately 5
> ºC below the set value and that's why I never
> bothered to fix the PID settings.

Crank up your integral term a bit to fix this. This is a perfect demonstration of what the I in PID is there for

> Have you checked if your extruder ever reaches
> your set temperature within allowed hysteresis? If
> it doesn't, that would explain why you and I are
> having this problem and others don't.

If this is the trouble and you don't want to sort out your PID properly, simply increase the hysteresis enough to encompass the resulting offset.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

While testing the 3 axis of my newly build Mendel by manually sending G-codes, I found out that my Z-axis locked up every now and then. After a bit of testing it looks like the same issue described here: the driver attempts to drive the stepper motor beyond what it can actually push or pull and it just stops and hums angry at me.

I've searched the Teacup firmware to find some sort of limiter to find out why it seems to ignore the maximum feed rate.

Is this fixed in the current version for the Gen7?

I read that Skeinforge can be instructed to make sure the axis don't move too fast but I'd rather make it idiot-proof by limiting the speed in the firmware.

On a side note, in dda.c there is a section which determines the maximum speed and then limits the new move. Is this not working correctly or does it do something different then what I'd expect?

Are you sure the maximum is set in the config file to the max your Z will move? I have been using Teacup for 7 months and I have never had it ignore the Maximum set in the firmware.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

It is not the maximum Z position that is exceeded but the maximum Z speed.

For example: when I specify MAXIMUM_FEEDRATE_Z to be 100, the homing command uses this as its speed.

When I send G codes and I specify a speed of 200, the firmware will attempt to actually move at 200 mm/min. Since G01 movement commands accellerate (and the homing does not), my Mendel will actually move at speed 200.

However, if I set the general speed to be 1000 (which the X and Y axes will do without problems), Teacup will also drive the Z-axis at that speed. Which is ten times the maximum and as such the stepper motor is not able to keep up and just sits still while humming.

I was referring to the speed not the software endstops. And like I said I have never had this issue. Can you attach your Config.h?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I'll post it later as I use a VM to program the Atmel on my Gen7.

On a side note, I am describing the same problem as the topic starter so it is not a configuration issue... And while the discussion sort of side tracked, I do not think a solution was given except for a remark that it 'should' be fixed in git somewhere.

This was the original solution to the problem.

Quote
Madscifi
If the result of STEPS_PER_MM_Z*MICROSTEPPING_Z is greater than 1000 then Teacup will ignore the max setting.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote

This was the original solution to the problem.

... and it's gone now, if you use the Gen7 branch. See: [forums.reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Cheers!

I'll update tonight and try it out.