Project: Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
Then you just need to convince
> your host-side talker to supply this information
> at the end of a print, or whenever it might be
> appropriate. Who wants to send patches for repg,
> reprap host, repsnapper etc to show returned
> messages during/after a print?
>
RepSnapper prints all comms to a log that is visible by default. If you suggest some syntax, I could make libreprap (RepSnapper 2 already uses it) parse it and make the data easily usable by the host software. Other errors that can be attributed to particular line numbers could use this syntax too.

Quote

If you suggest some syntax, I could make libreprap (RepSnapper 2 already uses it) parse it and make the data easily usable by the host software.

At the first glance, how about printing everything coming back and unknown to the host app into one or more dialogs for the user? On normal operations and with DEBUG disabled, Teacup is pretty quiet. Regarding known messages, there's "E: ..." for errors, "T: ..." for temperatures and adding "P: ..." for positional reports as well as "M: ..." for general messages would be simple.

One headscratcher is compatibility with RepRap Host, though. I don't know about the current state of affairs, but a year ago even a single character coming back from the firmware unexpectedly caused RepRap Host to crash or hang the ugly way. Many people use RepRap Host for sending G-Code, so being incompatible here won't be helpful.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Triffid_Hunter Wrote:
-------------------------------------------------------
> hi all, please test endstop and intercom-protocol
> branches, tell me whether they're ready for
> merging, or post patches if not

Good job, intercom-protocol looks really good. Moving start_send to the main loop of the extruder fixes all intercom-lost issues here. I'm currently "stress" testing intercom at a packet rate of 100Hz, and not one lost packet in 10mins! Something I never accomplished with my workarounds.
Get/set temperatur heater/bed works. I've not yet tested the PID stuff as I'm not familiar with it.

If you want to see what is happening in your serial interaction host to firmware and you are running linux then something like jpnevulator a serial sniffer should be useful and is part of the debs n ubuntu repositories.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> If you want to see what is happening in your
> serial interaction host to firmware and you are
> running linux then something like jpnevulator a
> serial sniffer should be useful and is part of the
> debs n ubuntu repositories.

Or socat?

---

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

Hi - I have another problem which is proving difficult for me to debug. I made the test knot in repsnapper and exported gcode - however after building the second base layer my machine freezes. I am using realterm with Xon Xoff flow control compiled into the firmware. And it seems that after sending a bunch of commands in a row it causing the machine to freeze and not respond to a command properly - and I am guessing Xon never gets sent. I have attached the compiled Gcode - I have found that If I put a delay after each line of around 300ms it seems to work ok. Any suggestions?

If you run it - be careful - I have my own custom homing code to allow me to adjust the first base height layer - so you might want to take the first few uncommented lines out....

So I get an OK - and then the machine sends an Xoff command - and never sends Xon again - causing transmission to get frozen....

After this happens - the machine is frozen - and will not respond to commands again unless I reset

Edit: Looks like it is usually freezing after exiting a Z axis move to the next layer.
Edit2: Tried this with send.py on my linux box and shortly after it gets sent the z move it will cause the firmware to freeze....

So anyone else experience this?

Edited 3 time(s). Last edit at 03/04/2011 01:10AM by kiram9.

Triffid sir.

New things. How are you proposing using socat?

I have only really used it to link up two network ports or a port and a pipe. Not as a "T" for the serial device.

So to capture the stream between say /dev/ttyUSB0 and ReplicatorG, how should I be using socat ??

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

aka47 Wrote:
-------------------------------------------------------
> New things. How are you proposing using socat?
>
> I have only really used it to link up two network
> ports or a port and a pipe. Not as a "T" for the
> serial device.
>
> So to capture the stream between say /dev/ttyUSB0
> and ReplicatorG, how should I be using socat ??

something like socat -v PTY,link=some/path /dev/ttyUSB0 plus some relevant options, then point repg at some/path should do it

Markus Amsler Wrote:
-------------------------------------------------------
> Good job, intercom-protocol looks really good.
> Moving start_send to the main loop of the extruder
> fixes all intercom-lost issues here. I'm currently
> "stress" testing intercom at a packet rate of
> 100Hz, and not one lost packet in 10mins!
> Something I never accomplished with my
> workarounds.
> Get/set temperatur heater/bed works. I've not yet
> tested the PID stuff as I'm not familiar with it.

good to hear, I'll merge soon for wider testing

