annodomini2 Wrote:
-------------------------------------------------------
> nophead Wrote:
> --------------------------------------------------
> -----
> > I think your casts are in the wrong place and
> the
> > ANDs are unnecessary.
> >
> >
> > void serwrite_hex16(uint16_t v)
> > {
> > serwrite_hex8((uint8_t) (v >> 8));
> > serwrite_hex8((uint8_t) v);
> > }
> >
> > void serwrite_hex32(uint32_t v)
> > {
> > serwrite_hex16((uint16_t) (v >> 16));
> > serwrite_hex16((uint16_t) v));
> > }
> >
>
> Not been on for a little while, the AND's (bit
> masking) are typically used if the code could be
> used on different architectures (e.g. 32 bit),
> different compilers handle the casting situation
> in different ways and on 8 and 16 bit micro's the
> math implementation can have a big impact.

I have to disagree, the ANDs in the source code are unnecessary, even on 32 bit systems. The compiler will generate them if needed.Typically they are not.

---

[www.hydraraptor.blogspot.com]

Shortening function names will only reduce the size of the object code files. It won't affect the size of the binary loaded into the micro.

---

[www.hydraraptor.blogspot.com]

I'd like to ask if homing using endstops is supposed to work (in current master branch). I have ramps w. mega 2560, pin settings in config.h loks correct, if I check endstop function using simple arduino program they work. But pressing "Home" in repsnapper just moves the bed to position where it was on last reboot. If i undefine Y_MIN it rams into endstop and tries to move the bed further. If I undefine Y_MAX it fails to compile:

home.c: In function ‘home_y_positive’:
home.c:189: error: ‘Y_MAX’ undeclared (first use in this function)
home.c:189: error: (Each undeclared identifier is reported only once
home.c:189: error: for each function it appears in.)
make: *** [home.o] Error 1

axtheb Wrote:
-------------------------------------------------------
> I'd like to ask if homing using endstops is
> supposed to work (in current master branch). I
> have ramps w. mega 2560, pin settings in config.h
> loks correct, if I check endstop function using
> simple arduino program they work. But pressing
> "Home" in repsnapper just moves the bed to
> position where it was on last reboot. If i
> undefine Y_MIN it rams into endstop and tries to
> move the bed further.

Unfortunately I can't test this until I have a space to set up my hardware. Hopefully others following this thread can help us work it out

> If I undefine Y_MAX it fails
> to compile:
>
> home.c: In function ‘home_y_positive’:
> home.c:189: error: ‘Y_MAX’ undeclared (first
> use in this function)
> home.c:189: error: (Each undeclared identifier is
> reported only once
> home.c:189: error: for each function it appears
> in.)
> make: *** Error 1

That will be because you still have Y_MAX_PIN defined. I think it's ok for the compiler to spit an error if you've told it to use the max endstop, but haven't told it where it is...

---

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

Please don't confuse X_MAX_PIN, the endstop I/O pin, and X_MAX, the soft axis limit. It should be ok to have a X_MAX_PIN endstop, but not a soft limit.

Workaround would be to remove all code inside home_x_positive(), home_y_positive() and home_z_positive(). That's used for G162 "Home Positive" only, a command one can well live without. Use G161 "Home Negative" instead.

Regarding endstop usage in normal operation, there is none, and that's intentional. Sometimes endstops catch a bit of electromagnetic noise and trigger for just a moment. Not good if that ruins an entire build.

For a peek into the future, have a look at the "endstop" branch. Endstop handling during normal operation and with proper denoising is around the corner and home.c will eventually go away.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Triffid_Hunter Wrote:
> That will be because you still have Y_MAX_PIN
> defined. I think it's ok for the compiler to spit
> an error if you've told it to use the max endstop,
> but haven't told it where it is...

I dont think so. I want to use both endstops, so the it should move the bed both ways and discover where the limits are.

Traumflug Wrote:
> Regarding endstop usage in normal operation, there
> is none, and that's intentional. Sometimes
> endstops catch a bit of electromagnetic noise and
> trigger for just a moment. Not good if that ruins
> an entire build.

Problem is that I could not get endstops to work even when homing.

axtheb, put something like this into clock_250ms(), which is in clock.c:

#include "pinio.h"
serial_writechar('0' + x_min());

to find out what's going on. This will print you a lot of zeroes normally, and ones in case the endstop is triggered.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

