Printer communication with Repetier

I am working on a school project in which my Mechatronics class is working on building our own 3D printer (Hardware from a kit, but programming everything ourselves). When interpreting the G code while printing (simulating a real print by sending strings to the display to test my code) Repetier stops sending lines of code to our micro-controller. Does Repetier expect something to be sent back from the printer before it continues to send G code to the printer? If so, what needs to be sent?

Edited 1 time(s). Last edit at 04/25/2015 12:28AM by gaskins1992.

I haven't looked at the code, but I am.sure that an ACK is expected. I run marlin and have no problem communicating with it from repetier host. Look into marlin .... probably into the serial portion of the code and see what it is using as an ACK.

I figured out that it uses the fletcher-16 checksum but I'm having problems obtaining the number of bytes each line received contains. Any suggestions? We are using CodeWarrior and controlling everything with a dragon 12 light microprocessor for our board.

I'm really.not all that sure, as I haven't dug into the guts of the communication. My best advice is yo open existing firmware and see how it parses the incoming data. I have looked at it just a bit in the past, and I am pretty sure it's literally just ascii strings of g code being sent. If you open marlin firmware I want to say there is a long select case statement that checks to which command is being sent by the host. If you find that portion you will see how it responds, the ACK message, and any delimiters that are used. If I remember correctly it just checks the buffer for a g or an m and then goes from there, so it might not actually use delimiters. There is probably some repetier documentation that covers all of this.... repetier has the host software and also it's on firmware for reference.

Correction. ... a switch case statement. .. not select case. Had my mind on visual basic

I don't know about Repetier in particular because I have never used it. However, low-cost printer electronics that is based on the atmega2560 chip uses a USB-over-serial interface to the host, with no flow control. So the host has to wait for an acknowledgement from the printer to know that it is safe to send further gcodes. The usual solution is to either run Marlin or other software that emulates Marlin on the printer electronics, which means that the firmware sends an "OK" response after receiving and processing each gcode. I guess it's the OK that Repetier is waiting for.

If your printer electronics has a true USB port and not USB-over-serial, then you can tell the host software not to wait for acknowledgements. I recall reading that this setting is called "ping-pong" in Repetier.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].