Aphoticjezter, I can't really test for those sort of bugs at the moment, my electronics are packed away pending a suitable workshop space to set them up in. As soon as I have a suitable space set up I will do my best to track it down. In the meantime, post your config.h and see if anyone can reproduce.

Architect, we've discovered that there is no gcode for home using endstops, so we'll have to make one. I've also been informed that monitoring the endstops all the time is really bad news because of how much noise they pick up, so a proper solution for this needs to be well thought out, and have several possibilities tried. I currently have no endstops, as they're also pending some suitable space for me to create them

---

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

Quote

I recently pulled a copy of the master branch after the recent merge (pulled hash 719a9d32b5b9ddbee2d339d8e4c6fe93ee2e1ac3) but I'm still seeing the same 2ms pauses as with the triffid_release_candidate. My earlier solution was a bit of a hack, but am I really the only one seeing this issue?

I'd be interested in how you "see" such short pauses. So far, the sound coming from the motors is the only indication wether they work proper or not for me.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

Architect, we've discovered that there is no gcode for home using endstops

Jacky2k has apparently fixed this in his set of sources on top of the release-candidate: [forums.reprap.org] Didn't have the time to review and put this into FiveD on Arduino's Repo, yet.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

hm, I saw somethings last night in the code base I have that looked promising and I reviewed all the relevant posts here regarding the end stop code. I am wondering how to add "noise" to my environment for testing purposes. I am using shielded cat5 for my motor lines. which should protect the end stops for ambient noises. guess I'll find out. where were you thinking about putting in the end stop pin reads to check for end stop activation? during the queue_step method?
I also have come to the conclusion that it only makes sience to support MIN stops and then calculate from there the build area based on a config param. X_MAX_DIM = 200mm something like that.
also I like the idea of a unique routine for homing. currently in the base code I have G28 calls XYSpecialMove() this I think makes sense, just needs some more thought behind it .

Traumflug Wrote:
-------------------------------------------------------

> I'd be interested in how you "see" such short
> pauses. So far, the sound coming from the motors
> is the only indication wether they work proper or

Hey Traumflug, I can actually hear it in the motors... when making moves at 500 mm/minute (as per F500 in my move commands). The older firmware produces nice consistent tones, while the new timer code produces more of a grumble.

However, I've also measured the gaps using an oscilloscope which is how I came to the 2ms value.

Here's a link to a pastebin of my config.h

I've also got some patches for things like setting the endstop invert in config.h, making E moves relative instead of absolute, making G28 work when no X, Y or Z values are given, and a small bugfix for the x endstop in pinio.h. Any suggestions on how I should post these?

Thanks,

Jes

A potential for adding electrical noise to wires is to run an electric drill near the wires or wrap a turn or two around the wire to the drill.

Not the best route.

Personally speaking I am of the view that noisy limit switches are something that are fixable and should be fixed in the electronics rather than avoiding their use in software. (I guess this comes from professional experience of embedded systems engineering and instrumentation)

There will be instances I guess where folk struggle with this though so perhaps an option to turn them off during moves might be useful.

If you are really desperate for noise free limit sensors use LED's and cheap plastic optical fiber.

Low impedance current loops though are perfectly adequate. More so with a little filtering.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

I've also got some patches for things like setting the endstop invert in config.h, making E moves relative instead of absolute, making G28 work when no X, Y or Z values are given, and a small bugfix for the x endstop in pinio.h. Any suggestions on how I should post these?

Open an "Issue" at Github's Repo. This way they can't get lost.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

So, I tried the drill thing. Signal worked clean every time, even wrapped my optical sensor cables 5 times around my drill and ran it. that was fun and a little mad hatterish. so I think I have a very simple solution in place now for the stops. Don't step if the axis.direction = whats read from the axis.min_stop_pin. seems to be working very well and when I thought about it, if there is a temporary misfire of the axis.min_stop_pin it would have to be at the exact timing it is being read which is right before a step it written and it would have to be a very long interruption to cause multiple steps to not fire to actually be noticeable. when the stop has purposely been activated then anymore movement in negative direction (cuz I only care about the min stop) will be suppressed. no interrupts, nothing really else to do. Any thoughts?

><,'>

Hi!

I'm trying to configure this fw for Mendel-Parts Gen6 electronics, which is a sanguino with internal extruder. So far, I've been running into a compile-time error:

