ryan_prof Wrote:
-------------------------------------------------------

> The problem I have with the pause button is that
> it's not accurate enough.
> I need it to complete the current layer it is
> printing before pausing and not right away (or
> really after buffer is empty I think,dont really
> know how that works)
> If I dont time it correctly it starts printing the
> next layer already and its to late.

I didn't speak of the Pause button. You can add a
@pause
line in the G-Code. The host will only send commands until that position, so you get absolute exact timings.
Only after hitting the button, the host continues sending commands.


>
> QUESTION: Doesn't the firmware stop the steppers
> automatically(also after pause)? Meaning a race
> against the timeout-clock for changing the
> filament.

You can set the timeout to 0 so they never stop on their own in the firmware (Default is 2 minutes which may be too short). Just add a M84 (I think it is) at the end of your print.
>
> But like I said it's just a nice-to-have I am in
> no way dissatisfied with your software and how it
> all works.
> Since I started using it I had no more bad prints.
> So I'm sticking with it. I just want more
> (hehe)...

More will come like improved temperature monitor, external g-code filter, ...

BTW: For questions or suggestion to repetier related products, I have now my own sub-forum (home->repetier) which is better visited from Repetier users then this thread.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hello there again,

Thanks again for the last time, That was efficient.

I still have some freeze bug.
I'm using a gen7 + Ubuntu + Repetier Host
And the chip seems to freeze randomly, It could be a interference problem (shutdown making signal noises, reseting or freezing).

I thougth it was the baudrate first so I changed it to 19200 but it's still the same.

EDIT: I do have this message in my terminal:

System.ArgumentOutOfRangeException: ArgRange_Array
Parameter name: count
  at System.Text.ASCIIEncoding.GetCharCount (System.Byte[] bytes, Int32 index, Int32 count) [0x00000] in :0 
  at System.Text.Encoding.GetChars (System.Byte[] bytes, Int32 index, Int32 count) [0x00000] in :0 
  at System.IO.Ports.SerialPort.ReadExisting () [0x00000] in :0 
  at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPort:ReadExisting ()
  at RepetierHost.model.PrinterConnection.ReadThread () [0x00000] in :0

So it is the host, Anyway the firmware continue to stabilize the temperature, and the FTDI works fine after that with the arduino frameworks...

Somebody could have the same problem (and a solution of course?) or have an idea?

Greetings,

Edited 2 time(s). Last edit at 02/11/2012 06:59PM by Ghunt.

Thanks for updating your post. The message really helped me finding the position. The main problem is, that it happens not in the host code but inside the read function for the serial console. So this an error of the Mono library used by the Host. For the next release I've added a try-catch-clause around this code, so it should try again, which hopefully works. I think it may be unclean written and have problems with threads, so it should work.

I have uploaded the fix on github. Download
https://github.com/repetier/Repetier-Host/raw/master/src/RepetierHost/bin/Release/RepetierHost.exe

and replace the file in your installation with the new one.

Hope this fixes the problem, so let me know.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Well, I'm try that now. You will have your feedback to confirm your fix.

I found a minor bug in the firmware: if you try to home one of the axis before enabling the power supply, the firmware freeze.

EDIT:
[...] Some time later ...

Yeah, I had the same message in the terminal, BUT hopefully, it seems to continue printing!
Fantastic!


Thanks again,

Greetings,

Edited 1 time(s). Last edit at 02/12/2012 05:22AM by Ghunt.

I'm not sure if this counts as error. Without power you can't move or heat. But the freeze is unexpected, as the processor should be running already. So I expected that it executes but has no visible effect. On the other hand, I don't exactly know how this suspend mode works. Might be a side effect. I will look at this when I have a board with switchable power:-)

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Ok, I see.

Anyway, no freeze since your update, it works fine now.

Thanks another time,

Cheers,

Hi. I didn't have trouble in the past but recently I am having so many communications problems that the print eventually stops. It resends commands all the time. Not sure what I should try. I tried diff baud rates, new USB cable, diff USB port on the PC ... RAMPS1.4, Ubuntu 10.04, Repetier Host and Repetier firmware, Repetier Protocol, any ideas? It is great firmware and software BTW :-) so thanks!

