Unknown command

I repetier,

I have installed last 1.0.0dev version downloaded 18/2/2017 for my mini Kosser with Chimera and autolevel
but when I send M99 X0  from Repetier host I receive continuos message of Unknown command.


22:27:49.386 : SelectExtruder:0
22:27:49.386 : X:0.00 Y:0.00 Z:199.150 E:0.0000
22:27:49.402 : Info:Autoleveling enabled
22:27:55.096 : N66 G91*33
22:27:55.096 : N67 G1 Z-10 F3000*42
22:27:55.096 : N68 G90*46
22:28:07.607 : N74 G91*34
22:28:07.607 : N75 G1 Z-10 F3000*41
22:28:07.607 : N76 G90*33
22:28:19.619 : N80 M99 X0*99
22:28:29.619 : Unknown command:N12593  X0.00 Y0.00 B0.00 L0.00
22:28:29.634 : Unknown command:N12593  X0.00 Y0.00 B0.00 L0.00
22:28:29.634 : Unknown command:N12593  X0.00 Y0.00 B0.00 L0.00
22:28:29.634 : Unknown command:N12593  X0.00 Y0.00 B0.00 L0.00



  • edited February 2017
    M99 , afaik it is not used in repetier 
  • Hi MartinH,

    In this page   https://www.repetier.com/documentation/repetier-firmware/z-probing/  if I want Automatic correction after G28 and G131   it is possible to M84 or  as from the page 

     "So now the best way is to use M99 X0 to move the X motor for 10 seconds. You can change the time with S<time in seconds>. Use Y0 and Z0 for the other 2 axis."

    In the previous dev version I have not an Unknown Command after M99 X0

  • Sorry, my mistake, reading thru the code, M99 is a valid code so i don't see why it throws up the errors.

  • It is not M99 firmware is complaining:
    22:28:19.619 : N80 M99 X0*99
    22:28:29.619 : Unknown command:N12593  X0.00 Y0.00 B0.00 L0.00

    there is no G or M code at all in that command firmware receives. Also as you see the line number N is way of from 80 you send with M99. Are you connected with 2 hosts using different line numbers?
  • I repetier,

    I am connected to the Arduino with a USB cable of my PC with only one Repetier Host (last stable versione) as I have done so many times before (I have this printer for over 2 years) I just updated the firmware version.

    I do not even know how to explain how this message appears continosly in log windows after a few seconds that I sent the M99 X0 command.

    If I use M84 for all tre tower I can complete the procedure of calibration and autoleveling.

    Tanks in advise
  • Strange. That command is unchanges since 0.91. If you have a LCD have you reduced languages to a minimum? With 8 bit processor having more then 64KB data you get wrong pointers and stuff. Also for delta make sure to have 900 byte ram when arduino compiles and reports it. If you have not enough the stack may overflow into data and do strange things. 1.0 has added some functions and needs now more ram so that could be the problem. Reduce delta subsegments by 1 if that is the case.
  • I have only one language (English) configured, 

    I will verify better the post compile message and I'll try to change the Arduino Mega, I have one backup.

    Thanks a lot
  • me too.. same issue.. not solved by reducing 1 subsegment (still 776 byte free)
  • 776 byte free is not 900 as I meantioned you would need. Not 100% sure where the minimum lies but guess 776 is still not enough.
  • I checked last firmware that worked ok for about 6 month (repetier dev september 2016, i has only 756byte), what is minimun subsegments to go to?
  • Hard to say as this also depends on segments per seconds. The higher segments per second the more subsegments you want to have. This is what makes the due boards very attractive for deltas. With 96kb instead of 8kb you can have much more buffers and updates. Do you also have this change in line number? That change is what makes me think the memory position for line number gets overwritten or the part where it comes in.

    Has any of you a common board like RAMPS? Then I could upload your configuration for testing so I also see the error.
  • I repetier,

    yes i have an Arduino Mega with RAMPS 1.4 , but now I do not see how can upload a file in this forum


  • I repetier,

    This il my configuration.h file


    for repertier_firmware 1.0.0dev of 18 february 2017 for my mini kossel DLT180 with chimera,z probe  Arduino Mega ,Ramp 1.4 

  • I repetier,

    I have recompile the 1.0.0dev and I have only 594 byte free, I think, as you said, they are few.

    This is the message from arduiono IDE, sorry is italian, but it seems clear.

    Le variabili globali usano 7598 byte (92%) di memoria dinamica, lasciando altri 594 byte liberi per le variabili locali. Il massimo è 8192 byte.

  • tonight i'll upload my config., I have a gt2560 from geeetech in a G2S delta

    To sennalb, yes it is clear (I'm italian.. :-) )
  • Hi to all,

    Today I got to try better new dev version on my Delta printer, but it is essentially unusable, I managed to make the automatic correction procedures without using M99,  but soon after the start of a simple program to prints a  cube, after first movement , the Arduino resets.

    Thanks for any help
  • Ok, it is exactly as I said. You need more ram. I could reproduce these strange errors with your settings with 594 byte free ram. Setting DELTASEGMENTS_PER_PRINTLINE to 20 gave me 1042 byte free ram and all problems disappeared. So 600 byte is definitely not enough free ram.
  • Thanks Repetier,

    I did another test that confirms what you say, I recompiled last dev version using a non-graphical display (FEATURE_CONTROLLER 2) getting 792 bytes free and I managed at least one sempilce cube wihout reset

    I take it for delta printers is best to use Arduino 2.

    A question; DELTASEGMENTS_PER_PRINTLINE to 20 means having less precise movements? what is the effect  to lower this parameter ?

  • This has no change in precision. These subsegments are to store parts of one line so if you have a 100mm move and run 100mm/s with 100 computations per second you would need 100 of these segments. Means it will now block 5 moves in move buffer with that line. Previously it would be 100/24 = 4.1667 so still needing 5 lines. So this has an effect on how much you can cache. For short moves 20 is still enough to buffer full move. This is why repetier is so quick with delta but the price is memory usage.

    Due based systems have here the advantage of having 96kb instead of 8kb and of course being 10 times faster so more updates per second are possible.
  • Thanks Repetier,

    I just tried the latest dev version with DELTASEGMENTS_PER_PRINTLINE to 20 and the graphic display with a complex printing and I would say that now everything is OK.

    While I waited for the print I did a check on Arduino DUE, but it seems to me that the RAMPS-FD card is not yet stable even in versone 2.1 that I've seen on gitub of bobc, which board you use on top of Arduino 2?

    Thanks again for your support

  • I personally have my delta running with a RADDS board which is also what I use for all testing. If you buy a due make sure to buy a original. Some clones do not start correctly on first power up and need to reset after powering to work.
  • Thanks Repetier

    I will follow your advice for my new delta printer.
Sign In or Register to comment.