Quote

In function ‘dda_create’:
error: invalid operands to binary << (have ‘double’ and ‘int’)

The line it crashes on is:

c_limit_calc = ( (dda->x_delta * (UM_PER_STEP_X * 2400L)) / dda->total_steps * (F_CPU / 40000) / MAXIMUM_FEEDRATE_X) << 8;

coming from config.h, my relevant settings are:

#define F_CPU 16000000L
#define STEPS_PER_MM_X 40.000
#define MAXIMUM_FEEDRATE_X 3000.0

can someone give me a bump in the right direction here?

And offcourse, after reading over my own post right after posting it, I spotted a problem.

Changed maximum feedrate to be integers, and it compiles now. Let's see if it will work :-)

Will upload to the board once I am done working.

Edited 1 time(s). Last edit at 01/14/2011 10:54AM by WebSpider.

Gentlepeople,

Thanks to Avrmax I got the FiveD to upload to my 168. (http://forums.reprap.org/read.php?147,33082,70321#msg-70321).
That's a milestone..

Now I need to get my host software talking to my Arduino.
So I installed both RepRap Host and Repsnapper as I was having some trouble getting RepRap Host to talk so I endeavoured to eliminate faulty host software.

However either do not seem to be able to generate movement in my physical machine. But a sample code to test my steppers works perfectly, so all my physical connections should be intact.

Checking the output when I send M114 to the Arduino I get "ok X:0,Y:0,Z:0,E:0,F:50 with parameters X:0,Y:0,Z:0,E:0,F:50" which I think is correct. So my Host must be talking to the Arduino correctly.

So I am thinking that I might have misunderstood the way the Pins are defined. I am thinking that on my little 168, if I define DIO4 that this defines the physical Digital Pin 4 on my board. Is this correct??

The rest of my definitions looks like the following:

#define	X_STEP_PIN						DIO4
	#define	X_DIR_PIN							DIO5
	#define	X_MIN_PIN							DIO1

	#define	Y_STEP_PIN						DIO6
	#define	Y_DIR_PIN							DIO7
	#define	Y_MIN_PIN							DIO2

	#define	Z_STEP_PIN						DIO8
	#define	Z_DIR_PIN							DIO9
	#define	Z_MIN_PIN							DIO3

	#define	E_STEP_PIN						DIO10
	#define	E_DIR_PIN							DIO11

	#define	PS_ON_PIN							DIO12

Other thing is, I am only using 3 stepper motors at the moment. No other equipment is hooked up. No stops, no extruder yet. And they are connected to Digital Outputs 4 to 9. Why would I need to define the "MIN_PIN" for each axis?? What is "MIN_PIN"?? If I define them out I get an error in my compiler so obviously they are integral to the workings of the software.
And what is PS_ON_PIN?

Thanks for taking the time to answer questions. And I hope that any answers to my question would help others as well. I have gone through all 13 pages of this forum but not been able to figure it out for myself..

I had the same questions when I started and the same set up.
you are correct in that DIO4 is digital Pin 4

that section of your config looks good.
what are your
STEP_PER_MM settings and MAXIMUM_FEEDRATE?
these had a lot with me getting my steppers to work.
I am working with getting repsnapper to work with this firmware at the moment too.
and the MIN settings are for the endstops.

Edited 1 time(s). Last edit at 01/14/2011 09:24PM by Architect.

*_MIN_PIN is the minimum endstop sensor, for detecting when the motors have reached absolute zero position.

PS_ON_PIN is the pin I connect to my ATX power supply to turn it on and off as necessary. It can also be used as a grouped enable line for your stepper drivers if they're active low. I actually haven't checked how things go if this isn't defined, I will check soon.

if you send G1X10Y10, what happens, and what does M114 report afterwards?

---

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

@ Architect
Well. I thought I'd be clever and not change any of those settings until I see some physical output from the motors so as to make sure I don't make any mistakes that cause me to chase my tail.
So STEP_PER_MM is all set at 320.00 and MAXIMUM_FEEDRATE is 200 for X,Y and E and 100 for E.
I am guessing that that was a bad idea and should really be setting the parameters to suit my machine?

@Triffid_Hunter
If I comment out PS_ON_PIN the program still compiles and uploads to my 168 fine. Hope that answers your question without having to try it out yourself.
When I send G1X10Y10 nothing happens physically, but I get back:

Received: ok with parameter ****************

When I send M114 afterwards it says:

Received: ok X:3200,Y:3200,Z:0,E:0,F:50 with parameters  X:3200,Y:3200,Z:0,E:0,F:50

So I am assuming that the Arduino thinks it has moved but it actually hasn't?
Are physical switches on the MIN_PINs necessary for the software to work? Ie. I only have 3 stepper motors attached and no switches.

Thanks for verifying what the PS and MIN pins are for and confirming that DIO4 is actually Pin4. Hope this helps others who are starting out with the software as well. (perhaps it should be included in the Readme or the Wiki?)

Edited 2 time(s). Last edit at 01/15/2011 04:24PM by edictor.

do your stepper controllers have enable pins? are they asserted? Some are active high, most are active low- are yours pulled the right way? can you connect a LED or some other debug indicator to the step pins, check that they're generating pulses? The duty cycle is fairly low, so use a really bright led if you can

---

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

I did the same thing for awhile, man that seems like a long time ago, and its only been a month. try messing with the feed rate in repsnapper.
under the menu Edit -> Printer settings you can change the Min/Max Print settings. this is the F value when manually trying to move the axis. try about 1500 depending on your driver. I found that I can play with the value here then set the FeedRATE in the firmware to cap it. I could set it to 3000 for my easystepper drivers but only 2000 for my pololu stepper drivers. sorry to be so sparce on responses, I've been building my extruder hot end for the last few days cuz makergear.com is got my order on backorder. now I gotta do all this by hand. :-) I should be at the bar...

Cheers!
Trout

@ Triffid_Hunter
I am using Easydriver Boards. The steppers do turn with the sample code and the same physical wiring so I assume that they are enabled. You have me doubting myself though as I am not using the Enable point on the board.
I will hook up an LED tomorrow if I can find one.

@ Architect
Will also try that tomorrow, but I don't think it should make a difference? Default settings should at least get me some sort of output? Testing with the LED should uncover something..
And why would you have to be at the bar when you can be out creating stuff with your own two hands?

Edited 1 time(s). Last edit at 01/16/2011 02:10PM by edictor.

Architect Wrote:
-------------------------------------------------------
> So, I tried the drill thing. Signal worked
> clean every time, even wrapped my optical sensor
> cables 5 times around my drill and ran it. that
> was fun and a little mad hatterish. so I think I
> have a very simple solution in place now for the
> stops. Don't step if the axis.direction = whats
> read from the axis.min_stop_pin. seems to be
> working very well and when I thought about it, if
> there is a temporary misfire of the
> axis.min_stop_pin it would have to be at the exact
> timing it is being read which is right before a
> step it written and it would have to be a very
> long interruption to cause multiple steps to not
> fire to actually be noticeable.

It only takes one incorrect read on the wrong axis at the wrong moment to completely and totally ruin a print.

What happens is this: The DDA algo steps until it can't step anymore, which is when all axises are at their target location, so the current location is set to the target location and we go on to the next prepared DDA.

When an endstop prevents the primary (fastest-moving) axis from stepping, that often means the DDA doesn't step that round, which then (incorrectly) means it's done, which is (incorrectly) taken to mean it must be at it's target location. So the current location is set (incorrectly) to the target location, and on we blithely go to the next prepared DDA. Only now the real location doesn't at all match the supposed location. It's equivalent to suddenly and randomly dropping steps on both X and Y at the same time. And probably several millimeters worth of steps too. (actual steps dropped would on average be 1/2 the average movement length)

Obviously *you* have a rock solid, tested electronics setup, but how many people take the time to acid-test the endstop misfiring problem? Almost none.

And honestly, who cares? It works to ignore the endstops during normal moves, and just use them for initial positioning. That assumes that the CAM software is implementing "soft endstops" and not generating moves that would be beyond the bounds of the machine. If it's not, of course you have other problems.

Sorry to be purist on this, but I know that I'm not the only one with marginal signal paths. It's a common problem, and it's difficult to be absolutely sure you've 100% fixed it forever and ever. I've replaced my endstop wiring with shielded 18/2 twisted pair. And I've rerouted the wires. But I'm still not willing to trust that they'll never ever give a false reading! Especially when it would potentially completely ruin a print.

The implementation nophead has uses a completely different movement loop for homeing. I think this is the correct implementation, in part because it's also part of the g-code spec. G0 movement is "fast, uncoordinated" movement. That's impossible to implement within the DDA, because the very nature of the DDA is to lockstep the axises to a particular destination. If it's a common enough solution to be embeded in the g-code spec *and* independently implemented by nophead, there's probably more than one reason for it.


The implementation that I came up with is /masterhere Approximately, anyway. I worked on it between 11-14-2010 and 11-20-2010. Most of the code is on the tail end of dda.c, though some is in gcode_parse.c.

There's still problems with my implementation. Among them are: G92 is supposed to be per axis, and doesn't set the "home" to zero, it sets the current location to be foo on a per-axis basis. This btw is how some other implementations get around the E axis overflowing - manually reset it at the end of each layer. This implementation looks too much like a DDA. There must be a simpler/faster way to do it, but I drew a blank. This implementation has a arbitrary maximum of 100us between step signals, meaning 10Khz max step rate when homing (I'm pretty sure the DDA's max is higher).

Also note that this code works if MAX is defined instead of MIN for each axis, meaning the axis has to "home" the other direction. And inverted endstops are accounted for. And missing endstops are OK too. I.E. if you have a X and Y endstop, but no Z, this will still work. It's ugly, but it works. For certain values of "works", as noted above. Not tested by anybody other than me. Well, when I visited Bill we tried to run it on his machine, but only spent a half-hour or so on it, and didn't get the pinouts set correctly, so little useful testing was done.

---

--
I'm building it with Baling Wire

that all sounds a bit complicated. I was keeping it as simple as possible. basically I want the end stops to be there for 2 reasons. homing Zero and not letting the axis crash into anything. so I put in a check (for min) right before the step call to each axis pin but do all the other house keeping i.e. count the step ans set did_step and all, just don't write the step to the pin if there is a signal on the endstop. the theory is, if its an actual endstop signal then when the DDA is complete we will be at the end if not then we only skip one step on one axis during one DDA movement.

So, having taken Christmas off from repstrap building and then concentrating on completing fabrication of my cartesian robot, I find myself with little else to do other than software and firmware. While waiting for the thread locker to dry on the penultimate step of fabrication I downloaded the most recent commit from the master branch (4febbe) and uploaded it, to see if I could get the heater working. Unfortunately I am still having the same trouble as my last attempt (see here,and here).

To review:

>I just have a resistor and led connected to the heater pin (arduino pin D6). The led is always very >dimly lit and there is .01v between the heater pin and ground. This never changes no matter what I >set the heater temp to (eg. m104 s100).

>I tried the m135 command which produced a short flash of the led I have imitating my heater. The >flash varied in brightness depending on the value I gave m135 (m135 s50 = dim flash, m135 s250 = >brighter flash) but always lasted less than a second.

I have modified the following lines in heater.c to get some debug feedback.

	//#ifdef	DEBUG
	//if (debug_flags & DEBUG_PID)
		sersendf_P(PSTR("T{E:%d, P:%d * %ld = %ld / I:%d * %ld = %ld / D:%d * %ld = %ld # O: %ld = %u}\n"), t_error, heater_p, heaters_pid[h].p_factor, (int32_t) heater_p * heaters_pid[h].p_factor / PID_SCALE, heaters_runtime[h].heater_i, heaters_pid[h].i_factor, (int32_t) heaters_runtime[h].heater_i * heaters_pid[h].i_factor / PID_SCALE, heater_d, heaters_pid[h].d_factor, (int32_t) heater_d * heaters_pid[h].d_factor / PID_SCALE, pid_output_intermed, pid_output);
	//#endif

void heater_set(uint8_t index, uint8_t value) {
	#if NUM_HEATERS > 0
	if (heaters[index].heater_pwm) {
		*(heaters[index].heater_pwm) = value;
		//#ifdef	DEBUG
		//if (debug_flags & DEBUG_PID)
			sersendf_P(PSTR("PWM{%u = %u}\n"), index, OCR0A);
		//#endif
	}
	else {
		if (value >= 8)
			*(heaters[index].heater_port) |= MASK(heaters[index].heater_pin);
		else
			*(heaters[index].heater_port) &= ~MASK(heaters[index].heater_pin);
	}
	#endif /* if NUM_HEATERS > 0 */

Now I get a lot of feedback from the firmware. Below are examples of how the feedback changes in response to m104 and m135.

Command sent - m104 s100 (the ok is where the command was processed)

T{E:-79, P:-79 * -1 = 0 / I:1 * -1 = 0 / D:-2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-77, P:-77 * -1 = 0
/ I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
ok
T{E:323, P:323 * -1 = 0 / I:-1 * -1 = 0 / D:2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:323, P:323 * -1 = 0 / I:-1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:321, P:321 * -1 = 0 / I:-1 * -1 = 0 / D:-2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:323, P:323 * -1 = 0 / I:-1 * -1 = 0 / D:2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}


Command sent - m104 s0 (the ok is where the command was processed)

T{E:323, P:323 * -1 = 0 / I:-1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:323, P:323 * -1 = 0 / I:-1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}

T{E:323, P:323 * -1 = 0 / I:-1 * -1 = 0 / D:-2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
ok PWM{0 = 0}

T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-79, P:-79 * -1 = 0 / I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}

Command sent - m135 s250 (the ok is where the command was processed)

T{E:-75, P:-75 * -1 = 0 / I:1 * -1 = 0 / D:2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-75, P:-75 * -1 = 0 / I:1 * -1 = 0 / D:2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:-2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}

T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:0 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
ok PWM{0 = 250}

T{E:-70, P:-70 * -1 = 0 / I:1 * -1 = 0 / D:7 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-77, P:-77 * -1 = 0 / I:1 * -1 = 0 / D:-2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-79, P:-79 * -1 = 0 / I:1 * -1 = 0 / D:-2 * -1 = 0 # O: 0 = 0}
PWM{0 = 0}

I quickly realized this means very little to me. All I can see is that some numbers at least change in response to those commands.

Can anyone tell me if this sheds any light on the trouble I am having? Are there any other debug codes I should enable that might prove more enlightening?

Having only one more step (mounting the extruder, which I don't want to do before testing it) before having a mechanically complete repstrap, I would very much like to start printing soon. I would also like to not have to buy a sanguino or arduino mega and run the official fived firmware. This leads me to ask if anyone has successfully printed without modifying the code other than the Makefile and config.h?

I have attached my config.h and heater.c.


Any help is greatly appreciated.
Thanks

P.S. I no longer have to force AVRDUDE to program the chip thanks this info from avrmax

6. Yikes! error
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.

found in covered in [www.arduino.cc]
Wrong avrdude used changed FiveD Makefile to :

#AVRDUDE = avrdude
#AVRDUDECONF = /etc/avrdude.conf
AVRDUDE = /home//arduino/arduino-0022/hardware/tools/avrdude
AVRDUDECONF = /home//arduino/arduino-0022/hardware/tools/avrdude.conf

Yippee! Got 100% with $ make program


Thank you very much. Maybe this should go onto the wiki page (if it hasn't since the last time I looked).

spaztik: perfect, I see exactly what your problem is. See all those multiply by -1? You need to program PID settings into the eeprom! apparently, my blank eeprom detection code failed for you- usually it writes defaults in if your eeprom is blank. use M130-M133 to provide settings, then M134 to save to eeprom. There are defaults in heater.c, note the scale factor (usually 1024). Also note that I_factor * I_limit should be about 192, or whatever value will maintain your highest set temperature.

---

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

Wow 28 minutes, thats gotta be some kind of record or something.

I used these defaults from heater.c:

#define DEFAULT_P 8192
#define DEFAULT_I 512
#define DEFAULT_D 24576
#define DEFAULT_I_LIMIT 384

and entered them like this:

m130 s8192
m131 s512
m132 s24576
m133 s384
m134

the output is now this:

m104 s100

T{E:-77, P:-77 * 0 = 0 / I:-384 * 0 = 0 / D:2 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}

T{E:-79, P:-79 * 0 = 0 / I:-384 * 0 = 0 / D:0 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}
ok
T{E:321, P:321 * 0 = 0 / I:-63 * 0 = 0 / D:0 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:323, P:323 * 0 = 0 / I:260 * 0 = 0 / D:2 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}

m135 s250

T{E:-79, P:-79 * 0 = 0 / I:-384 * 0 = 0 / D:-2 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}

T{E:-77, P:-77 * 0 = 0 / I:-384 * 0 = 0 / D:0 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}
ok PWM{0 = 250}

T{E:-72, P:-72 * 0 = 0 / I:-384 * 0 = 0 / D:5 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}
T{E:-79, P:-79 * 0 = 0 / I:-384 * 0 = 0 / D:0 * 0 = 0 # O: 0 = 0}
PWM{0 = 0}

The -1s are gone but replaced with 0s which doesn't seem much better.

>note the scale factor (usually 1024)

I'm not sure what this means.

>Also note that I_factor * I_limit should be about 192

512 * 384 /= 192, I must be missing something here.

8192 * 1024 > 65536, result 0

try M130S8 etc

---

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

Hmm.. That only confused me more..

I attached the LEDs and they light up whenever I issue a manual move command from either Repsnapper or ReprapHost. But it seems to hang as I have to reset the Arduino to turn off the LEDs again. Motors do not move.
Even issuing the command to move just one axis causes all LEDs to all 3 driver boards to light up.

Peculiar thing is that with Reprap Host I get this response:

ERROR: GCodeReaderAndWriter.getX () - no value stored! [27.794s/672ms]
ERROR: GCodeReaderAndWriter.getY() - no value stored! [27.795s/1ms]
ERROR: GCodeReaderAndWriter.getZ() - no value stored! [27.795s/0ms]
ERROR: GCodeReaderAndWriter.getE() - no value stored! [27.795s/0ms]
ERROR: GCodeReaderAndWriter.getETemp() - no value stored! [28.623s/828ms]
ERROR: GCodeReaderAndWriter.getBTemp() - no value stored! [28.626s/3ms]
ERROR: GCodeReaderAndWriter.getBTemp() - no value stored! [30.129s/1503ms]

I am not too sure what that is about..

I think I have to retrace my steps and start afresh again.

Just to be sure, I had loaded the sample code again to the Arduino and all 3 steppers are still making the right motions.

@Architect
Changing the settings of feedrate didn't change anything unfortunately..

Edited 1 time(s). Last edit at 01/17/2011 02:33AM by edictor.

edictor Wrote:
-------------------------------------------------------
> I attached the LEDs and they light up whenever I
> issue a manual move command from either Repsnapper
> or ReprapHost. But it seems to hang as I have to
> reset the Arduino to turn off the LEDs again.
> Motors do not move.
> Even issuing the command to move just one axis
> causes all LEDs to all 3 driver boards to light
> up.

what signal did you hook the leds to? step, dir, enable, min, max?

---

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

Tried to get this working on XCBot, which has a custom RAMPS settup. (different pins, on a breadboard)

Things went well until I tried to set up the heaters...

In the Config.h I set the motor pins and steps per mm
commented out #Define Gen3
Changed values for steps and speed
Defined Pins.. had to change AIO to DIO for the top bunch of pins (X and Y)

There is some wierd programer stuff going on with heater control...

I defined the TEMP_PIN_CHANNEL as AIO1
set num_temp_sensors to 1
Changed Type to TT_THERMISTOR pin 1, heater 0 > 0 is for the offsett position...
Set number of heaters to 1

Uncommented and changed the pins and interrupt timer (as per the table at the bottom):

} heaters[NUM_HEATERS] =
{
// port pin pwm
{ &PORTD, PINB7, &OC0A },
// { &PORTD, PIND5, &OCR0B }


This is where it rolls over...


I tried a couple different pins.. I tried changing the portD to B... I get the error:


C:\Users\alan\AppData\Local\Temp\build496314725904670695.tmp\/config.h:300: error: 'DIO13' undeclared here (not in a function)


My Config.h file: [pastebin.com]

Not sure what's up... I can get it to compile with all of the above changes, except the last heater pins assignment...

I haven't tried to get it to run on the bot yet.. waiting till I get my pins sorted out.

Al...

Edited 1 time(s). Last edit at 01/17/2011 09:05AM by araspitfire.

---

[araspitfire.blogspot.com]

edictor Wrote:
-------------------------------------------------------
> Hmm.. That only confused me more..
>
> I attached the LEDs and they light up whenever I
> issue a manual move command from either Repsnapper
> or ReprapHost. But it seems to hang as I have to
> reset the Arduino to turn off the LEDs again.
> Motors do not move.
> Even issuing the command to move just one axis
> causes all LEDs to all 3 driver boards to light
> up.
>
> Peculiar thing is that with Reprap Host I get this
> response:

> I am not too sure what that is about..
>
> I think I have to retrace my steps and start
> afresh again.
>
> Just to be sure, I had loaded the sample code
> again to the Arduino and all 3 steppers are still
> making the right motions.
>
> @Architect
> Changing the settings of feedrate didn't change
> anything unfortunately..

I found that using the MENDEL_TALK command line tool from the func.sh scripts helped out when I started. I don't know if you are running your host on a *nix box or windows, but if you are on a UNIX variant then the func.sh was very helpful in my early testing.

Triffid_Hunter Wrote:
-------------------------------------------------------
> 8192 * 1024 > 65536, result 0
>
> try M130S8 etc

Thanks Triffid, I will try this when I get home from work tonight. I am still not certain of what to do here, but this is what I am thinking.

8192/1024 = 8 therefore m130 s8, then do I divide all the default numbers I found in heater.c by 1024, like this?

512/1024 = .5 - m131 s0.5

24576/1024 = 24 - m132 s24

384/1024 = .375 - m133 s0.375

Is this correct? I really don't know what is going on here with P I D and I_limit, is there something I can read to help me understand?

Edit: After thinking about this for a while, I am wondering if I_limit should get divided by 1024 or not, because it is not a factor (like p_factor, I_factor and D_factor). Also because 384 * 0.5 = 192.

Edited 1 time(s). Last edit at 01/17/2011 12:47PM by spaztik.

Architect Wrote:
-------------------------------------------------------
> that all sounds a bit complicated. I was keeping
> it as simple as possible. basically I want the end
> stops to be there for 2 reasons. homing Zero and
> not letting the axis crash into anything. so I put
> in a check (for min) right before the step call to
> each axis pin but do all the other house keeping
> i.e. count the step ans set did_step and all, just
> don't write the step to the pin if there is a
> signal on the endstop. the theory is, if its an
> actual endstop signal then when the DDA is
> complete we will be at the end if not then we only
> skip one step on one axis during one DDA movement.

Setting did_step is the most important thing - so that's good. Missing one step is certainly better than missing the most part of a movement.

Would it be possible to set did_step, but skip the rest of the housekeeping? That way the major axis would keep going a bit longer, while a minor axis would simply step the next time (counter is still <0). Of course, then it'd never actually STOP when it really did hit an endstop, it'd just not move any further. How to detect that?

I still think a separate G0 movement routine is the correct way to go. Missing a step is better, but still bad. Also, doing MAX endstops and / or dealing with missing endstops will get really messy no matter which way you slice it. Add to that the desired "hit the endstop fast, then back off of it slowly to get more exact positioning" behavior, it's messy.

Have you looked at "correct" homing behavior vs. reprap standard behavior? i.e. correct behavior is to go to 0,0,0 even if a G92 command has moved 0,0,0 to some arbitrary locaiton. The more typical reprap behavior which is to interpret "go home" as "go mash the endstops and set current location to 0,0,0" which is technically all wrong, as it loses G92's information. I don't know the right answer to that one, but I think it looks like storing the real vs. temporary location information, and using a special M-code to hit endstops and reset position when if a G92 code has been seen (expect for a G92 E0)

---

--
I'm building it with Baling Wire

spaztik Wrote:
-------------------------------------------------------
> 8192/1024 = 8 therefore m130 s8, then do I divide
> all the default numbers I found in heater.c by
> 1024, like this?
>
> 512/1024 = .5 - m131 s0.5
>
> 24576/1024 = 24 - m132 s24
>
> 384/1024 = .375 - m133 s0.375
>
> Is this correct? I really don't know what is going
> on here with P I D and I_limit, is there something
> I can read to help me understand?
>
> Edit: After thinking about this for a while, I am
> wondering if I_limit should get divided by 1024 or
> not, because it is not a factor (like p_factor,
> I_factor and D_factor). Also because 384 * 0.5 =
> 192.

Sounds exactly right to me

Google "PID without a PhD" for tuning help

araspitfire Wrote:
-------------------------------------------------------
Try OCR0A, otherwise looks good

---

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