18:22:23.726 : Resend: N496 G1 X69.65 Y103.65 F6000 *95
18:22:23.728 : Resend: N497 G1 X65.35 Y103.65 E7.16746 F1800 *22
18:22:23.729 : Resend: N498 G1 X65.35 Y66.35 E7.69605 *79
18:22:23.735 : N499 G1 X104.65 Y66.35 E8.25299 *123
18:22:23.744 : N500 G1 X104.65 Y70.65 E8.31392 *119
18:22:23.767 : N501 G1 X69.65 Y70.65 E8.80992 *76
18:22:23.791 : N502 G1 X69.65 Y103.545 E9.27609 *76
18:22:23.943 : Error:Binary cmd wrong checksum.
18:22:23.943 : Resend:497
18:22:23.944 : Resend: N497 G1 X65.35 Y103.65 E7.16746 F1800 *22
18:22:23.947 : Resend: N498 G1 X65.35 Y66.35 E7.69605 *79
18:22:23.949 : Resend: N499 G1 X104.65 Y66.35 E8.25299 *123
18:22:23.950 : Resend: N500 G1 X104.65 Y70.65 E8.31392 *119
18:22:23.952 : Resend: N501 G1 X69.65 Y70.65 E8.80992 *76
18:22:23.954 : Resend: N502 G1 X69.65 Y103.545 E9.27609 *76
18:22:23.958 : N503 G1 E6.27609 F1500 *43
18:22:23.998 : N504 G1 Z0.95 F6000 *1
18:22:23.998 : N505 G92 E0 *103
18:22:24.051 : N506 G1 X67.502 Y101.878 *59
18:22:24.199 : N507 G1 Z0.45 *111
18:22:24.200 : N508 G1 E3 F1500 *49
18:22:24.255 : Error:Binary cmd wrong checksum.
18:22:24.255 : Resend:501
18:22:24.256 : Resend: N501 G1 X69.65 Y70.65 E8.80992 *76
18:22:24.258 : Resend: N502 G1 X69.65 Y103.545 E9.27609 *76
18:22:24.260 : Resend: N503 G1 E6.27609 F1500 *43
18:22:24.261 : Resend: N504 G1 Z0.95 F6000 *1
18:22:24.263 : Resend: N505 G92 E0 *103
18:22:24.264 : Resend: N506 G1 X67.502 Y101.878 *59
18:22:24.265 : Resend: N507 G1 Z0.45 *111
18:22:24.266 : Resend: N508 G1 E3 F1500 *49
18:22:25.409 : N509 G1 X67.502 Y68.122 E3.48168 F1800 *40
18:22:26.234 : N510 M105 *3
18:22:26.624 : N511 G1 X68.188 Y68.122 E3.49147 *75
18:22:26.676 : N512 G1 X68.188 Y68.878 E3.50226 *66
18:22:28.937 : Error:Binary cmd wrong checksum.
18:22:28.938 : Resend:506
18:22:28.938 : Resend: N506 G1 X67.502 Y101.878 *59
18:22:28.939 : Resend: N507 G1 Z0.45 *111
18:22:28.942 : Resend: N508 G1 E3 F1500 *49
18:22:28.943 : Resend: N509 G1 X67.502 Y68.122 E3.48168 F1800 *40
18:22:28.944 : Resend: N510 M105 *3
18:22:28.946 : Resend: N511 G1 X68.188 Y68.122 E3.49147 *75
18:22:28.947 : Resend: N512 G1 X68.188 Y68.878 E3.50226 *66
18:22:28.951 : Error: expected line 506 got 507
18:22:28.951 : Resend:506
18:22:28.952 : Resend: N506 G1 X67.502 Y101.878 *59
18:22:28.954 : Resend: N507 G1 Z0.45 *111
18:22:28.955 : Resend: N508 G1 E3 F1500 *49
18:22:28.956 : Resend: N509 G1 X67.502 Y68.122 E3.48168 F1800 *40
18:22:28.958 : Resend: N510 M105 *3
18:22:28.960 : Resend: N511 G1 X68.188 Y68.122 E3.49147 *75
18:22:28.961 : Resend: N512 G1 X68.188 Y68.878 E3.50226 *66
18:22:28.964 : N513 G1 X68.874 Y68.878 E3.51206 *74
18:22:28.968 : N514 G1 X68.874 Y68.122 E3.52285 *67
18:22:29.059 : N515 G1 X69.56 Y68.122 E3.53264 *117
18:22:29.235 : N516 M105 *5
18:22:31.519 : N517 G1 X69.56 Y68.878 E3.54344 *117
18:22:31.524 : Error:Binary cmd wrong checksum.
18:22:31.528 : Resend:512
18:22:31.529 : Resend: N512 G1 X68.188 Y68.878 E3.50226 *66
18:22:31.531 : Resend: N513 G1 X68.874 Y68.878 E3.51206 *74
18:22:31.532 : Resend: N514 G1 X68.874 Y68.122 E3.52285 *67
18:22:31.534 : Resend: N515 G1 X69.56 Y68.122 E3.53264 *117
18:22:31.536 : Resend: N516 M105 *5

