The additional field is currently only used for thermistors. There you can specify which thermistor table to use. It shouldn't influence thermocouples. Just put in 0.by Markus Amsler - Firmware - experimental, borrowed, and future
Andrew Diehl Wrote: ------------------------------------------------------- > Has anybody had problems with teacup randomly > deciding to send some combination of the x/y axes > to infinity during a print? try #define STEP_INTERRUPT_INTERRUPTIBLE 0 in config.h It is (was?) possible that the step interrupt interrupts itself, and the step counter goes below zero, and then count from 2^by Markus Amsler - Firmware - experimental, borrowed, and future
Markus Amsler Wrote: ------------------------------------------------------- > IMO a better way around UM_PER_STEP would be to > store the speed as something more machine friendly > like (cpu cycles)/step and do everything in steps, > cpu cycles beyond gcode_parse. I didn't take into account that each axis may/will have different steps per mm, so for distance and speed calculationsby Markus Amsler - Firmware - experimental, borrowed, and future
> Can we start with finding out what's different in > your setup from mine? I have a STEPS_PER_M_X of > 320000 and use absolute coordinates. What is > yours? Can you find out how many steps are moved > on 45 deg commands? They should be the same for X > and Y, obviously. I have a STEPS_PER_M_X of 10000. That explains a lot, as my steps are way bigger. I think you also had wanderby Markus Amsler - Firmware - experimental, borrowed, and future
I didn't know the preprocessor was so dumb. Perhaps there's some clever way around this comparison but I didn't found one. I epxlained the wandering problem like this: The internal state of the firmware x-axis is now in um. But the machine state is always in steps. The um_to_steps_x introduces some rounding error, e.g. for a 100um move you should move 33.3333 steps or so. But obviously you can oby Markus Amsler - Firmware - experimental, borrowed, and future
@Traumflug: I just printed a test object with the new code, and the x-axis is "wandering" with increasing height. It looks like after many moves the x-axis doesn't come back to the same spot. In fact I'm pretty sure the machine must know its position in steps to avoid "wandering". It's perhaps best to revert the changes for now and push them into it's own branch, until this "wandering" issue isby Markus Amsler - Firmware - experimental, borrowed, and future
Why don't you do something like #define STEPS_PER_M (STEPS_PER_MM*1000) and the config.h would remain largely backwards compatible.by Markus Amsler - Firmware - experimental, borrowed, and future
I haven't found a git/svn repository with a complete history of skeinforge, so I created one on github. https://github.com/amsler/skeinforgeby Markus Amsler - Skeinforge
Nophead, you convinced me. My software analogy source=cad/plan, binary=part/object is wrong because source, cad/plan AND binary are copyrightable, but not the part/object.by Markus Amsler - General
Correct, you can't copyright the parts themself (yet). But in the license for the copyrighted plans you can specify pretty much anything (like selling your soul in some EULAS), including don't feed me to a fabber. Now I have no idea if/how much arcol's CC license apllies to fabrication/3D printings. But I'm pretty sure you can't just take a by-nc-nd licensed MP3 manufacture an LP and sell it. Okby Markus Amsler - General
Disclaimer: Im no laywer, just happen to read slashdot nophead Wrote: ------------------------------------------------------- > Not true. Archol would have to patent it to stop > somebody making and selling them. If you could > stop people making things simply by publishing the > plans with a copyright notice why would anybody > spend thousands of pounds on patents? You're not alby Markus Amsler - General
nophead Wrote: ------------------------------------------------------- > All Archol's copyright protects is copying the > design files. Nothing to stop anybody using the > files to make hot ends and selling them. No need > to reverse engineer since copyright does not stop > you making use of the information it only stops > you copying information. The license says what you areby Markus Amsler - General
Triffid_Hunter Wrote: ------------------------------------------------------- > a discussion about > which behaviour is better- slower steps and jitter > with processor load, or all-out stack smashing > crash if we exceed maximum speed? Perhaps > something more elegant than these two? Theoretically it should be possible to calculate the maximum time it takes to execute the step intby Markus Amsler - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: ------------------------------------------------------- > I have attached my config.h for others to test, my > chip is a 328p, and the failing command is "G1 > E100 F2500". Does this occur on anyone else's > 328p? How about other chips? Any insights as to > why simply not zeroing next_step_time could cause > such a lot of bizarre behaviour? I haven't testeby Markus Amsler - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > Now, that's drastically simpler than what I had in > mind so far. I always thought of inserting a small > circle segment in between two straight paths. > Circles may be accurate, but the maths is > obviously more complex, as you have to move, well, > a circle, a non-straight line. That poses the questionby Markus Amsler - Firmware - experimental, borrowed, and future
Have you looked at GRBL's motion planner [1]? It seems to do exactly what we need. [1]by Markus Amsler - Firmware - experimental, borrowed, and future
For intercom extruder/heated bed I have currently the following hack in my config.h DEFINE_TEMP_SENSOR(extruder, TT_INTERCOM, 0) DEFINE_TEMP_SENSOR(bed, TT_INTERCOM, 1) #define HEATER_extruder HEATER_noheater #define HEATER_bed HEATER_noheater #define HEATER_BED 1 // 1 is the intercom temp channel Is this an acceptable workaround to go into config.gen3.h? I also attached a hackish patcby Markus Amsler - Firmware - experimental, borrowed, and future
brnrd Wrote: ------------------------------------------------------- > Is anyone using teacup on Gen 3 electronics with a > separate extruder controller? The firmware code > has a big error message that indicates it's not > tested. Thanks. I use it. But I have wired my gen3 motherboard a bit special, so I can't say the wether config.gen3.h will work out of the box for default wiring.by Markus Amsler - Firmware - experimental, borrowed, and future
Andrew Diehl Wrote: ------------------------------------------------------- > Hey everybody, > > Any plans to put support for dual extruders into > the firmware? Is there any machine out there with multiple extruders?by Markus Amsler - Firmware - experimental, borrowed, and future
nophead Wrote: ------------------------------------------------------- > Anthong Redbeard Wrote: > -------------------------------------------------- > > PEEK there seemed to be friction issues, itseemed > > to transfer more heat than PTFE, and allow the > > filament to be hotter than PTFE, > > Yes that is my experience also. PTFE/PEEK have about the same thermalby Markus Amsler - General
emt Wrote: ------------------------------------------------------- > "Skeinforge in absolute dimension mode generates a > lot of G92 E0. Although absolute E mode won't work > zeroing all axis is a bad idea. " > > > Why a bad idea? > > The G92 E0 clears the register. This is needed > with some Reprap controllers that have a finite E > register. When Skeinforge usedby Markus Amsler - Firmware - experimental, borrowed, and future
Traumflug Wrote: ------------------------------------------------------- > Is this an artifical command or insists some host > software on using G92 E0 ? In the later case a fix > wouldn't be too hard, in the former case a fix > somewhat a bit a waste of program storage space. Skeinforge in absolute dimension mode generates a lot of G92 E0. Although absolute E mode won't work zeroingby Markus Amsler - Firmware - experimental, borrowed, and future
sliptonic Wrote: ------------------------------------------------------- > Below is an output from a mendel_talk session. I > don't understand teacup's behavior with regard to > G92. As you can see, a G92 on Z axis is only > setting the Z but a G92 only on the E is resetting > X,Y,and Z as well. I don't understand this. That's a bug. It doeset know E on g92 so assumes g92 withouby Markus Amsler - Firmware - experimental, borrowed, and future
sliptonic Wrote: ------------------------------------------------------- > I think almost everything is working now. The > only bug I'm still hitting is that the extruder > stepper turns in the same direction whether I send > in forward or backward. Teacup currently only support relative E positions, perhaps its that. It means after every g1 e.. command e gets reseted to 0. G1 E-10by Markus Amsler - Firmware - experimental, borrowed, and future
sliptonic Wrote: ------------------------------------------------------- > Also, (and I haven't tested this thoroughly) it > appears the thermistor reading doesn't change, > even if I warm it up with a heat gun. Have you tried shortening the contacts, this should change the value. > Still have not got the mosfet led to turn on > either. with M104 S250 or so? works hereby Markus Amsler - Firmware - experimental, borrowed, and future
Triffid_Hunter Wrote: > Any idea what's wrong with the heated bed? > extruder.c:195 and extruder.c:95 should grab > trimpot value for PWM. Is something going on with > the analog subsystem whereby it only reads the > first defined analog input? Heated bed is on a non pwmable pin, which requires some hack to make it work. Currently the trim pot channel is not in the automatic geneby Markus Amsler - Firmware - experimental, borrowed, and future
sliptonic Wrote: ------------------------------------------------------- > Thanks Markus. I've applied the patches and the > mb firmware installed fine. On the extruder, I'm > getting the error: > > error: initializer element is not constant > > The IDE is highlighting this line in config.h. > > DEFINE_HEATER(extruder, DIO11) Strange. No idea. I tested it with currby Markus Amsler - Firmware - experimental, borrowed, and future
sliptonic Wrote: ------------------------------------------------------- > My thermistor still reports 866.25 degrees and > nothing I do changes either the reported value or > the toggles on the LED associated with the mosfet. > > > Any suggestions what I should look at next? The attached patches should fix your problem. Heated bed, extruder stepper trim pot pwm also won't wby Markus Amsler - Firmware - experimental, borrowed, and future
jbayless Wrote: ------------------------------------------------------- > That sounds like a big improvement. > > If the current command rate is 209 Hz, and the > axis is moving at 30 cm/sec, that means that it > travels a distance of 1.4 mm between recieved > commands. At 1798 Hz, that's 0.17 mm between > commands, which is definitely much better! You probably meant 30mm/sby Markus Amsler - General
I was playing around with gcode extruder retraction and got some firmware lookups as results. The Problem was/is that for step pulse rates above around 30kHz the step interrupt interrupts itself if STEP_INTERRUPT_INTERRUPTIBLE is set. if STEP_INTERRUPT_INTERRUPTIBLE is not set I get lost serial chars. Now what should the firmware do if we get close to the step rate maximum, and how do we detectby Markus Amsler - Firmware - experimental, borrowed, and future