›

V0.80.2 Pro - Bad comunication with the printer!

Marco67Marco67
edited November 2016 in Repetier-Server
I upgrade my server, now when i try to print the printer doesn't respond.
After an emergency reset i can change bed and hotend temp, but with i try to print something it doesn't work.
In this "freeze" situation Repetier Host connected in lan doesn't read the eeprom settings.
Downgrade to V0.80.1 and same issue (RAMPS 1.4), but the problem is here when upgrade to 0.80.2.
The printer work fine if i execute a job from SD or using Repetier Host with a pc.
What's "destructive" in the new release? ;-)

Marco

Comments

  • RepetierRepetier
    Just tried reading eeprom from ramps board over host->server->ramps and it worked as expected. Also after emergency reset it worked. So please tell us what is your exact situation - server pc and os. If you enable logging in server over web gui what does it contain when this freeze happens?

    Is the problem repeatable and always at the same action? In that case please tell me what steps cause it. As soon as I can replay a problem I can fix it. Communication has not changed between 0.80.1 and 0.80.2 - we only fixed other issues.

    The other question is what kind of freeze do you get. In theory only the webserver part freezes and the server still runs.
  • geoffreyforestgeoffreyforest
    I have an odd issue with repetier server and eeprom settings as well. After a reboot of the server (RPi3) the server is unable to control the printer. If I connect Repetier Host and check the eeprom settings, they are mostly red (can't be read from the server?). But if I choose the restore settings to default, and then press cancel on the confirmation popup, the correct settings appear and then everything acts as normal. Host and server problems and control the printer.

    Maybe worth a shot?
  • NiklasONiklasO
    edited December 2016
    I also have problems after upgrading to 0.80.2. I can print ONE print using Repetier-Host. The following prints will start heating and then fail. Printer needs to be activated several times before it accepts that the printer is there. I also have had repetier-host freezing up on me. I can't remember having these problems with .1
    I can see the bed starting to heat and suddenly it just stops and repetier-server shows the printer as inactive/offline. I need to select "Activate" from the web gui several times before the printer becomes green again. Using Marlin. Server on Pi 2.

    Edit: No problem reproducing it. This is after one successful print:
    I have to press "Activate" several times before it changes to green/activated. Every time I press, the printer seem to reset.
    Don't know how the mouse pointer got way off but it is. ;)

    As you see, the print just stops and printer offline or deactivated. The printer does nothing. The requested temperature of the bed goes down to 0.
  • RepetierRepetier
    Hard to say from these informations what is really happening. I see the bed is heating and when it comes into control range - meaning where pwm kicks in it disconnects. Disconnect normally only happens when the port disappears on the system. Here it would be good to check all logs as well meaning you have to activate logging in server and check print log, connected.log (the one written to after print is finished), server.log in storagedir/log and /var/log/syslog to see if linux gave any hints for that point in time. Since it appears to be connected to pwm kicking in it might also be the ftdi chip crashing due to voltage drops. Would not really explain why 0.80.1 works but on the other side I haven't changed the communication after connection so not sure what to make of this.

    @geoffreyforest red values come from read errors during query of eeprom. So how does the log like when this happens?
  • NiklasONiklasO
    No disconnects. dmesg looks good.
  • RepetierRepetier
    Your video showed it disconnected, so there was one. Not sure if it would show up in dmesg - never tried that. So still open what happens. I think most important is server.log as one more reason for disconnect might be a server crash. But then it would reconnect on startup so not what I really expect. But it also shows when it reconnects ports. And last thing would be the normal print logs to see if there is something unusual.
  • NiklasONiklasO
    I can provide logs. The first print always works. The second one does not. Disconnects acting on USB will be seen in dmesg.
  • NiklasONiklasO
    edited December 2016
    Now it did it first print.

    Connected-log is empty.

    Print log just stops:
    > 21:39:30.670: T:209.4 /210.0 B:65.0 /65.0 @:65 B@:108 W:6
    > 21:39:31.670: T:209.5 /210.0 B:65.0 /65.0 @:65 B@:110 W:5
    > 21:39:32.670: T:209.6 /210.0 B:65.0 /65.0 @:64 B@:99 W:4
    > 21:39:33.670: T:209.5 /210.0 B:65.0 /65.0 @:66 B@:100 W:3
    > 21:39:34.670: T:209.7 /210.0 B:65.1 /65.0 @:64 B@:95 W:2
    > 21:39:35.669: T:209.7 /210.0 B:65.0 /65.0 @:65 B@:99 W:1
    > 21:39:36.669: T:209.9 /210.0 B:65.1 /65.0 @:63 B@:92 W:0
    > 21:39:36.749: ok
    > 21:39:36.749: ok
    > 21:39:36.750: ok
    > 21:39:36.751: ok
    > 21:39:36.751: ok
    > 21:39:36.752: ok T:209.9 /210.0 B:65.1 /65.0 @:63 B@:92
    > 21:39:36.753: ok
    > 21:39:36.754: ok T:209.9 /210.0 B:65.1 /65.0 @:63 B@:92
    < 21:39:36.757: M117 Layer 0/50
    and Offline/Deactivated.

    The print job just disappears without a trace from the server.
  • RepetierRepetier
    So server shows printer in red from that point on? Red = no serial connection and switching into that mode would also remove the print job. That should also be logged in server.log that a connection got closed.

    If that happens, is the serial device still available in /dev/ or does it disappear? If it is still there the server would normally try to reconnect every few seconds so color changes to orange.
  • NiklasONiklasO
    edited December 2016
    No, it goes to.. no color. Like when the printer is deactivated. And yes, printer still there in /dev
  • NiklasONiklasO
    edited December 2016
    I have to press "Activate" at least twice (or more) for the printer to become green again. I changed usb-port and the cable now, same thing. First print usually works but not the 2nd one. It starts heating and then just stops as before. No reset, no usb disconnect. The Pi 2 has a 2A power supply. Should be enough.  Used image V5. Before I used V4 but started fresh when V5 came. The printer does not reset or something like that when the "disconnect" happens. The job just disappear. Strange..
  • RepetierRepetier
    Ok, that is even more strange. The host does not even have the commands implemented to disable  printer and I assuem you did not send it on your own. So I will check if I see a way fot this to happen. In any case I will update disable command to be ignored while printing. At that time it makes absolutely no sense.
  • NiklasONiklasO
    edited December 2016
    Hmm, it could be because I kill the power to the usb-ports from the command I talk about here:

    The LCD screen (and LED in BLTouch) stays on if the Pi is running so using that would turn off the printer and the usb-ports. I happen to have my printer in my bedroom. ;) I have some prints now running fine if not using hub-ctrl to deactivate/activate the ports. I may need to reboot the Pi after sending power on. How would I restart repetier-server only? Now I restart the Pi completely after sending the on command.

    Edit: Spoke too soon. It just stopped again but now the web gui had "Firmware was halted" error message. Using the RCBugFix-branch of Marlin so everything could be my own fault. ;)
  • RepetierRepetier
    You can restart server with
    sudo service RepetierServer restart

    if you check /lib/systemd/system/RepetierServer.service you see you can easily add scripts on start so you could enable usb power there as well.

    You could check what happens if you are connected and you disable power. I would expect the printer just getting red for not connected assuming the serial device disappears and not grey as you said above. You can also make the commands selectable from server as commands.

    Firmware halted from Marlin is of course a marlin/hardware/config bug on printer side, depending on reason for halt.
  • NiklasONiklasO
    edited December 2016
    Thanks!
    If I disable power as in my scripts it shows up red and disconnected. When I apply power again the printer goes yellow and then green. Not always. Sometimes it stays white and I have to press Activate at least twice. Three-four times often.
  • RhinoRapRhinoRap
    This is the fault I logged a few weeks ago and had next to no support for it.
    Logging simply **stops** as does the print and code - sometimes mid print.

    coincidentally I removed the (cheap) webcam and the problem sopped - but by then i'd gone over to Octoprint.

  • NiklasONiklasO
    I use a "no name" cheap webcam...
    But now I have had like 10 prints after each other without problem. It just happens but now I restart the Pi after powering on the ports and the printer..
  • NiklasONiklasO
    edited December 2016
    It did this while the extruder was heating after a fresh reboot I did moments ago (I just started the print):
    When the set temperature was met, it moved the X-axis in the wrong direction and collided with the physical max, causing the stepper motor to do it's grinding noise. I had to press reset (on the printer) to stop it. This has happened before.

    Edit: The print preview starts to draw lines too but the printer is not up to temperature yet.
    It seems like something goes wrong between host and server. Trying to print several jobs after each other will fail, restarting host makes it work again. Sometimes host just go unresponsive. To close I have to right click the repetier-host and select close. When all prints failed the server showed "Job 1", "Job 2" and so on, not the name of the file and no rendered image. It then said print done after 17 lines. Tried several times before I restarted host and now it just works again.
  • NiklasONiklasO
    edited December 2016
    Well, I started to print from the webgui instead (to see if host was the problem). Uploaded file. It worked for some prints but now it just started to suddenly show the printer as deactivated while heating again. :-(
  • RepetierRepetier
    I'm running some final tests for next release where deactivating while printing should fail. Hope to release tomorrow.
  • NiklasONiklasO
    edited December 2016
    I sure hope it will help. I tried OctoPrint in desperation here but didn't like it.

    Why did I get all that in the log when the printer was still heating? (image in earlier post, https://drive.google.com/file/d/0B13H1MftDH4lNDl5aEdMSEtsWnM/view).
    When it came up to temperature the head crashed to the right side on the X-axis. It has happened several times and repetier-host starts writing the lines way before the printer begins printing. Not even heated up. After a while the print fails.
    This does not happen all the time and I may have missed it before.
  • RepetierRepetier
    New version is out.

    Timeout means server expected some response from firmware. This is normally set to 30-40s except if your firmware supports the busy protocol reporting long taking tasks like newer Marlin/repetier versions do. 

    The heating should be considered a long task and not cause the timeout. But for better analysis it is required to know the start and eventually see the complete communication when such things happen. 
  • geoffreyforestgeoffreyforest
    Repetier said:
    @geoffreyforest red values come from read errors during query of eeprom. So how does the log like when this happens?
    @Repetier Which log would you like to see? From Repetier-Host? I think I remember where that file is located. Or is there a log for the server? Sorry, I'm not familiar with finding the log files, but I'll send you whatever you think would be helpful.
  • RepetierRepetier
    Since you print over server the server log is what is needed. In web frontend select printer and right top printe rmenu has a option logs. There you can activate logging and later also download the logs.
Sign In or Register to comment.