How much testing are the main devs doing on some form of hardware?

I'm just not getting Teacup to do much of anything, frankly. The only success I have had is the thermistor and heater, and even that will error out during if you try to use bang-bang mode by using the suggested method of setting the PWM timer to 0.

I'm not getting out any steps. I can communicate to Teacup through a terminal, read back firmware version, set feedrates, etc. But when it comes to actually generating a pulsetrain, things get weird.

I've disconnected my machine and am now using an Arduino Uno sitting on my desk with the Y step pin connected to an LED. Theoretically, I should see some activity when a pulse train is attempted. I've testing using an oscilloscope, too.

Here's a typical result. My config.h is set to the default settings. I'll start up a terminal and see the start and ok responses from Teacup. Just to be sure, I'll send a G90 and an M190 and get ok responses. Then I'll send a command like "G1 X0.00 Y10.00 Z0.00 F100.00". Nothing happens...but wait. There is a tiny flash from the LED approximately once per second. If the feedrate is set slower, the LED on the step pin might go several seconds between flashes.

While this is happening, you can use the M114 command to view Teacup's idea of the axis position. In the command above, Y will increment by 1 every second or so, far beyond the target 10 position. It will keep going forever. If you use an M112 to halt the move, then tell Y to go to 5, the same thing happens, it undershoots 5, and over the course of the minutes I was patient enough to wait, it will go negative below the soft limit.

So, obviously, this ain't right. I'm not using Git, I'm downloading the zip file for the master branch. I unzip it into my Arduino sketch folder, rename the directory to Teacup_Firmware, edit config.h, and compile/download it in Arduino-022. Based on the wiki that should all be fine.

Any suggestions? Any other info I can provide?

I'm between houses and haven't room for any hardware unfortunately.. I do what testing I can, and ask others in this forum to test new stuff I come up with. Hopefully my situation will change soon

Having said that, your reported behaviour sounds like the step timer is broken. this is the point where you start using git, and tell us if commit 0ec0d360be5e3 works better, or any earlier commits you decide to try. If you find an earlier commit that works correctly, do a git bisect to find the particular commit that breaks things.

---

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

I have a mendel with GEN3 running with Teacup firmware, and test/use it quite often. I will check tonight if there's a serious regression.

You could attach the config.h file, and what kind of hardware you're using.

I hooked up my bare arduino (no motherboard) and with HEAD,

Start
ok
M115
ok FIRMWARE_NAME:Teacup FIRMWARE_URL:http%3A//github.com/triffid/Teacup_Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:1 HEATER_COUNT:2
G1X10
ok 
M114
ok X:199,Y:0,Z:0,E:0,F:50
M114
ok X:459,Y:0,Z:0,E:0,F:50
M114
ok X:699,Y:0,Z:0,E:0,F:50
M114
ok X:1272,Y:0,Z:0,E:0,F:50
M114
ok X:1536,Y:0,Z:0,E:0,F:50
M114
ok X:1798,Y:0,Z:0,E:0,F:50
M114
ok X:2067,Y:0,Z:0,E:0,F:50
M114
ok X:2340,Y:0,Z:0,E:0,F:50
M114
ok X:2594,Y:0,Z:0,E:0,F:50
M114
ok X:2864,Y:0,Z:0,E:0,F:50
M114
ok X:3144,Y:0,Z:0,E:0,F:50
M114
ok X:3200,Y:0,Z:0,E:0,F:50
M114
ok X:3200,Y:0,Z:0,E:0,F:50
M114
ok X:3200,Y:0,Z:0,E:0,F:50

I ran M114 about as fast as I could type it in, so I'm not seeing the bug you describe. As traumflug says, please post your config so we can try to reproduce it

---

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

My machine is working fine with current master.

I attached the config file. Nothing fancy. As mentioned above I gave up connecting it to any hardware and reverted to the default config file in hopes of seeing some pulses. All I've changed is disabling the thermistor and heater, since in the default config.h the thermistor pin conflicts with X axis pins.

I'm using an Arduino Uno (328p of course), Arduino 0022 on Windows 7 Pro 64bit. I download the zip file for the master branch. I assume that file contains the most recent changes anyway.

Triffid_Hunter: have you tried hooking up an oscilloscope or an LED to any step pins to see if something happens? Your activity log appears correct, so hopefully it's working. Also, can you tell me what Arduino you're using for that test?

Thanks

