› ›

Connection problems to RP3B over Ethernet

tonyowens_uktonyowens_uk
in Questions & Answers
Hi. I normally connect to my RADDS/DUE/Repetier based printer via an RP3 which provides wired ethernet connectivity to a dedicated PC running Repetier Host. I find I need to set the TCP/IP Transfer Protocol to ASCII to get decent connectivity. The issued command to the RP3 is nohup socat TCP-LISTEN:5577,reuseaddr file :/dev/ttyACM0,raw,echo=0 &

Now, I have been trying to setup Repetier Server on the host PC as a next step. There doesnt seem to be a way to specify the ASCII transfer protocol on the Printer Settings page, and this appears to be essential to get connectivity to the Due via the RP3.
Am I missing something obvious here? If not, is there some other way to configure the connection to work the same way as when I connect directly using Repetier Host?

Thanks
Tony

Comments

  • RepetierRepetier
    Actually repetier firmware works best with binary protocol and since server speaks this and knows it, it uses that protocol automatically when you select repetier-firmware. Are you sure you have not marlin as firmware which does not work in binary format?

    The server defines firmware settings in /usr/local/Repetier-Server/firmwares here repetier.xml - this line

    <com okAfterResend="true" protocol="repetier" allowColonInAscii="false"/>
    tells to use repetier protocol. You can change it to ascii to force that for repetier-firmware, but as said there are only drawbacks normally, which is why I do not understand that you need it.
  • tonyowens_uktonyowens_uk
    Hi, thanks for your advice, and my apologies about the delay getting back to this issue. The machine is a large Massportal Delta using Arduino Due/RADDS 1.5 running Repetier_0.98.8, via Protocol 1.0, and has come to me totally undocumented and somewhat incompletely developed. It does not work reliably.
    This is a high-end machine which includes a Raspberry Pi host with 7" touch screen. My connection to Repetier is therefore through the RP, not directly to the Due.

    I am not (yet) knowledgeable about embedded systems. Could it be the fact that communication with Repetier on the Due is through the RP3 is the reason why there is an issue with binary comms?

    My objective here is to:
    1. Update the Repetier firmware
    2. try and get the machine running with Repetier Server
    3. to install Z-probing/bed levelling.

    Any help you can offer would be most useful, thanks
    Tony Owens
  • RepetierRepetier
    Ok, that is a bit unusual solution as the massportal has it's own software on the pi. Normally you would install the repetier-server on the pi directly and connect to it. With a separate sd card you could still try this, but I can't say how they connected it.

    Anyhow, to make repetier-server communicate to repetier-firmware in ascii protocol you need to go to installdir/firmware and edit repetier.xml
    There is a line
    <com okAfterResend="true" protocol="repetier" allowColonInAscii="false"/>
    Change protocol to ascii and restart server and it will connect in ascii protocol instead which if I understand you correctly is something the massportal software can handle.

  • tonyowens_uktonyowens_uk
    Well that seemed to work fine. Except (nsurprisingly perhaps), the PI-connected webcam doesn't work.
    Thanks.

    Having thought about this a bit more, I believe I am going to:
    1. Add another PI 4B+ to this machine, with a second 7" touchscrween, to host Repetier Server, the webcam, and act as a front end to the Due/RADDS board.
    2. Update to the current Repetier firmware and add bed probing/autolevelling, which dont work on this machine
    3. Segregate the existing RP 3B+ that runs the Massportal software bundle so that it only runs the filament driers. There are two fitted to this machine.

    The effect of this should be to regain control of the machine from the maker's proprietary (and incomplete) control system with minimal effort and with minimal loss of functionality. The only negative element is that I will now have to find time to understand the operation of PI's, and the Linux environment. And that might be a blessing in disguise!

    Tony
  • RepetierRepetier
    No need to learn that much about pi. We offer a pi image where webcam works out of the box and server is preinstalled. You should in this case also connect pi directly to the RADDS board inside the printer so you have no indirect connection any more.
  • tonyowens_uktonyowens_uk
    That's the plan now.
    I was hoping to access the existing configuration.h file, but in my developing understanding about Arduino Due, there is no filing system to speak of, and this file would only exist in the hands of the machine developer. So I'll have to use the online configurator, in combination with the EEPROM data which I have, to build a new printer firmware.
    All in a days work!
  • RepetierRepetier
    There is no need for different firmware!
    Firmware is on the due and is ok - just connect the usb port to the other pi and all is done. Then your pi controls the printer directly over isb and not tcp any more. The printer display still controlls the dryer.
  • tonyowens_uktonyowens_uk
    Yes, but...
    The 'but' is that the Due is still running 0.92.8, while I plan to add both autolevelling and filament sensing. My thought was that release 1.00 would be better.
    To provide a path back, I'm going to install a fresh Due with the upgrade and additions, and a different PI with Server on it. The existing PI can stay, and just control the dryers. I will add another 7" touch screen controller to display the Server GUI, and attach this to the machine frame with a small ergo arm.
    If there are major issues, I can always swop the Due's and reconnect the old one to the new PI.
    Quite a lot of work, but I want to stick with Repetier and RAMPS due to the step/direction interface for motors. Duet doesn't offer that, and it isn't a priority for them. That allows me to look at replacing the belt-drive delta sliders with ballscrews and closed-loop stepper motors later this year, which opens the door to increasing the chamber temperature beyond 80C.

    Tony
  • RepetierRepetier
    Ok I understand. See https://www.dropbox.com/s/lg3ikq3rod509es/Configuration_Pharaoh.h?dl=0 that is my 5 year old config for my Pharao with 20x4 char display. Might be a good start - guess config tool will level it up to latest settings automatically.
  • tonyowens_uktonyowens_uk
    Very generous, kind sir. Would you happen to have a pins.h file to go with that?
    Our machine is a D600, which has almost identical motion hardware and control components to an XD40. This is very helpful!
    Thanks

    Tony
  • RepetierRepetier
    My Pharaoh has a RADDS board inside and that is a known board for due. If they have exchanged the board by a self made board I have no pins, but you can ask their support. You can also ask for firmware sources used.
  • tonyowens_uktonyowens_uk
    The new RP4/touchscreen was integrated successfully with the existing Due/RADDS motion planner/controller board and the printer webcam yesterday and Repetier Server is available across our LAN. Very smooth!

    Next, there are some bugfixes to do e.g. the chamber temperature sensing which doesn't work, and the extruder selection servo needs testing.  Then, we will provision control pins and wiring for filament sensing and bed probing. I expect we will reverse-engineer a pins.h and configuration.h file, as we go through that process.

    When we receive our new Due board, we will then use these .h files to upgrade to the latest firmware.
    Unfortunately we cannot count on support from the manufacturer.
  • tonyowens_uktonyowens_uk
    Hi Markus.

    An update on my project:
    The extruder selection servo and chamber fans work directly from the Repetier Server HMI panel with no changes. I am working my way through definition of a new configuration.h file.

    One question arises:
    The chamber temperature is sensed using a thermistor connected to Channel 4 of the RADDS thermister input header. Running Repetier Host, through the Massportal RP3, to the Due/RADDS, the chamber temperature is correctly polled for and displayed by an M102 command, which seems to be issued each second by the RP. Fine.
    Now, when I swop out the Massportal RP3B and replace it with the Repetier Server RP4B, which is configured to expect a heated chamber, the current chamber temperature is shown as 0 C. See linked PP file with picture of the display on the Server HMI:
    https://www.dropbox.com/s/vdijl18bbapxrlc/Re-engining of MassPortal D600 with Repetier Server.pptx?dl=0

    Can you clarify the questions on the final slide in my PP document for me please? Thanks

    Tony
  • RepetierRepetier
    That eeprom image looks strange. I have never seen these entries. Was that with the original due version over their connector? If so it looks like they modify the output. I hope they have connected all sensors etc to the board.

    The Problem with the chamber temperature is that 1.x firmware has no chamber support. Only firmware V2 has this. Server/host expect in temperature response M105 C: for chamber, but when you define it as extruder it gets returned as T1: for second extruder. One question is if you should better directly start with V2 firmware which is describe here: https://docfirmwarev2.repetier.com/ and is available in dev2 branch on our github repository. All functions and your board are already supported also I did not have tested very much with the delta, but all seems to work as expected so far and should give superior results to V1. there is a sample config for delta as well just for different board with 2 extruders.

    For open door detection you need to define DOOR_PIN with the door sensor pin. It will issue a message that server understands. In server configuration you can tell what to do when it is detected. It ranges from nothing over show in interface to pause print.
  • tonyowens_uktonyowens_uk
    Thats fantastic Markus. I wasn't aware that V2 was that far developed although I did suspect that chamber temp control was not directly present in the V0.92.8 firmware I have loaded.
    To answer you question about the EEPROM data, this is the new RP4 running Server, connected serially to the programming port on the Due/RAMPS. Repetier Host reports that Due as running firmware v0.92.8. It seems hard to believe that there is any other intelligent life running on the Due.
    When I swop over the RP4 with Server to the orignal RP3 running the Massportal front end, Host (running on a Windows box connected via hard Ethernet to the RP3) starts streaming the string "M105 S" at 1 sec intervals, followed by the response "XX.XX C" (a single temperature reading) and the suffix "Chamber temperature". I assume this is a formatted response to an M105 command issued by something running on the RP3.

    OK, so I will restart building a config.h file, but based on V2 firmware. All very interesting!

    Tony
  • RepetierRepetier
    M105 is send by server every second if firmware doe snot support autoreport temperature. My guess is that massportal has modified the firmware on their own. E.g. making a C: appear for chamber.
  • tonyowens_uktonyowens_uk
    I'm slowly immersing into a new world (to me) of microcontrollers, firmware and their coding. I've started with the v2 documentation and looking at the v2 files on github. I have a fresh Due to play with and have documented the wiring to the RADDS in my Massportal D600 delta printer. I find this line of work a bit intimidating but I think I'll be OK! I'll get stuck in properly in a couple of days time.  
Sign In or Register to comment.