Edited 1 time(s). Last edit at 02/12/2012 06:30PM by structr.

@structr

Looks like you upgraded your Arduino to version 1.0. In version 1.0 the receive buffer was reduced for Mega boards from 128 to 64 bytes. In Repetier-Host go to printer settings and reduce receive buffer length to 63 byte, that should do the trick.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Awesome!! That did the trick. Beautiful prints once again :-) 1k lines and zero errors ... yay! Thanks again Repetier. With this firmware, Slic3r, and the host .... it's got to be (IMO) the easiest, most intuitive, and smooth printing tool-chain. Can't thank you enough.

Edited 1 time(s). Last edit at 02/13/2012 07:53AM by structr.

Hello Repetier,

I came back

I'm running your host without any problems with Slic3r.

But I would like to try Skeinforge (the last one), so I'm currently trying to configure it.
The calibration is ok because Slic3r is working pretty fine.
I've got a extraordinary big amont of plastic coming out of the nozzle with Skeinforge.
(When I use your interface, I extrude in the software 100mm, it's really extrusing 100mm of feedstock)

So the question is: do you have a working skeinforge configuration in backup?

So if you have any solution or idea...
If it's just a bad tuning, I would be glad if you have any nice tutorial for skeinforge noobs.


Another minor detail:
Solidworks STL exports doesnt work in your framework, because of the decimal format from Solidworks, so I did a python script
You think it could it be take into account in the next version??
Thanks again!

Edited 5 time(s). Last edit at 02/17/2012 10:48AM by Ghunt.

Ghunt Wrote:
-------------------------------------------------------
> I'm running your host without any problems with
> Slic3r.
Thats what everybody likes on Slic3r:-)

> But I would like to try Skeinforge (the last one),
> so I'm currently trying to configure it.
> The calibration is ok because Slic3r is working
> pretty fine.

Yes, thats the same.

> I've got a extraordinary big amont of plastic
> coming out of the nozzle with Skeinforge.
> (When I use your interface, I extrude in the
> software 100mm, and it's really extrusing 100mm of
> feedstock)

Which means ideally calibrated, good so far.

> So the question is: do you have a working
> skeinforge configuration in backup?

I attached my .skeinforge settings folder. It's for 3mm filament, 0.5 mm nozzle and PLA. I always set the temp before running the job.

> (The Gcode out some E120 which is much bigger than
> Slic3r)
>
> So if you have any solution...
> If it's just a bad tuning, I would be glad if you
> have any nice tutorial for skeinforge noobs.

With my settings it should match more or less. Some tweaking to match your filament type. You can search the forum for skeinforge configuration and you will get much informations, more then I know about it.

>
> Another minor detail:
> Solidworks STL exports doesnt work in your
> framework, because of the decimal format from
> Solidworks, so I did a python script
> You think it could it be take into account in the
> next version??

If you send me the stl file not working i can have a look at it and try to make it work. I have no solidworks, so I also have to stl examples to test. Depends on what the problem is. Have already seen binary outputs that start like ascii output should do. So not everyone does it like the specs define it.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

repetier Wrote:



> With my settings it should match more or less.
> Some tweaking to match your filament type. You can
> search the forum for skeinforge configuration and
> you will get much informations, more then I know
> about it.

I'll try that


> If you send me the stl file not working i can have
> a look at it and try to make it work. I have no
> solidworks, so I also have to stl examples to
> test. Depends on what the problem is. Have
> already seen binary outputs that start like ascii
> output should do. So not everyone does it like the
> specs define it.

Ok, nice, I attach you 2 files:
-The solidwork version of STL
-a dirty homemade python script translator that I use


