Hi all, I've heard that preference is swinging towards microswitches as the preferred endstop for reasons of less noise. Let me just chuck this on the table- I hooked up one microswitch and two optos to my printer, and the microswitch is the only one picking up noise! I've hooked signal to common and NC to ground so 99.9% of the time the signal line is held low, however this is when it's gettinby Triffid_Hunter - Controllers
I understand where you're coming from. That's simple to implement in teacup, simply stick a queue_wait(); at the top of each unbuffered command in gcode_process.c This may be useful for SD prints but I wouldn't use it when running interactive prints where hostware is involved Add #define ENFORCE_ORDER to your config and try the attached patch (against current master) and see if you get what yoby Triffid_Hunter - Firmware - experimental, borrowed, and future
Teacup supports '328 and sd card (although not at the same time- not enough space!) Just hook 4 stepper controllers to it, some endstops, and see how you go.by Triffid_Hunter - Controllers
Teacup has a (default disabled) heater sanity check feature. If we're pouring power into the heater but the temperature isn't rising, we panic and shut everything down. If we turn the heater off and temperature isn't falling, we panic and shut everything down (as this may indicate a fire). It hasn't been tested much and almost definitely needs tweaking, but it may be what you're looking for. Witby Triffid_Hunter - RAMPS Electronics
brnrd Wrote: ------------------------------------------------------- > According to the specs for the power MOSFET on > RAMPS 1.2 (stp55nf06l), the Static drain-source on > resistance is typically 0.016 ohm and maximum > 0.020 ohm with Vgs of 5V. Assuming that the > resistance of the PCB heater is 1 ohms, the power > being dissipated by the MOSFET should be less than > 2.8 Waby Triffid_Hunter - RAMPS Electronics
I just had a look at the schematic and board layout after chatting to someone on IRC about ramps, and something that jumped out at me is a dearth of decoupling capacitors! On my board, I have a 100nF between 12v/gnd, and also 5v/gnd of every pololu, one across the arduino connector, across all the power connectors, and a few others for good measure to keep the noise down. Ramps seems to only haby Triffid_Hunter - RAMPS Electronics
the log shows the temperature at just 87.5 degrees. if that's what teacup thinks the temperature is, it will certainly be waiting for things to heat up. The provided thermistor table works with reprap's most common type of 100k thermistors, is yours a different type? If you keep sending M105, does teacup report a temperature that's +/-10 of your target 235? Have you pasted a thermistor table froby Triffid_Hunter - Firmware - experimental, borrowed, and future
yep that's pretty familiar I wouldn't limit yourself to only two analog inputs, then you can use it as a generic library. afaik the interrupts are disabled/re-enabled for you automatically by the ISR entry/exit blocks provided by avr-libc, no need to do it yourself unless you want to nest interrupts (dangerous unless done extremely carefully). There's an ISR_NOBLOCK flag you can use if you donby Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > with knowing the pin it still takes 2 > instructions, although this is prone to its own > set of errors. it is better to buffer the known > state in a ram location then to find out on the > port register what is stored there... Actually gcc uses sbi/cbi for bitwise port I/O, no need to know previous statby Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > I have a modified version of an arduino firmware > pushing 92.5khz at o-scope for a y move of G1 > Y1000 F400000 . using fast writes, with interrupt > redundancy, meaning writing two times to a pin in > case first time is interrupted. also i require a > 1us delay enabled in configuration for when e aby Triffid_Hunter - Firmware - experimental, borrowed, and future
spaztik Wrote: ------------------------------------------------------- > I just downloaded the latest commit from master to > test my recently completed heated bed. > After a reboot the extruder heater works fine. > After I send m104 p1 s100 both thermistors begin > to read the extruder thermistor and both m104 and > m104 p1 begin to turn on and off the bed heater > only. A lby Triffid_Hunter - Firmware - experimental, borrowed, and future
Currently, Sprinter can achieve about 36KHz step rate by doing the whole move in a tight busy loop. Teacup tops out at about 13KHz because we use a step interrupt and keep everything else running at the same time (serial I/O, temp sensors, heaters, system clock, gcode processing etc). EMC2's virtual axis runs at 40KHz, and at this rate you would have markedly increased jitter for any fast steppiby Triffid_Hunter - Firmware - experimental, borrowed, and future
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 demonstratiby Triffid_Hunter - Firmware - experimental, borrowed, and future
I don't entirely understand what you're proposing, but if you're saying that we run a virtual axis faster than any real axis to achieve less jitter, that's what EMC2 does. I think our little atmegas would have trouble keeping up with a decent lead rate, and the resulting aliasing would end up on all moving axes rather than just the lead axis. I think this one can wait for the 32 bit, >60MIPS mby Triffid_Hunter - Firmware - experimental, borrowed, and future
I dropped my solution from soupcup, you'll have to scroll back a few commits. Basically, precision loss meant that it was almost impossible to get all the axes to finish moving at the same time. When they moved similar distances it was almost perfect, but with things like eg G1 X143 Y8.1 it was terrible- Y would finish moving at X=85 or so! I think I wrote somewhere another possibility- the bresby Triffid_Hunter - Firmware - experimental, borrowed, and future
I wonder why it's even trying to work out move times if the distance is zero? If teacup detects a zero distance move with a feedrate, it simply updates the stored feedrate and moves on, without queueing anything.by Triffid_Hunter - Firmware - experimental, borrowed, and future
apologies for the thread hi-jack, we're moving it to the teacup thread.by Triffid_Hunter - Firmware - experimental, borrowed, and future
didn't see this until too late, my reply is in the other thread here :/by Triffid_Hunter - Firmware - experimental, borrowed, and future
aka47 Wrote: ------------------------------------------------------- > If we have a bunch of buffered moves going off as > well the returns are peppered with random OK's > sometimes in the middle of a return string that I > am waiting for. Perhaps you're missing what I'm saying. Consider this example: > M109 S225 > G1 X10 > M114 > G1 Y10 > M114 > M105 > G1 Z10 &by Triffid_Hunter - Firmware - experimental, borrowed, and future
aka47 Wrote: ------------------------------------------------------- > In Teacup some of the G-codes execute out of > sequence and this may be throwing the host-ware. But the 'ok' response is always to the line of g-code just sent so regardless of teacup's buffering, the hostware is receiving the correct response vs its expectation. For buffered commands, the ok is sent after the move isby Triffid_Hunter - Firmware - experimental, borrowed, and future
aka47 Wrote: ------------------------------------------------------- > In reality though I don't actually know enough > about the teacup firmware (or any other existing) > code to say if these optimizations would be of any > value (some or all might have already been done). Teacup has free-running ADCs, but we only check the results occasionally. Each sensor type has its own read perby Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > yes, but you forget we are also sending serial > data.... which by the way i also think is > problematic. 1 the processor completely stops > until all serial data is sent (arduino22 fixes > this with a serial TX buffer, but you are sending > and receiving ) That's a well known failing of the arduinoby Triffid_Hunter - Firmware - experimental, borrowed, and future
jamesdanielv Wrote: ------------------------------------------------------- > even though adc conversions are quick when done > with the interrupt, the reality is they can only > be completed when serial buffer is empty. (no > other acting interrupt, the serial interrupt is > very time critical.) Disagree. At 115200 baud and saturated down-link, the serial RX interrupt fires 1152by Triffid_Hunter - Firmware - experimental, borrowed, and future
nophead Wrote: ------------------------------------------------------- > average += (sample - average) >> 6; I have used this algorithm a few times, and I find that it actually decreases precision massively! If (sample - average) is less than 2^6, each sample produces zero change of the average! Also have to watch out for negative values and bit shifts as they don't interact well. Thisby Triffid_Hunter - Firmware - experimental, borrowed, and future
Hi all, just found a bug that would cause waitfor_temp to only check every 256 seconds, just pushed a patch. Please test and let me know if it's sortedby Triffid_Hunter - Firmware - experimental, borrowed, and future
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 problemby Triffid_Hunter - Firmware - experimental, borrowed, and future
Basically if we store the last 64 samples and add them all together (or some more memory-efficient averaging algorithm) we get a lot more usable precision and a drop in noise. I've done those algorithms before, just didn't know how useful it would be for printing since the heater block does quite a bit of thermal averaging all on its ownby Triffid_Hunter - Firmware - experimental, borrowed, and future
sprinter isby Triffid_Hunter - Firmware - experimental, borrowed, and future
what happens if you strip the comments out before printing?by Triffid_Hunter - Firmware - experimental, borrowed, and future
Jens_R Wrote: ------------------------------------------------------- > One advantage of using a normally-closed switch > with an internal pull-up or the pull-up on the main > circuit board is that you get a "triggered" signal if > the wire to the switch gets disconnected. You could do both- have the switch pull low for run and high for triggered, and enable the pull-up so when the sby Triffid_Hunter - Firmware - experimental, borrowed, and future