Connection Errors Repetier FW + Host

Printing works relatively good, except that during printing a shift in the x-coordinates occurs.
What can be the reasons for this behavior?

I already tried reducing the feedrates and accelerations but with no success.

Edited 1 time(s). Last edit at 12/18/2012 11:02AM by kugel.

If it is always in the same direction set

#define ALWAYS_CHECK_ENDSTOPS false

It could be cross-talk to your end-stop stopping x moves towards your endstop. The above setting disables checks during print - only during homing the endstops get then used.

Then you always have machanical reasions like a pulley that is not properly fixed or a belt blocking sometimes moves (I had that when it was defect on one side. From time to time I the tooth didn't fir the pulley and blocked the motor).

---

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!

Ah working! Thanks again

I have only one problem left, and its probably also related to this crosstalk: My x-Achsis does not always move to the endstop when homing - probably because my cable is too close to the motor wires or?

Yes, with bad luck you get the cross talk problem also with homing. Especially if the print now has no more shifts.

You can encapsulate the endstop cable or put them some mm apart to reduce cross talk. Also twisting the cable should help. You know like twisted pair telephone cables.

---

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!

Okay, maybe I'll switch the two cables with a coaxial one, then i should have no problems with this.
Thank you very much for your help and also for your Firmware and Hostsoftware!

I'll report back here when i get the other board running.

Hi again,

would it be possible to power on an atx-supply with one of the pins of the IO-Header if i set it in the pins.h?

Sure you can. You have to connect it to the sense cable of the atx if I remember it right. The pin must be defined like

#define PS_ON_PIN          45

then you can turn the atx on/off with

- M80 - Turn on power supply
- M81 - Turn off power supply

like gen7 does 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!

Hi again,

i just can't figure out what the problem with the electronics is, is it possible that i damaged the ftdi while soldering it to the board?
Windows does recognize it without problems though.

Any suggestions on what i could check?

Thank you very much
kugel

What is your last problem? The FTDI is for communication and from your earlier posts I read that communication works.

---

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!

Hi repetier,

I have two sanguinololu boards, and one is working flawlessly - but i can't connect to the other one. I have detached everything including the stepper drivers and power the board only through usb.
Most of the time the commands are just qeued up (the initial ones), sometimes it connects but immediately disconnects after a few seconds due to too many errors. I have interchanged the ATMEGA's from the two boards and they are not the problem.

Any suggestions?

Ok I understand and if it is not the atmega there is only the ftdi part left that could cause the error. At least if I assume that baud rate and receive cache size are set up correctly. Set cache to 63 for safety and upload the firmware with eeprom disabled to make sure the baud rate is as you expect.

So from your description it works in general but something introduces instabilities that causes many checksum error which will break the communication at some point. This happens with wrong cache size and hardware problems. After switching the atmega you had the working firmware on the problem board with problems so I think it is hardware.

---

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!

If i try to upload a firmware via arduino, after a few seconds it stops with the following errors:

avrdude: Recv: . [14] 
avrdude: Recv: . [82] . [81] . [93] . [81] . [0e] . [94] $ [24] C [43] . [a8] . [01] . [97] . [01] . [0e] . [94] - [2d] D [44] . [0e] . [94] . [f6] B [42] . [f6] . [01] ` [60] . [83] q [71] . [83] . [82] . [83] . [93] . [83] $ [24] . [96] . [c0] 1 [31] . [d1] . [05] . [09] . [f0] . [ad] . [cf] . [df] . [91] . [cf] . [91] . [1f] . [91] . [0f] . [91] . [ff] . [90] . [ef] . [90] . [df] . [90] . [cf] . [90] . [08] . [95] O [4f] . [92] _ [5f] . [92] . [af] . [92] . [bf] . [92] . [cf] . [92] . [df] . [92] . [ef] . [92] . [ff] . [b5] . [83] . [ed] . [85] . [85] . [83] . [ff] . [83] . [ff] . [b5] . [15] . [ff] . [15] . [ff] . [83] . [ff] . [15] . [ff] . [ff] . [f3] . [a5] . [97] 5 [35] 7 [37] . [07] . [f8] . [c1] . [fd] . [ff] . [c8] . [c2] . [00] . [ff] . [e8] . [15] . [e6] . [8f] . [ff] . [b5] . [83] . [ff] . [83] . [ff] . [15] . [ff] . [83] . [ff] . [83] . [ff] . [15] . [ff] 
avrdude: Recv: 

avrdude: stk500_paged_load(): (a) protocol error, expect=0x10, resp=0x14
avrdude: Send: V [56]   [20] . [00] . [00] . [00]   [20] 
avrdude: Recv: 
avrdude: stk500_cmd(): programmer is out of sync

I Lifted all legs of the FTDI which are not connected to anything according to the schematics on reprap.org. Is it possible that the FTDI is damaged, although windows recognizes it without problems?

The FTDI has 2 parts. The usb part which is connected with windows and which windows sees. Then there are the to pings RX/TX connected with the AVR. I guess it is possible that the usb part works and the RX/TX part have a problem like bad connection or what ever causing your problems. Would at least fit into your problems.

---

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!

Now i soldered cables between the rx/tx pins and the atmega, still no success.

Seems like this board is not going to work

Is it possible that only the serial part of the FTDI is broken?

Edited 1 time(s). Last edit at 01/12/2013 01:26PM by kugel.

Hi again,

i got a avr programmer and flashed the gen7 bootloader onto my atmega and switched the resonator with a crystal and 2 capacitors. I am only able to upload firmware to the atmega using the programmer so far, but i am able to connect to that firmware with NO communication errors.
But: the steppers are moving very slowly - is it possible that this happens because of one stepper driver missing (it's defect and i am waiting to get a replacement).

Or what could else be the problem?

Thanks again

The firmware doesn't see if a stepper works or not. It just toggles the pins and hopes there is a driver magnifying the signals.

One reason might be wrong fuses. All AVR have a internal clock with 1 or 4MHz, don't know exactly. If that is used instead of the external clock everything would be slow as it counts signals and they are less frequent then expected.

---

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!

Hi,

thank you for your reply. The fuses don't seem to be the problem, I have checked them again and again now and still the same. I tried the fuses which are in the boards.txt from the Gen7 support package - they are the same for atmega644 and atmega644P - i have a atmega 644A so they should also work. According to the datasheet they all share the same fuse settings.
Is it possible that i need another bootloader for the atmega644A ?

I have contacted my supplier but they have not answered my inquiry so far.

Th ebootloader is responsible for firmware uploads over usb. They have nothing to do with the software running later on the avr. Infact if you have a programmer oyu can do completely without a bootloader and spare the 4kb.

When you said the steppers are slow, how slow did you mean? 12.5% of the target speed, 50%. Could it be a config setting beeing wrong e.g. limit max speed to a very slow value? Check the eeprom settings for this - they have priority to confg settings!

---

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!

Slow as 12.5% maybe. But now i seem to have bricked my ATMEGA, i get "initialization failed" and have tried some solutions i found around the ineternet but none worked so far.
And I am wondering why i was not able to upload the firmware through usb anymore.

When i get to some state where i can upload firmware again I'll post here again.

Hello again,

i got an Atmega1284p so that i can print from SD card now and the problem with the slow motors was really a firmware setting!
Got it all working again, just need a new Pololu and then i can finally print again

Thank you for your support!