please do the obvious - network printing

Hi there,
Repetier Host is a perfect tool to control USB/RS232 connected printers and Repetier Server is great for connecting printers to a network. But why can't they work together?
I want to use Repetier Host on my PC to control my printer, which is connected to a raspberry pi with wifi. Doing this is almost impossible... Why?! It would be so simple...

Repetier Server should expose the RS232 communication channel of each printer to a configurable TCP Port.
Repetier Host should be able to connect via TCP/IP instead of RS232 only.

Thats all... Why don't they do the obvious?

Because it is not so simple. Channeling the communication through a socket is indeed not difficult, but that would break the server functionality completely. One important part of the server is to ensure, that no two users print at the same time. And this works only if you use the provided api. And this API is currently changing for the next server release. So we have to wait until the server api is final.

---

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!

It is that simple... I can use "socat" on my pi to expose the RS232 interface to a TCP Socket and I can use my own tools to communicate with the printer without problems (did that yesterday). However, it is a pain in the ass to get Repetier Host to communicate via TCP. There are tools available for windows that create pairs of virtual RS232 ports which are virtually connected AND there are tools for windows, like socat, that can also connect RS232 ports to TCP sockets.
However: Getting the whole path (Repetier Host connecting to virtual RS232 Port A, virtually connecting Port A to Port B, connecting Port B to TCP Socket on Pi and connecting TCP Socket on Pi to RS232 on Pi) to work reliable is really horrible. I managed it to work for a few seconds/commands, but soon I get communication errors and communication stalls.
If Repetier Host would speak TCP (which is not complicate at all, you can literally change RS232 sockets with TCP sockets) it would work like a charm.

>> One important part of the server is to ensure, that no two users print at the same time.

A TCP Socket does not have to allow two or more clients being connected at the same time. It may always reject connections if it is already in use. Thats no problem at all... It may also provide "read only" mode for those connections, so they can read the printers status information but cannot issue commands.

A simple TCP connection is planned for the next version. At least if I can get it running over socat.

But if you do this with the server there is no sense in having the server as you loose all functionality.

---

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!

Not really... Server is good for 2 reasons:
1) Having the printer available via (W-)LAN at places which have not to be near (<2m) my PC
2) Having the printer printing without Host-Software connected

Yes, you loose functionality 2) while you print via TCP connections. But you can switch all the time to the method that suits best in each scenario.

If I have a new object to print or do some tests, I want to control my printer with the buttons in Repetier Host immediatly. You can't do "print debugging" with Repetier Server. Controls are delayed and not that easy to use. However, when my tests are successful and I'm having a gcode that actually works fine, then I upload it to my server and use repetier server for further prints of that object.

It would be great if you could toggle printers within Repetier Server between TCP/local use OR if it would do that on its own (reject one way when the other one is in use).

Further info for socat etc: http://www.eroldan.net/blog/serialoverlanwirelessfor3dprinters

Ok, I understand. While printing the port gets blocked and if you are not printing it would block printing. We could even keep the server in read mode like if a job is running. I like that idea. That makes implementing one host connection easy.

---

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!

Perfect
So sad that I suggested this to repetier on the official homepage months ago and never got a response :/

btw. I guess the problem I had with the tools like socat and com0com is because they don't work/buffer line-based. If my printer receives a command like "G" in one Data-Frame instead of "G28\n" it freaks out (this is what happens if you use telnet to connect to socat and start typing). It looks like it doesn't wait for EOL to process the commands and neither does socat/com0com when forwarding comands. This lead to commands beeing splitted in two different frames and beeing not processed correctly. I guess it should be implemented with line-based buffering on both sides...

Hi,

@repetier
And is this nice idea implemented yet ?

Regards

Yes, since Host 1.5.0 and Server 0.65 this works very good.

---

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!

Thank you. It's worth my donation :-)

Quote
repetier
Yes, since Host 1.5.0 and Server 0.65 this works very good.

Macs are still on 0.56!