›

HUGE PROBLEM after 1.4 update!

chazychazy
in Repetier-Server
After the update to repetier 1.4 become HUGE problem that don't let me print again!
After starting the print, after 2 layers, repetier send a like M600 code and my printer ask me to change filament. If I let do it, after few layers, the nozzle is crashing on the bed..
WHAT DAMN DID YOU DO WITH THAT UPDATE?!
Printed perfectly since 2 mins before the update.

Comments

  • RepetierRepetier
    There was no work on filament change routine. But to figure out the problem more information is required.
    First was the filament change correct or not? You say a few layer later nozzle crashed into bed. That does not sound like the filament change is causing this. Actually printer should forbid internally moves below bed. For analysis the log and some relevant times like when did you change and when did it crash be required to see if there were any commands that would cause this. And then question is next where do they come from. Continue script or our internal code. Any commands thatmodified coordinate system while filamentchange, ...
  • chazychazy
    Since 20 minutes before the update was working perfectly (and I have it from 1 year).
    I tried to change the draw too to see if the problem was the model, and did the same think. So, it's the update. No way.
  • chazychazy
    After the filament change (that no one on the slicer out an m600 code) start again printing and after 1 minutes it crashes on the bed.
  • RepetierRepetier
    The M600 comes most likely as response on some message from Firmware. You did not say which you are using and how filament change/sensor is configured there. But it sounds like marlin and like you handled it on printer directly. That is always dangerous as server does not see what you do. So server restores on last data known.

    But again, without seeing the communication it is not possible to say what causes the nozzle crash. I can only say we did not change filament change processing actively - so it may be a side effect of something or unrelated and bad luck. Not the first time users say it's our fault and after debugging it was something different. Here firmware might have moved head down as well without server knowing so you just get deeper. Not saying this happened, just what could be.

    What happens e.g if you run during a print the server pause and then continue? That is the same handling as on M600 just without the firmware interference and also easy to test and log.
  • chazychazy
    Unique things to do is: let me know how to roll back to 1.3.0 and we'll see.
  • chazychazy
    As. For the last time: was working perfectly with other firmwares, from 1.0.1 to 1.3!
  • chazychazy
    Did a try to print THE SAME DESIGN, with the SD and without repetier: works perfectly!
  • RepetierRepetier
    Just run manual installation of 1.3.0 - but the layerinfo files might not be readable for 2d preview. Format has changed a bit.

    For comparison you also would need to run M600 of course in between. I remember a user with older server version had same problem. Just forget what reason was but there was a reason for the shift not coming from server.

    Anyhow maybe some day someone gets same issue and will show required info to fix.
  • chazychazy
    It's absolutely coming from server! Course with version 1.3 works perfectly and without it, with SD, works too.
  • copposhopcopposhop
    How can someone looking for help be so unhelpful himself? Stop shitting on people improving the software you propably use for free. Tell them what's your issue and help them find ypur solution.

    Use "@debug 1" to enable the full server log then send "M111 63" to enable all printer-side debugging messages (in case you're using marlin, which you didn't specify).
    Then, while printing, you can send "M600" for example to pause the printer, which simulates the filament change.
    See if your printer acts the same as before and look at the terminal log to see what your printer is acually doing.

    You might have already found your mistake by now, if not paste your log in here and somebody might actually be able to help you. 
    If your print is working via SD, see if you have written any event dependend scripts in repetier server (like run on print job, run on pause etc.).
    If not, do you use any g-code replacements, do you have any timer related functions, do you have a filament runout sensor? What printer are you using, what firmware are you using? 


  • chazychazy
    edited July 2022
    Hey kid, what you mean "software you probably use for free"?! I PAID a license course there are 3 printers attached! Do you know what I mean?! Do you understand that I cannot use WHAT I PAID for a damn stupid update?! And If you read the messages before, you can see CLEARLY that before the 1.4 (and 1.4.1 same problem) it was working perfectly! I used it for more that a year!
    And when you gave me "advice" you let me laugh! Are more of 5 years I'm in a 3d printing.
    Poor kid..
    So, shut up your mouth.
  • KilrathyKilrathy
    the only one who needs to shutup, is you chazy. And please learn some english, it‘s hilarious what you are writing. I think you even don‘t know the words your typing. You don‘t want give any more informations, you only blame the software. To be clear, printing over SD doesn‘t proves any shit, it only shows that the gcode is good.

    The worst at all, maybe there is a bug and you discovered it. But just because you paid something, you are like „fix my god damn problem, I am your boss“.

    Sorry kiddo, you deserved nothing other but a broken software. Now please be a bit more polite or don‘t write again. this is not a kiddy forum where. ou can flame other people.
  • chazychazy
    Ops, little kid.. as you can see, so many people have the SAME PROBLEM from the 1.4.0! So, now do you think you're stupid?! Yes, think about that.
  • Kru5sty3dpKru5sty3dp
    edited September 2022
    I've had the exact same issue after upgrading from 1.3.0 to 1.4.1 and have just managed to fix it. 

    It was caused by the runout sensors being enabled when they were expected to be disabled. I don't use them, therefore I had them disabled from the LCD in Marlin firmware. 

    Whenever I connect the printer, RS activates the rounout sensors now (M412?). 
  • RepetierRepetier
    Yes, for that reason we remove it in next update. Users needing it can still add it to runonconnect event script.
  • chazychazy
    How much we have to wait for the fixed update?! I think it's overtime..
  • RepetierRepetier
    Probably next week 1.4.2 will be released with the M412 removed form start script. Also all other found bugs are then removed. If this solves your issue as well is unknown as we have no way to test it. We got no other complains except M412 related so it is the issue or yours is very specific and maybe configuration dependent. 
  • chazychazy
    Still nothing..
  • RepetierRepetier
    Just releasing:-)
  • chazychazy
    After the update, problem fixed.
    Now we can print, again.
    Thanks.
Sign In or Register to comment.