I'm using a 328p too. I didn't have anything hooked up for that particular test, but every time I do I have motors turning at appropriate rates.

I didn't even know github provided zips, everyone else uses the git interface. I don't think that would make a difference but it's always possible.

On another note, I did once see behaviour vaguely similar to what you describe, and that's when I had 12v going into my '168 shortly before it caught fire.

I'll try out your config shortly when I get the opportunity

---

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

That's how I got so far outta wack with the repository. I started out with the zip download.

I set up and used Git instead of downloading the zip file, and it did not make a difference. The Arduino works fine otherwise. Triffid_Hunter: you said you used a 328p, but didn't mention the actual type of Arduino?

Re Comunication protocol for Repsnapper >> Teacup // race condition.

On looking through the communication code used by the Tonokip RepRap firmware (that works with Repsnapper)

There is this ClearToSend ~ handshake code that is sent after instructions sent from the host.

inline void ClearToSend()
{
  previous_millis_cmd = millis();
  Serial.println("ok"); 
}

In the Teacup code "ok" appears to only be sent after start is sent.. it seems to be sent as part of the "start" string.

serial_writestr_P(PSTR("start\nok\n"));

I think this is where the race condition is in the teacup code when communicating to Repsnapper.

It would seem to explain why it works only at certain baud rates or only on the third attempt as some one said.

Could any one who understands the Teacup code better than me at the moment confim this for me ?

Maybe even sugest a way to fix this problem... if I am correct

---

Bodge It [reprap.org]
=======================================

---

BIQ Sanguinololu SD LCD board	BIQ Stepcon	BIQ Opto Endstop
BIQ Heater Block PCB	BIQ Extruder Peek clamp replacement	BIQ Huxley Seedling
BIQ Sanguinololu mounting	BIQ standalone Sanguinololu or Ramps mounting	Print It Stick It Cut it

My rep strap: [repstrapbertha.blogspot.com]

Buy the bits from B&Q pipestrap [diyrepstrap.blogspot.com]
How to Build a Darwin without any Rep Rap Parts [repstrapdarwin.blogspot.com]
Web Site [www.takeaway3dtech.com]

All right so this is why I wanted to know what exact hardware was used...I noticed that with all the stuff I had disabled, the hex size was small enough to fit on a Diecimila. So I tried that and it works. Changed board type to Uno, uploaded, doesn't work. Hope this helps anyone else unfortunate enough to have the same problem. Now we need to figure out why.

Yeah mine is a diecimila, I've heard that there are lots of issues with the uno family, slowly being solved. I really don't understand why the usb serial chip would have any bearing on the operation of the chip behind it, maybe some sort of host-side linker bug or something? Are you compiling with the IDE or with the makefile? Makefile doesn't care what board you have, only the chip on said board

---

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

BodgeIt Wrote:
-------------------------------------------------------
> Re Comunication protocol for Repsnapper >> Teacup
> // race condition.
>
> On looking through the communication code used by
> the Tonokip RepRap firmware (that works with
> Repsnapper)
>
> There is this ClearToSend ~ handshake code that is
> sent after instructions sent from the host.
>
> inline void ClearToSend()
> {
> previous_millis_cmd = millis();
> Serial.println("ok");
> }

This seems to record the time that ok was sent before sending it - what do you suggest this solves?

> In the Teacup code "ok" appears to only be sent
> after start is sent.. it seems to be sent as part
> of the "start" string.

Check gcode_parse.c near gcode_process() for the command response ok. The start ok is to kickstart comms if the host said something before we started, or if we reset or something like that. Does removing it help?

> I think this is where the race condition is in the
> teacup code when communicating to Repsnapper.

Where is the race? Which two things occur in an indeterminate order?

> Could any one who understands the Teacup code
> better than me at the moment confim this for me ?

You want a delay between start and ok? A delay between newline and ok? Something else?

I don't understand what you think is going on, nor what you think should be going on and the difference between them. Perhaps some serial logs showing differences would help?

---

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

Triffid_Hunter: I'm using the IDE to upload. I think using the ZIP file is also OK, it appears to have the latest commit on the master branch. At least, the ZIP checksum changes every time you do a commit. The problem was definitely some difference between the Uno and the Diecimila/Duemilenova. And for most people, using the ZIP download and the Arduino IDE is a nice and simple way to try it out, compared to Git, makefiles, and ISP hardware.