A weird thing is, when I am printing those STL, sometime it get freeze 1seconds while printing and it happen that the print translate a bit (on Y or X on the next layers...which is not really nice..) ... I dont know if it is sli3r or my printer but it seems to happen with solidworks files+slic3r...
(perhaps my script is wrong...)

Anyway, thanks for anwering,

Edited 2 time(s). Last edit at 02/17/2012 11:15AM by Ghunt.

I just tested you STL file and it worked perfectly. The only thing is, if you load it with the G-Button it is not recognized as STL because the suffix is in uppercase. I will add an ignore case for the next update. If you use the "Add STL file" button in object placement it loads, because here the suffix doesn't matter.

Regarding your short freezes it's not the slicer, but perhaps the speed. If you get a translation to the preview in the host, the printer didn't keep track of all steps. So I guess in that second the controller tried to execute some steps, but the motors didn't follow. Maybe your populus got too hot? Or did you hear some sounds like loosing steps?

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

You skeinforge file is just great!!

It work perfectly without touching to anything...

EDIT: I didn't see your post:

>Regarding your short freezes it's not the slicer, but perhaps the speed. If you get a translation to the preview in the host, the printer didn't keep >track of all steps. So I guess in that second the controller tried to execute some steps, but the motors didn't follow.
>Maybe your populus got too hot?
No I don't think so, I saw that it was maximum 50°C
>Or did you hear some sounds like loosing steps?
Difficult to say so.

I'm affrait that it is the Slicer Slic3r, I do not have those problems on Skeinforge...

Anyway, skeinforge seems to be much better than Slic3r... That's a good news...

Thank you a lot another time!!

Edited 1 time(s). Last edit at 02/17/2012 01:16PM by Ghunt.

I continue here the Edit (cf up)

>I just tested you STL file and it worked perfectly.
Yes indeed
>The only thing is, if you load it with the G-Button it is not recognized as STL because the suffix is in uppercase. I will add an ignore case for the >next update.

Good news!

>If you use the "Add STL file" button in object placement it loads, because here the suffix doesn't matter.

No, I was not so clear, the visualization problem is something, but the main problem was Slic3r which doesn't take into account the decimal problem of the STL parts (perhaps I'm wrong, but it does not work here). So I thought you could wrap and translate the STL for Slic3r until they tix themselft the problem.

Well, it is not a big deal... It seems to work directly with Skeinforge...

Greetings,

If you load the STL inside object composer and then hit "slice and load", the stl is always rewritten by the host into a binary format, regardless of what it was before. If you use the G-Button and select a stl file and say slice it, it is send without rewriting to the slicer.

I tested your file with rewriting in the host and it worked with slic3r.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hello, I try to put repetier firmware on a gen7 v1.3.1, and all is working except the temperature readings, it stay at 357°, the led of the heater loght up, but nothing, is there something I miss ?

@pomalin

your configuration is wrong.

#define EXT0_TEMPSENSOR_PIN 0

I'm quite sure you set your sensor pin here. Thats wrong. You are not allowed to change this value, this is not pin numbers. The pin for your extruder sensor is defined in the extruder section:

Put all the pin numbers for the analog sensors (temp. sensor for extruder and heated bed) in here.
In the configs of the sensor, use the index in this array. For the typical combination of
one extruder with heated bed, write:
#define  ANALOG_INPUT_CHANNELS {TEMP_0_PIN,TEMP_1_PIN}
*/
#if HAVE_HEATED_BED==true
#define  ANALOG_INPUT_CHANNELS {TEMP_0_PIN,TEMP_1_PIN}
#else
#define ANALOG_INPUT_CHANNELS {TEMP_0_PIN}
#endif

Here you can set the ANALOG pin numbers, not the digital one. These are taken from pins.h and are normally correct for gen7. Analog values go from 0-7 for a0-a7.

If this wasnt the error, you selected a wrong thermistor table, but I'm quite sure the others with the same error had extactly this done wrong.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Ok, you were right, it was that :

#define EXT0_TEMPSENSOR_PIN 0

I had put a 1 instead of the 0, now all is all right, and work really well, just a question what configuration I have to change to have some more smooth movements ? I found that it's a little violent, my prusa dance like an epileptic when doing some small moves, I have reduce the jerk, and the feedrate, but it's not that smooth, is there a way ?

Hi,

you probably have eeprom enabled. In that case you have to change the eeprom settings for jerk and max. feedrate. Changing the eeprom settings is easy with Repetier-Host. Just use the eeprom menu after connecting.

