Firmware Issues Motherboard v1.2

I started ontop of another thread so I move the important stuff over here. Original thread: Here

Ok curiosity got the best of me and I went back to look at the generic firmware again with a fresh mind. The code is indeed running, all be it not very well. When I use the serial monitor I see the following message stastststststststststststst ect. I changed up the start message to make sure and sure enough I got 123121212121212121212 in a never ending stream.

Does anyone have any ideas? I'm going to keep playing with this, but if someone has input its definitely welcome.

Edited 1 time(s). Last edit at 05/21/2011 08:25PM by Adam.m.Nelson.

F&% Ya! Found it!

Turns out the RS485_BUF_LEN was set to 20 which is too small?

Note: In the comments in intercom.h it says this setting is in the configuration.h file, but its really in the intercom.h file line 71.

I doubled its value from 20 to 40 and have atleast stable communication, Looks like it needs tweaking, but its a start. The debug LED has also started blinking again.

I got the file from the repository like this, are other people having this issue?

ok, so I can communicate, I've tested all the inputs, and can move all the axis (including the extruder). However my Mendel still loves to crash.

Regarding the RS485_BUF_LEN I found the following:

The Original value was 20. Tested Values that give me a debug led 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 60, 63
Failing values 36 and lower, 64 and higher.
Settings that communicate (not all inclusive) 40, 50, 55

Now I have a reset problem with the robot. Using the serial monitor I have been testing the latest issue, I can retrieve information GCode M114, turn on, modify, or monitor the heater and temperatures with out an issue. However if I try to move the robot I get continual errors, in a pattern. For example I can send a code to move an axis, Blue is what I send, Red are responses:

G0 X000 Y10 Z000 E000 F000
ok
G0 X000 Y20 Z000 E000 F000
ok
G0 X000 Y30 Z000 E000 F000
start

This pattern never fails. I did some code testing and commented out the setFatal() conditions one at a time to see what was causing the issue, and it kept happening, same pattern, all the time, leading me to believe its something else doing the resetting. I should note this will happen with X Y Z or E movements in that pattern. My next step I suppose is to add code to set a flag for each kind of Fatal to see if it is indeed that resetting the robot.

While writing this I realised the buffer I changed is probably only used in the comms with the extruder board, as I don't think the rest is RS485, maybe the problems there, more testing to follow.

Also while writing this I got my first restart while pulling info from the Mendel, it crashed while transmitting me data. The serial monitor output is below:

start
G0 X000 Y10 Z000 E000 F000
ok
G0 X000 Y20 Z000 E000 F000
ok
M114
ok C: X:0.start
M114
ok C: X:0.00 Y:0.00 Z:0.00 E:0.00
M114
ok C: X:0.00 Y:0.00 Z:0.00 E:0.00

My question to the people who maintain the code for Mendel:

Has the latest release been tested on Gen3 electronics? Is anyone else having issues like this? These seem like more then just calibration/ configuration issues we are having here.

I know by now no-one is probably listening, but its a good place to keep my thoughts together worst case scenario.

Any thoughts are welcome!

Edited 1 time(s). Last edit at 05/21/2011 08:28PM by Adam.m.Nelson.

What version of the 5D firmware are you trying to run? I don't know of anyone who has been able to run the latest 2011 firmware on Gen 3 electronics with separate extruder controller through RS485. I've been able to fix compile errors but it doesn't run when loaded to the electronics. Unfortunately, no one from the development team seems to be reading this forum.

Why are you sending g-codes to move the head with a feed rate of 0 (F000)?

According to the firmware its version "1.8", from the 20110509 build.

#define REVISION "1.8" // arbitrary, based on comets in top of main file...
// definitions for M115 machine capabilities command, see [reprap.org]
#define xstr(s) str(s)
#define str(s) #s
#define PROTOCOL_VERSION "0.1" // Make sure you really are compliant with what you advertize here
#define FIRMWARE_NAME "FiveD" // Please change this name if you fork the codebase
#define FIRMWARE_URL "http%3A//reprap.org" // Escape any colons as %3A
#define MACHINE_TYPE "Mendel" // Set to whatever bot you have, could be Darwin, Huxley, or Custom, etc.
#define FIRMWARE_VERSION "20101023" // Need to autoupdate this from svn or git. FIXME.

It sounds like you are having the same issue I am. I did more testing last night and found some more interesting notes. If I am using "ENABLE_PIN_STATE_INVERTING" in the config file I had to change the RS485_BUF_LEN to between 40 and 55, I am currently using 50. If I use "ENABLE_PIN_STATE_NORMAL" I can use the RS485_BEF_LEN of 20 or lower and it will run. I've tested the end stops using the test code, and they work fine, so it's got to be a code thing. Not to mention wieh the boards were running the original firmware they came with it worked fine.

My plan for today is to start testing older releases I guess. This one doesn't seem to be compatible.

Are you using the Gen3 electronics brnrd?

As for the GCode I am just sending codes to see if it crashes which it does. I'm pretty sure that it will use the default feed rate is you don't specify one.

I really wish there was an in circuit debugger on this, it would make finding the issue much easier. I may have to look into buying one.

Edited 3 time(s). Last edit at 05/24/2011 11:58AM by Adam.m.Nelson.

I went back and tried the v102 build for Gen3 electronics same thing.

brnrd,

Take a look here, this guy shared his working code, it'll just need to be tweaked for your application.
Forum Link