kiram9 Wrote:
-------------------------------------------------------
> Hi - I have another problem which is proving
> difficult for me to debug. I made the test knot in
> repsnapper and exported gcode - however after
> building the second base layer my machine freezes.
> I am using realterm with Xon Xoff flow control
> compiled into the firmware. And it seems that
> after sending a bunch of commands in a row it
> causing the machine to freeze and not respond to a
> command properly - and I am guessing Xon never
> gets sent. I have attached the compiled Gcode - I
> have found that If I put a delay after each line
> of around 300ms it seems to work ok. Any
> suggestions?

The xon/xoff stuff is very solid by now I think, but we have occasionally seen issues with the dda occasionally getting confused and not completing moves, which stalls the queue, which in turn stops the gcode reader from accepting new commands. If you can reliably trigger this bug, please enable debug and add an M111 S6 to enable debugging of dda and position, and see whether that gleans us some more information. With those debug options, it will still freeze reading of serial data, but will continue sending information back and hopefully there will be something interesting in there for us

---

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

Ok so I ran it with debug mode on and got the following output - I am going to try and figure out what it says.

I've merged my intercom protocol work into master, those of you with intercom hardware please test

---

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

has anyone else noticed that every move adds two objects to the move queue? when did that start happening? why is it happening? where is the 2nd move coming from?

---

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

So my wierd freezing problem has been narrowed down to the following:
When DDA_step sometimes fires it will write a value of zero to the timer


R Pos: 525,2606,1565,0,200,3,0 //last two are function calling settimer and value put into settimer
R Dst: 525,2663,1565,0,2300



So while it still needs to move in the Y direction - it instead calls setTimer(0) which turns off the next interrupt.

My super awful hack is as follows. At line 595 of dda.c if we see a zero - we just set it to a big default value. However there are some other cases where the timer gets loaded with a huge value - making the machine sit there for a loooong time on a very short move stepping every second or so. Perhaps we should check at the end of dda_step() before we load the timer to make sure it is within bounds....
Hack:

        if (did_step) {
                // we stepped, reset timeout
                steptimeout = 0;

                 //if we could do anything at all, we're still running
                 //otherwise, must have finished
                //HACK: if some crappy overflow happened - fix it here by making a zero into a large number TODO:Add upper bound
                if(0 ==(dda->c >> 8)){
                        dda->c = 22117840;
                }
        }

Also in timer.c timer1_compa_isr you are blinking the debug LED - however this always happens - so if someone uses the pin for something else - they will be surprised....

Edited 4 time(s). Last edit at 03/05/2011 03:06AM by kiram9.

Which type of acceleration are you using? ACCELERATION_REPRAP? ..._RAMPING? ..._TEMPORAL? None at all?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I am using REPRAP acceleration - it seemed to be the one most suggested in the firmware comments.

Thanks.

For the choice of acceleration, use what you actually need. They differ in how the machine moves. ACCELERATION_REPRAP moves how RepRap Host and Skeinforge expect it. ..._RAMPING is suited for movements issued without or with a general G-Code generator, like CNC milling applications. No acceleration is a fallback and limits the axes speeds to what the axis can reach instantly. ... TEMPORAL is a new algorithm, intended to run even smoother, but without actual acceleration, yet.

Next step to get to the bottom of the freeze would be to find a short set of G-Code commands to reproduce the hang. Please try to cut out as many lines of G-Code as possible while still demonstrating the issue. I consider this an important one, as hanging is a really bad thing.

Another interesting bit would be to find out to what dda->c and dda->end_c is set at the time dda_start() starts the movement. If one of these is 0 there already, the culprit should be found in dda_create().

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Guys

Sorry, another trivial thing. Just compiled master for a ramps machine and noticed:-

CC gcode_parse.o
CC gcode_process.o
gcode_process.c:61: warning: ‘SpecialMoveE’ defined but not used
CC timer.o
CC temp.o

It all compiled fine and is a lower level warning so probably not serious.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

That happens if your E_STARTSTOP_STEPS is zero, don't worry about it, or wrap an #if E_STARTSTOP_STEPS > 0 around it.

---

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

Hello.
Here are some patches, cosmetic things mostly
patches.zip

I'm rejecting patch 3 because arduino IDE ignores the makefile, so 3 will break arduino ide support. Everything that the ide doesn't define (such as bootloader settings and cpu freq etc) lives in config.h. If you find something that isn't seeing the settings, this is a bug fixed by adding #include "config.h" at the top of that file.

Thanks for the other two

---

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

OK quick update.

Using ReplicatorG 24 with the Mendel Mega Ramps driver tweaked for 115200 baud.

Just fetched latest bunch of master, recompiled and programmed.

Tweaked direction for X and Y axes as they were gong the wrong way.

When they run they now run the right way.

The machine now seems to be randomly resetting and the stepper drivers are getting hot where as they didn't seem to be before.

Note I haven't got a lot of baseline to compare with yet so the above observations might not have been the changes that came down overnight.

What I am assuming is the resetting is the fact that the motors all seem to twitch (like they do at power on)

RepG Manual control, moves the correct axes in the correct direction some of the time at others the axes are confused or don't move at all.

I am incrementally testing and adjusting. So only have XYZ axes with Min Limit switches as yet connected to the Ramps board. the unused XYZ MAX Limit inputs are linked to ground so that they are not floating.

No thermistor or heater connected as yet.

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Quote

Tweaked direction for X and Y axes as they were gong the wrong way.

When they run they now run the right way.

That's why there's X_INVERT_DIR and Y_INVERT_DIR

Quote

Note I haven't got a lot of baseline to compare with yet so the above observations might not have been the changes that came down overnight.

In case you suspect recent code changes, just switch to an earlier version:

git checkout master~20

This sets you 20 commits back. If that solves the problem, try 10, then less. If the failure is still there, increase the number.

Quote

the unused XYZ MAX Limit inputs are linked to ground so that they are not floating.

To get rid of endstop handling, comment out the pin definition in config.h. Undefined pins will be ignored.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Yup already spotted the config settings this is what I had tweaked. but thanks anyway.

Setting up serial debugging using socat is turning out to be a touch tedious. See attached file for traces etc.

***** is a comment or note.

ReplicatorG 24 doesn't seem to want to see the socat generated PTY as a valid serial port for some reason. Tried ctty option as well.

Also tried pointing ReplicatorG directly at the /dev/pty/1 etc as well no joy.

The firmware responds to a reset OK though and I can see the start.ok appearing in the socat generated trace.

Has anyone had any sucess with socat and ReplicatorG ??

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

As a complete aside.

I have been wondering a couple of things.

Firstly is it perhaps worth looking into using O commands in conjunction with M98 and M99 in some way with SD cards for stored programs. Could produce some very, very useful features.

[en.wikipedia.org]

Secondly is it worth implementing some of the M commands for manipulating spare IO and or pins on devices that have some spare. Useful for those what want to experiment a little without hacking the firmware every time.

I appreciate this is pie in the sky stuff and there is enough otherwise to be going on with.

cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

Is it possible to use the Teacup firmware with Repsnapper?

I have made a custom build to suit my Gen3 Motherboard 1.1 ~ initial coms will work till the connection times out indicating.
There is a Comms protocol diffrence of some kind or my custom build is affecting the serial comms.

Is there a definition of communication protocols for the various Host Packages?

Replicator G, Reprap host, Repsnapper.

---

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]

If my reseach is correct, Teacup recently changed it's Bang-Bang from switching arbitrary I/O pins low and high to using two different PWM values. With Gen7, the older version worked fine, with the current one it doesn't. Because the heater FETs aren't on PWM pins. The later is probably subject to change, but I'd also like a working solution for Gen7 1.0.

Another reason for not using PWM is, high frequency PWM heats up the MOSFETs a lot more than switching them at 100Hz (once each clock_10ms). Even if the current going through the FET is on average the same. 100 Hz is totally sufficient for e.g. a heated bed.

So my question is: is there a specific reason why Bang-Bang is now limited to the four PWM-Pins? If not, I'd change that back to be compatible with general I/O pins. Without sacrifying PWM with PID, of course.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Probably an oversight on my part, we should of course support heaters on non-pwm pins. If you think 62.5 khz is too high, feel free to adjust the timer initialisation too.

Btw, I think it's silly to have heaters on non-pwm pins, whose idea was that?

If anyone can tell us what protocol repsnapper expects vs what we're sending, that would be really helpful

---

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

Quote

Btw, I think it's silly to have heaters on non-pwm pins, whose idea was that?

Probably the idea of someone not being aware heaters should better go to some specific pins. Nevertheless, all of the first three test boards worked fine, so the PR desaster for Gen7 introduction was inevitable.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I use repsnapper on occasion. I dropped it because I had no control over the Gcode it generated.
I did a few modifications to the line numbering and the start comands as well as m105 return. I think other then that it works ok. What issues are you having?

BodgeIt Wrote:
-------------------------------------------------------
> Is it possible to use the Teacup firmware with
> Repsnapper?
>
> I have made a custom build to suit my Gen3
> Motherboard 1.1 ~ initial coms will work till the
> connection times out indicating.
> There is a Comms protocol diffrence of some kind
> or my custom build is affecting the serial comms.
>
> Is there a definition of communication protocols
> for the various Host Packages?
>
> Replicator G, Reprap host, Repsnapper.

It should work. This is the reason the protocol standard should be followed and refined.