In your list you forgot acceleration. The default is 3000mm/s². Max feedrate is not important for your problem. It's only jerk and acceleration making your printer dance. If you can, keep the high jerk values. They give better print results.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hello Repetier,

Speaking about Jerk and acceleration,
I saw the jerk exemples on Gitub, which are understandable,
nevertheless, I'm not really sure about how to proceed to tune my Huxley with Jerk and acceleration.

I did some small tunings, and I put 20 in jerk and 20 in acceleration on X and Y. (max speed:750mm/s)
But I still want to accelerate my printing, and I saw that if I set the max speed to more than 750mm/s it just steps.
It sometimes too quick in small segments and too slow and low ones. (I could slow the acceleration, but perhaps you have better to expose).

Would you have some advises, tips and tricks to tune the beast?

Thanks a lot for this community work!

Greetings,

Edited 1 time(s). Last edit at 02/24/2012 07:30PM by Ghunt.

A Jerk of 20mm/s is quite normal value. The weight of the printed bed and extruder prevents much higher values.
Not sure if you mixed speed and acceleration.
Speed 750mm/s is ver very fast. Even the fast ultimachine stops around 350mm/s. My Mendel has a limit around 150mm/s.
Acceleration 20mm/s^2 onthe other hand is ver slow. Mine is 3000 but can also print with 7000,

For 0.5mm/3mm prints good print speeds are 60mm/s. For the first layer and outer perimeter 30-40 are better, so you get more details. You can try higher values for the infill, but the higher you go, the worse your result will be.
For travel speed, I would take values 100-150 mm/s. Depends on what you printer can handle.

If you get lost steps with acceleration < 2000 mm/s^2 you might have some unoptimized hardware setup. Possible reasons:
- No high torque steppers
- Not enough current set. Higher current gives more torque. But watch the limits of the motor and your driver!
- If you slip of the belts, you must be able to move the bed and extruder with nearly no resistance. If you get resistance your rods are not parallel, not greased well or your lm8uu too small.
- Your stepper driver get too hot (heat sink, fan)
- ... no idea what I forgot

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hello,

repetier Wrote:
-------------------------------------------------------
> A Jerk of 20mm/s is quite normal value. The weight
> of the printed bed and extruder prevents much
> higher values.
> Not sure if you mixed speed and acceleration.
Yes I'm sure I didn't mixed
I show you:

> Speed 750mm/s is ver very fast.
I know, I do have a bowden extruder, so a very light X carriage and I tried to make have the ligthest Y carriage too.
But I usualy slow down to 350 or 500 to make small pieces, to get better results..

> For 0.5mm/3mm prints good print speeds are 60mm/s.
> For the first layer and outer perimeter 30-40 are
> better, so you get more details. You can try
> higher values for the infill, but the higher you
> go, the worse your result will be.
> For travel speed, I would take values 100-150
> mm/s. Depends on what you printer can handle.

Ok, 'will see that

> If you get lost steps with acceleration < 2000
> mm/s^2 you might have some unoptimized hardware
> setup.
I'm trying as you see on the picture...

Possible reasons:
> - No high torque steppers
Yes, I do have some low torque NEMA 14 (not NEMA certified)

> - Not enough current set. Higher current gives
> more torque. But watch the limits of the motor and
> your driver!
Nope, it's not a current limit

> - If you slip of the belts, you must be able to
> move the bed and extruder with nearly no
> resistance. If you get resistance your rods are
> not parallel, not greased well or your lm8uu too
> small.
It could, I had some issues before, but not anymore if I see my printings.
> - Your stepper driver get too hot (heat sink,
> fan)
Nope
> - ... no idea what I forgot


Perhaps, something is wrong, I never saw another printer working. So it could not be so fast. You can check yourself on blur video. I'm printing some home made gears. I will show you the result if you want.
Sorry I do not have camera except on my phone

Any feedback is good to take

Thanks

Edited 3 time(s). Last edit at 02/25/2012 06:30AM by Ghunt.

ok, if you really tried 750 mm/s then there is another possible reason.

If you have 1/16 Steps you'll need 80 Steps/mm (may differ in your case).
750mm/s *80 Steps/mm = 60000 Steps/second.

With 16MHz this is one step every 266 clock cycles.

What I'm saying is, your board is not fast enough for that speed. In these 266 cycles the board needs also to update new moves, check temperatures etc. Not sure where the limit is, but I'm quite sure it is less then 60kHz. It also depends on what you print. With large moves you can go higher then with multiple short moves.

Only for comparison: A float division takes > 600 Ticks, the optimized version in the stepper routine is down to about 70 Ticks.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Interesting...
I did'nt think that way...

For information:
I'm using a 20Mhz gen7 1.3.1
And my motors are 400Step/cycle (0.9°). I'm using a 1/8 uStepping
As you say on the picture I've got 64step/mm in Y
EDIT: Sorry, I didn't remember the 80
so if I use a 600mm/s speed => 600*80 = 48000 steps/seconds

If I follow your idea:
Admiting our limit is 50Khz, I can manage ~600mm/s for big things
Interesting...I thought limits was just mechanicals in the reprap case, but you'r right uC are not so powerfulls.

Result of the last prints
I checked my 750mm/s, its not really good (but no step lost)
But, I decreased the speed to 400mm/s which is much better for the gears but for big pieces I already used the 750mm/s prints and it worked quite fine.

The thing is, it can take really long to print some big pieces. I just have to accept it

A little picture:

All gear have been printed with 350 or 400mm/s (I dont remember)
The big holding part with 600mm/s speed.

All thanks to your nice work :p !

Edited 3 time(s). Last edit at 02/25/2012 09:52AM by Ghunt.

750 mm/s on a TZ Huxley ! I never been able to go over 100mm/s - but then I tend to reduce the current given to the motors, to avoid the motors mount to creep (they are PLA).

Also I still have the original Monotronics that only can do half stepping.

I start seeing shifted layers if I use anything above 80 mm/s for non printing moves.
I usually do not go over 50 mm/s for printing moves or it will start reducing the output print quality a lot.

You did a good job hacking that Huxley Ghunt.

(Sorry for the slightly out of topicness).

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

Hello,

I am trying to get this firmware (v 0.45) on my Gen7 1.3.1 electronic ([email protected]) but without any success. I am using Gen7 644 20MHz bootloader. OS is WServer2008R2 x64, Arduino IDE 1.0.
Gen7 Setuptest and my own custom test sketches works without any problem.
I have followed instructions to install, move all included files etc.

At beginning I had problem to upload firmware - getting stk get sync issue - But I resolved it by changing upload.protocol=arduino which does not work, to stk500v2. The uploading is not a problem then.

Now - it still keeps resetting MCU on Brown out Reset (even if I disable it by setting 0xFF in extended fuses). Power source is stable (5.03-5.07) without peaks. So I think that there have to be some other problem. But I am unable to find out what could cause this.
At first I thought it could cause my changes in cinfiguration. So, I tried to revert all changes I made in config, and kept only Gen7 board selected. For a pity it did not help, and I have still same issue. I am completely out of ideas how to fix it or what causes it.
Do you have any ideas what could cause this?

Thank you.

@Bigbaz Brown out without doing anything is really strange.

Did you have it working with another firmware or is it the first?
How often do you get the reset and how far do you come. I assume you could read the brown out reset message. Did you also see start message?
If it is the first firmware, did you try unplugging motors/endstops/stepper driver/extruder. Perhaps something of these is wired incorrect and causes a sudden drop during initialization.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hello repetier,
thank you for your fast response. It is first firmware I try to use.

I've tried to unplug everything. Just left only core board with no sensors or motors connected.
This is what I get from console after powering board up :
start
PowerUp
External Reset
Brown out Reset
start
Brown out Reset

I hope all pins are set correctly because I used pin configuration in my own sketch and everything worked.

Strange behaviour. You should add some debug messages along the setup process, so you can find the spot that causes the reset. Add

out.println_P(PSTR("Pnt 1"));delay(500);

add several messages inside setup() after the reset messages. Change the output text to not get confused. The delay is to give time for output, otherwise it may be in the buffer but never be seen, because of the reset. Also add a info inside loop() to check if it gets that far. All methods are found in Repetier.pde line 367-...

WIthin a few tries you should be able to locate the function causing the reset. Then you can analyze that function the same way.

My guess is that some output change causes your reset, perhaps a solder bridge on your board? At the start all pins are high impedance input pins, so everything works. Changing the pin to output may have that effect, so you need to find the pin making trouble by scanning board or software debugging.

If you think you have the code making trouble I may say more.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!