I'm going to try swapping chips on these two Arduinos to figure out where the problem lies...the 8u2, Optiboot, or somewhere else. If it looks like the 8u2 is the culprit, I'll go ahead and fire up the hot air gun and swap a 328p into a 168 Seeeduino I have.

Yep, the Uno 328p still doesn't work with Teacup when placed in a Diecimila board (requires manual reset to program too). So, there's something about the Uno firmware that is incompatible; either the bootloader, or something the IDE does when downloading to the Uno.

Hm, my 328p has optiboot on it... Put it on myself when I cooked my 168.

On an unrelated note, there's $50 paypal credits and $50 makergear store credit up for grabs to the first person who posts exact versions of an entire working toolchain (slicer, sender, firmware) for ramps 1.1 that Just Works out of the box on the maker gear mailing list . If teacup works that well for you, post now!

---

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

I did just get Teacup ~working with ReplicatorG after putting a new 328p on the Seeeduino. Got some filament extruding finally. I'm using the stepper drivers that came with my robot. It's not working all that well, since the ReplicatorG control panel will keep locking up for 5 to infinite seconds at random times. I think it's waiting for an OK that it didn't get. It wouldn't work at all until I dialed everything back to 57600.

But I'm planning to stick with Teacup here on out, I know you guys keep improving it every day and I'll eventually have some fixes to add too. Teacup just seems like the most efficient, reasonable approach so far, or at least it will be when it's stable. And it's C, which means I can wrap my brain around it.

Looks like you are experiencing similar problems with RepG that I get.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

It's not working all that well, since the ReplicatorG control panel will keep locking up for 5 to infinite seconds at random times.

Teacup features a movement queue, so the "ok" is sent after the command is received and _before_ it's executed. Especially when more than one command is sent, this can make a difference of several seconds (the time it takes to execute the current movement).

Quote

It wouldn't work at all until I dialed everything back to 57600.

This is expected, Teacup has 115200 baud hardcoded. If you're brave, you can change this in serial.c line 9, but no promises.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I've been running teacup at 57600 for the past few months now with no problems regarding the communication speed.
I feel its pretty stable at that rate.

OK

Teacup is great there is no doubt about it.

There are gonna be those (I am turning into one of those as I have some deadlines at the moment I need to meet with a machine that prints) that need to commission and test hardware/electronics and need a degree of confidence that they are working with a RepRap Tool Chain that can at least print a mini-mug. If only to eliminate them from the bucket of things that are not working.

I intend to stay with teacup for a while, but as it is part of a chain I need to know what other components it will work with with the minimum of intervention. It is going to be worth the projects while to pick at least one something (don't care at the moment what it is) and state very clearly what that preferred something is. I guess which version too.

Potential users then would have a guide as to what should definitely work and the rest may work but are untested.

As it stands at the moment the table in the wiki suggests that teacup works with just about anything, which may be considered misleading. It is also perhaps an unrealistic ask for the project to make it so.


As a straw poll who reading here prints whole pieces successfully and using which host/slicing software to directly run the machinery ??


Some feedback may help those of us attempting to eliminate that which definitely doesn't work and leave us with a smaller set to work with.

A curious thought is coming to me perhaps no one does, may be the only way to get reliable prints at the moment is to slice and save as G-code then off load this to the machinery using the scripts in the source bundle.

I dunno, guys what do you think ??

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Totally in agreement with you, aka47. I love the more polished interface of ReplicatorG and seeing it work was what finally made me take the plunge into building one of these things. The RepRap Host software is a prime example of traditional OSS reliability and user interface design Repsnapper's Windows port is abandoned.

I plan to jump in over on the RepG topic and try to get this working reliably. Perhaps XON/XOFF instead of depending on the protocol? Maybe the reprap5d driver for ReplicatorG is just buggy? Maybe it doesn't even work well with stock 5D firmware.

Quote

Potential users then would have a guide as to what should definitely work and the rest may work but are untested.

As hosts change often, and always without notice, such a list would be even less reliable. Host developers apparently don't care much about protocol accuracy, backwards compatibility or even fault tolerance, so the only way out is to test, debug, test, ...

Quote

As a straw poll who reading here prints whole pieces successfully and using which host/slicing software to directly run the machinery ??

I don't have an extruder yet, but PCB milling with terminal and XON/XOFF works reliably for thousands of lines of G-Code.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY