Geeetech

Hi,

yesterday, I've completed assembly instructions and started using the printer.

3 problems emerged:

1st: the x axis is slanted and whenever I try to set it straight, the right z motor grinds a little and then operates normally but with a slanted x axis; I found a few pointers in the FAQ that I want to follow up so this problem should be of no concern here

2nd: the LCD screen goes off at times - that is, it is still lit but doesn't show any information anymore (this seems to happen mostly, but not exclusively, in the main menu at the top trying to go up); this is not a bit deal as it can be fixed with a reset, but is it normal?

3rd and potentially most problematic: I tried to connect with the software to the board at the default 250000 baud; when that didn't work, I tried 115200, couldn't get it to work again; only when I changed the firmware to 57600 did I get it to work.

Is that a problem? Will this comparatively low baud rate hamper performance or will even make printing impossible because of the cooling down of the filament?

Or is 57600 baud enough?

Does anyone else have this problem on linux? Or even a hint what I could do to get the rate up to 250000?

1.The Z AXIS problem
You need to check the FAQ of the printer,find the section for the Z axis
viewtopic.php?f=109&t=61933
2.The LCD
I think you need to check the wires insert correct or not
3.The baud rate.
The baud rate for your printer :It means when you open the software of slic3r,cura...etc.You need to set the baud rate to 250000.
For the"USB serial COM port", the default of it is Ok

@William: Thanks for your quick reply.

Re baud rate:
I would love to use the default.
But setting the software (I used the recommended Repetier-Host) to 250000 baud only produced garbage responses. As a result, the software wasn't able to command the control board.
Then I read somewhere on some forum that some operating systems don't cope well with non-standard baud rates.
I should maybe mention that I'm using Linux.
I downloaded the firmware for the board and the Arduino 1.0 SW and recompiled with 115200 baud rate. The Arduino IDE has a serial console, so after recompiling and uploading the firmware I tried the serial console with 115200 baud. Still only garbage.
Only when I recompiled the firmware with 57600 baud rate did I get meaningful output on the serial console.
Consequently, the Repetier-Host worked at that baud rate as well.

But my question is: Now that the SW works, can I leave it at that baud rate or will it make the printer really slow or, worst case, will it make the printer unusable as it is so slow that the filament cools down too quickly before more commands are sent. In other words, do I need the high baud rate?

Re reset:
How could the wires be wrong?
Most of the time, it shows meaningful information and the wheel/button works. It just goes off sometimes...

Hello.


Linux is not a problem, and is not a source of communication errors.

I see in your description one common symptom - disruption of communication.
This concerns communication to the LCD module and to the computer via USB cable.

Try to improve the cable routes.
Also show photos of how you assembled your printer and how you arranged all the cables.

@_kaktus_: Here are pictures of the display board



and the processing board



The USB is not plugged in in the picture.

I'm not sure these will be any help as I don't know what to focus on specifically.

How can cable routes be improved?

Hi.


Signal cables should not be laid along cables with high current. And in their immediate vicinity.
In other words, try to route the cables to the LCD module as far as possible from the cables for stepper motors and heaters.
As far as possible, do not intersect either.

The photographs came out beautifully.
It would have been useful as the one at the top, but with a view of the right side where the cables go down. And such as the one at the bottom with a view of the tangle of wires on the left.

@_kaktus_: Thank you very much for your suggestions.

I didn't take a picture this time because I removed the zip ties I had tied the cables to the case after your suggestions and all cables are loose now.

I tried implementing what you said and moved the ribbon cable as far away from the other cables to the other side to see the effect: The display didn't go blank anymore. It seems a lot more stable.

However, as far as serial connection speed is concerned, ribbon cable location didn't seem to contribute a whole lot.
And to me it makes sense that it doesn't.
I'd assume that the serial connection goes from the serial cable socket almost directly to the SoC component that deals with serial communication and that is decoupled from the rest of the processing, isn't it?

Anyway, I did some more tests with serial connection speeds:
At 250000 baud, nothing seems to be communicated backwards and forwards.
When I compiled in 115200 baud, I did get communication going but it seemed to fail intermittently and then resume - it seems the connection is not stable.
When I went back to 57600 baud, the connection seems to be stable.

Do you think I may have a faulty processing board if you think that 250000 baud should be no problem?

Hi.


The first small success achieved.

This is one of the reasons why DIY printers are difficult to run.
This is all the more important because not all users have the knowledge about it.

I'll say yes, you don't have anything to blame for.

To solve the problem of transmission errors we can do some experiments.

The first easiest way to do this is to use a different USB cable.

Another experience is to connect the printer to your computer, and run it.
Then run the serial terminal program.
Configure and establish a connection.
Now you will be able to observe what is happening on the terminal.
When the characters are clear, it means that the connection speed is correct and there are no transmission errors.

You can repeat it for different speeds.

When you do a test, you can move the cables to different places and observe the result in the terminal.


If you need more precise tips, ask.

Hi,
on the baud rate issue...
I tried connecting and ancient "eee" netbook running Lubuntu to the i3. All the software worked fine set permissions on the usb port and then ended up with an error that said "failed to set baudrate" ( which I had to find by running repetier-host in a console)
It turns out that the USB1.1 hardware in the PC cannot handle the baudrate. and , rather than fiddle with the firmware in the printer( I only just built it a couple of days ago!) I abandoned attempting to use the eee PC
So the question you might need to ask is "how old is the USB controller in my Linux PC?" - that may explain the slow baudrate.

I don't know how fast the host computer needs to talk to the printer during printing, that may be why it is set so fast, but you COULD ( I imagine) set up the printer at ANY baudrate but then save the "sliced" image to an SD card an do the actual print from the SD card - I have not even tried printing from SD yet, so I may be wrong

Good luck!! i have managed some really good prints (IMHO) since building the i3 so it is worth the "fiddle".

1st: the x axis is slanted and whenever I try to set it straight, the right z motor grinds a little and then operates normally

I say either print a Z-wobble fix component and rework that part OR for a quick win try to loosen the screws around the lead screw and carriage end (Z axis screw). The coupler on the bottom of the Z axis might also be ex-center.
It's definitely not good to leave it like that, you have to fix it.

For the baud rate, strange, I am using OctoPrint on a Raspberry PI 2+, and it works great with the default (250000).

At worst, I think the baud rate of 56k could also temporarily work, the printer gets "g-code" commands, like "move along a line path from here to here", might be slightly slower on 56k baud but should still work.