Possible communication errors with repetier-firmware. about octoprint

[KazW]

You're getting further than me... When I hit "Connect", OctoPrint just hangs.

[daftscience]

If you're using the repetier firmware I had to comment out the line
'''
#define WAITING_IDENTIFIER "wait"
'''

And set the baud rate in the EEPROM to 115200

Rebooted and switched to the shortest cable possible.

[lincolnep]

Hi Guys would impermenting the repetier protocol be a possibility as i think that this would fix any issues with octoprint and repetier firmware?

here is what a quick dig for the repetier protocol turned up https://github.com/repetier/Repetier-Firmware/blob/master/repetier%20communication%20protocol.txt

Most of this is does not mean anything to me as i am a new ish to arduino.

Thanks for such a great piece of software

Lincoln

[KazW]

Passing the GCode in binary doesn't make a difference for Repetier, it supports US-ASCII(plaintext) and binary. Both Printrun's driver and RintCore's can successfully communicate with Repetier.

While developing RinCore (a Ruby RepRap driver), I had similar issues when I exited the listening loop because an invalid/unexpected response was received. I'm not great at Python, but I''ll see if I can dig through the source and find a bug.

[daftscience]

Thanks, yeah it's been years since I've done any real programming, and just started to pick up python recently.

So are you using repetier firmware with octoprint? I don't know if anyone has been able to get it running yet.

[daftscience]

I was literally writing up a comment saying that I was going to have to give up when I found something interesting. Repetier uses just one bit to determine if the commands are ASCII or binary. Because of this, there is a high error rate. To correct that repetier requires a checksum on every command sent. @foosel suggested that this might be the case, but I hadn't yet pulled the version where that change was made.

Here is a discussion describing this issue.

So now for the good stuf:
To get octoprint to work with repetier make the following changes to configuration.h in the repetier firmware

comment out this line:

#define WAITING_IDENTIFIER "wait"

and set this one to false

#define FEATURE_CHECKSUM_FORCED false

**I don't know how reliable this will be, because I haven't printed with it yet. But I will try later tonight and report back.

[foosel]

I've dug through the parts in the firmware where these settings are used and just added a branch at https://github.com/foosel/OctoPrint/tree/repetier where I've tried to achieve the following:

• Interpret a wait as an empty line, because that is what triggers the M105-pings from OctoPrint to the server and therefore keeps the communication loop going
• Added an option to always send along a checksum. I had to introduce current-line-tracking into the communication layer (so far it only had to track the current position in the gcode file being printed), which also take care to react to m110 commands to properly set back the counter. Some dry runs with the virtual printer looked ok-ish.

@daftscience (and of course anyone else with repetier firmware), could you please give these changes a try the above configuration changes reverted? The interesting commit is 8ef580c I'm especially unsure if the wait stuff works as I hope it will, I can't test it with a real firmware image here (at least I think so, my Ultimaker does not seem to be among the supported boards), so it's a bit poking in the dark ;)

[foosel]

Related to #74

[foosel]

I just realized that the checksum part of the patch I made in the repetier branch will probably break resending, working on that now.

[daftscience]

Thanks!!, after a tiny modification that code works. However, issue #74 still exists.

gcodePos and current line were out of sync when a print was started commit.

Thanks again.

And I don't think I've seen octoprint ever attempt to resend a command.

[foosel]

Closing this because connection now at least works, continued communication is being debugged in #74