Software Reset during auto level

edited September 7 in General
Hi,
I do have a selfmade cartesian printer controlled via a RUMBa board (not the plus version). I updated the firmware from 0.9x to 1.05dev. After auto bed level the printer restarts everytime after the last of three bed level points.

Is that the value given by the arduino-software? When compiling and uploading it says "Globale Variablen verwenden 6.936 Bytes (84%) des dynamischen Speichers, 1.256 Bytes für lokale Variablen verbleiben. Das Maximum sind 8.192 Bytes." (meaning 1.256 bytes free for local variables. there is an orange warning that the memory is maybe insufficient).

What may I check? I cannot "Reduce subdivisions" , because I do not find it, obviously because my printer is cartesian style.

best regards,
karl.ranseier

P.S.: edit:
Points for auto level:
P1(50|220) P2(50|50) P3(220|50)

Zprobe offset: (-108|-10)
Zprobe height: 13.850




Comments

  • A missing information: There is a servo with a microswith attached. After the last measurement point it moves back, than the printer goes off.

    Probe start code:
    M340 P0 S1165 R400

    Probe finished code:
    M340 P0 S1865 R400 \n G4 P400 \n M114


  • Maybe a brown out. Please control form repetier-host or server and look into console when it restarts to see what the restart reason is.
  • This is the protocol from repetier-host:
    16:25:01.165 : Z-probe:19.008 X:220.00 Y:50.00
    16:25:01.165 : plane: a = -0.0003 b = -0.0003 c = 19.0933
    16:25:01.185 : Transformation matrix: 1.000000 0.000000 0.000322 -0.000000 1.000000 0.000294 -0.000322 -0.000294 1.000000
    16:25:01.185 : Printer height:160.86
    16:25:01.185 : CurrentZ:19.09 atZ:18.95
    16:25:01.595 : Printer reset detected - initializing
    16:25:01.595 : start
    16:25:01.605 : Detected EEPROM version:20
    ...

    About the brown out: the power supply is 24 V set to 30 V with 15A. The current per coil is up to 2.5A. The x/y motors are connected via an external steepepr driver (trinamic steprocker). The z-motor is connected via the RUMBA. There is a 10mF capacitor in front of the RUMBa-board.

  • I checked the start and finish code from the console: Startcode runs without problems. After the line "M340 P0 S1865 R400 \n G4 P400 \n M114" the next command results in an error.

    20:36:51.524 : N24 M340 P0 S1865 R400 \N G4 P400 \N M114*35
    20:36:51.524 : skip 0
    20:36:57.326 : N25 M340 R400 P0 S1865*108
    20:36:57.386 : Error:expected line 24 got 25
    20:36:57.386 : Resend:24
    20:36:57.396 : Resend: N24 M340 P0 S1865 R400 \N G4 P400 \N M114*35
    20:36:57.396 : Resend: N25 M340 R400 P0 S1865*108
    20:36:57.396 : skip 0
    20:36:57.406 : Error:expected line 24 got 25
    20:36:57.406 : Resend:24



  • Brown out can still happen with that power unit. It is the stabilized 5V on the board that might go down especially after M340 P0 S1865 R400 which controls a servo connected to 5V and the board has maybe just 500mA for 5V.

    You have not pasted the relevant part after start with restart reason that shows the restart reason. I think "Printer reset detected - initializing" is a response of your host to "start" detected and not the response from firmware.

    You can not send 
    M340 P0 S1865 R400 \n G4 P400 \n M114
    from hosts as one line. Hosts will not split commands at \n causing errors. But the only critical command is 
    M340 P0 S1865 R400
    and only if the probe was already deployed otherwise current would be less.

    You can try also
    G30 P1
    which only deploys before testing and
    G30 P2
    which undeploys after testing.
  • Thanks for the explanation. I will do another test in the evening. Do you really think the brown out can appear just because of the new firmware? Using the older version I had never any problems with restarts.

    I will try to add a resistor and capacitor in front of the servo to reduce the current peaks..
  • Since you say it happens on undeploy where the magnet needs to suck in the pin and hence has higher load on 5V that makes at least sense. But that is also why I ask for the log to see if it was brown out. 
  • edited September 8
    I tried to check the logfile, but failed. Now my RUMBA-board is broken. I touched a metal part with a cable, have seen a spark and need now some time to fix it :-( .
    Therefore I cannot send anything right now.

    I found in another, older topic, that even with unplugged servo I had those restarts.

    It is a rotating servo having a small motor, the load is equal for on/off because of the rotation-symmetry.
    I will send the logfile as soon I have rebuild everything. Maybe it will not happen using the Rumba+ board, which I ordered.

    Thanks so far for your help!
  • I decided to change to Rumba32 instead of replacing the old one with the same version. So I think one can close this thread.
Sign In or Register to comment.