Defined Printer Limits

I keep getting the following message when I try and start a print.

'According to your defined printer limits, this print will not fit inside your printer. Print Anyway?'

I can choose to print anyway and it works fine. This bug started after my update to 85.2.
«1

Comments

  • Actually it is not a bug but done on purpose. We now test if all extrusions are only above the bed shape. So if you get this message always I guess this is not the case. Most likely you use some initialization that does extrusions outside the bed area and the causes the message. In that case you need to help server to ignore these moves:

    @nosize

    Ignore next print moves for object size calculation. This is interesting if you make a extrusion at a fixed position. Then the server will include that into the size and that may lead teh rendere to show a much too small object.

    @size

    Stops the @nosize command from neglecting size computation. Never forget this if you use @nosize. They should always come as a pair.

    So put at the beginning
    ;@nosize

    and after this outside extrusion add
    ;@nosize
    so it then can start with gcode rendering. Everything inside @nosize does not get rendered.
  • Strange, if this has always been in place, then why has it not shown up until after the update. All slicers I have used do a purge just outside of the print area before moving in to do the skirt and the rest of the print.
  • That feature is new. Previously we would print everything without test. But especially with large objects this can lead to expensive errors, so we now run this test. And as you just confirmed it is working! So just add the server commands to exclude your purge and it will really show correct positioning. Maybe I can remove pure extrusion on first layer from counting to position test. Will check that as an improvement.
  • Yeah, if you could remove the check on the first layer or ignore the check for the common purge locations, that would be great. With the update, the server now has all my files marked as bad. So I either have to manually update the gcode within server or process the stl file with the new coding and upload again.
  • I've also had this since upgrading and don't fancy having to go through and update all my STL files I use for each printer.

    Would it be possible to add an option (Either per printer or per server) to disable this warning?
  • I prefer more not marking purges outside print area as part of print area, so it does not appear any more. After all it is an important information that your print will fail. Only shortcoming was that I did not consider users extruding outside print area.
  • I don't mind the check, just need it to ignore purges on first layer. If that is done, it should be a very useful addition.
  • I have the same problem and I am not extruding outside the print area.  If it warns users without a valid reason it means that the checking is not made correctly and it is a bug not a feature.  Of course there ere way around it but the most straightforward one is to provide users with a way to disable it.
  • I never saw a invalid message here. But if you have one please show me. Post printer configuration exported and the gcode not fitting also you say it fits and I check what is wrong. Put  files on dropbox or similar fo download.
  • Here is a quick screenshot.  Any Gcode does not fit. Probably something is wrong in the configuration but I can not what (screenshot of config also attached). Printer is CR10s
  • settings for X-Min and Y-Min should be 0 , not 300
  • I'm getting the error before every print as well, regardless of the size of the object. Double checked all my settings and made sure minimums are at 0 and my max is correct. Using the most current build 90.6 on Raspberry Pi 3B+ with my Prusa i3 MK3.
  • I confirm that Xmin Ymin did not change anything with regard to print limits warning (and they were autodetected values)
  • Did you also check the bed geometry for same error? If all is ok you can still send me the files so I can check it, but I'm quite sure it is a setting or print is really outside. YOu can also check in th emodel directory for filename.gin and should see something like
    xMax: 15.10099983215332
    xMin: -15.10099983215332
    yMax: 15.10099983215332
    yMin: -15.10099983215332
    zMax: 26.700000762939453
    zMin: 0

    showing the computed dimension of the gcode.
  • I performed an update (and had also set Xmin and Ymin to 0 previously).  The warning suddenly disappeared for most prints.  I do not believe the update was related but maybe because the server had to restart made a change.

    I also re-entered a new printer profile in Cura and then I noticed that the old profile would systematically place the prints outside the print area.   The new print profile would place them correctly on the board and therefore there was no more warnings. 

    I conclusion, it was combination of bad settings both in the slicer and repetier's prints settings. 
  • Just for reference I am putting here the GCode heading of the old and new profiles of the same print.

    Old profile:

    ;FLAVOR:Marlin
    ;TIME:26645
    ;Filament used: 45.4035m
    ;Layer height: 0.25
    ;Generated with Cura_SteamEngine 3.4.1
    M190 S65
    M104 S218
    M109 S218
    M82 ;absolute extrusion mode
    G28 ;Home
    G1 Z15.0 F6000 ;Move the platform down 15mm
    ;Prime the extruder
    G92 E0
    G1 F200 E3
    G92 E0
    G92 E0
    G1 F2700 E-6
    ;LAYER_COUNT:464
    ;LAYER:0
    M107
    G0 F3600 X21.755 Y-41.74 Z0.3
    ;TYPE:SKIRT
    G1 F2700 E0
    G1 F1800 X26.908 Y-39.695 E0.34574

    New profile: 

    ;FLAVOR:Marlin
    ;TIME:25942
    ;Filament used: 36.3267m
    ;Layer height: 0.25
    ;Generated with Cura_SteamEngine 3.4.1
    M190 S65
    M104 S205
    M109 S205
    M82 ;absolute extrusion mode
    G28 ;Home
    G1 Z15.0 F6000 ;Move the platform down 15mm
    ;Prime the extruder
    G92 E0
    G1 F200 E3
    G92 E0
    G92 E0
    G1 F2700 E-6
    ;LAYER_COUNT:464
    ;LAYER:0
    M107
    M204 S5000
    M205 X30 Y30
    G0 F3600 X117.654 Y95.241 Z0.3
    M204 S500
    M205 X20 Y20
    ;TYPE:SKIRT
    G1 F2700 E0
    G1 F1800 X118.892 Y93.833 E0.09354
    G1 X119.377 Y93.338 E0.12811
    G1 X120.746 Y92.085 E0.2207
  • I´m shure the negative Y moves caused the error as they are out of printers limit

    Quote:
    G0 F3600 X21.755 Y-41.74 Z0.3
    ;TYPE:SKIRT
    G1 F2700 E0
    G1 F1800 X26.908 Y-39.695 E0.34574

  • probably.  No idea why Cura was doing that!
  • I am upping this thread again because Repetier now does again exactly the same for every printer I add:  Complaining about the prints being off limits Perhaps Cura hates me or I have a repetier curse ... whatever it is, it an annoyance that there is no option deactivate this useless spam warning.
  • It is not spam it is a serious warning if print is off limits. If it fits you have not set limits right in server. If limits are right the print is really outside and would fail.
  • Well the thing is that I am pretty sure that the limits are set to the correct size both in Repetier and in Cura, they even light green to show the setting match the firmware values.  And the prints are pretty small to be offlimits. You could even try a 1 mm square in the middle of the bed and it will still complain about printing off-limits.    there is something else that makes Repetier believe that it is printing off-limits.  And that something is a discrepancy for sure because prints are fine with every other functionality (i.e. Control, exclusion of Gcode etc.)
  • To narrow the problem you should check what server thinks about dimension. Go to model storage in ssh terminal

    cd /var/lib/Repetier-Server/printer/Felix/models/

    Replace Felix with your printer slug. Then run ls to show files. Take the one you are interestid in and cat content of the gin file

    cat name.gin
    At the end you will see something like

    xMax: 112.56400299072266

    xMin: 0

    yMax: 112.56400299072266

    yMin: 0

    zMax: 4.599999904632568

    zMin: 0


    Then you know what the real dimension is according to server. That must be covered by the min/max dimensions in general printer configuration.

    It is possible that you have a extrusion outside. My prusa config for example will do that at y = -3 so I had to allow that even I do not want to print there. Alternatively you can omit these parts using


    @nosize

    Ignore next print moves for object size calculation. This is interesting if you make a extrusion at a fixed position. Then the server will include that into the size and that may lead teh rendere to show a much too small object.

    @size

    Stops the @nosize command from neglecting size computation. Never forget this if you use @nosize. They should always come as a pair.



  • edited May 2019
    Hey Same Message,

    Do this (if you're purge line is G1 Y-3.0 F1000.0 ; go outside printing area ):  :D  

  • Hi,

    So i haven't printed anything in a while and was on Repetier Server 0.91.2. I now upgraded to the latest version 0.92.1 and today i wanted to print some things and for each of my uploaded GCODES i now get the Security Question about the printer size. 

    1. My printer profile in Repetier Server has not changed from 0.91.2 to now and has the correct print bed size settings.
    2. My S3D and CURA profiles are also all the same since 0.91.2 and i have not made any changes to print bed sizes in my profiles nor in the startup scripts which do have a purge line in them.
    3. The startup script has a purge line however it is not going outside the specified print bed dimension:
    G1 X0.0 Y15.0 F3000.0 ; Move the nozzle to bottom left corner
    G1 Z0 ; Move nozzle to print height
    G1 X0.1 Y20 F5000.0 ; move to start-line position
    G1 X0.1 Y200.0 F1500.0 E15 ; draw 1st line
    G1 X0.4 Y200.0 F5000.0 ; move to side a little
    G1 X0.4 Y20 F1500.0 E30 ; draw 2nd line

    So realistically there should be no reason for me to get this error message. 





  • At least what you show shows no reason for it. If you go to 2d preview you see on the right side what server thinks is the dimension of the print. Please check that. If that also fits please post the .gin file to the gcode

    On linux you find it in /var/lib/Repetier-Server/printer/<printer slug>/models

    Interesiting part is this:

    xMax: 117.88700103759766

    xMaxMove: 115.697998046875

    xMin: 83.34300231933594

    xMinMove: 0

    yMax: 128.48399353027344

    yMaxMove: 210

    yMin: 71.63999938964844

    yMinMove: 73.0479965209961

    zMax: 15.949999809265137

    zMin: 0


    The move limits are new in 0.92 so might not exist for old gcodes.

  • So i checked on the 2D preview and again there is no reason for this error. See screenshot below:



    I also checked the corresponding .gin file which shows the following info at the end. 

    xMax: 180.9720001220703
    xMaxMove: 175.40899658203125
    xMin: 0.10000000149011612
    xMinMove: 0
    yMax: 200
    yMaxMove: 363.1159973144531
    yMin: 20
    yMinMove: 15
    zMax: 28.479999542236328
    zMin: 0 

    From what i can tell the yMAXMove indicates a movement that would be out of bounds for the printer so i guess this would be the reason for the message however based on the slicer settings and the printer settings in repetier server and also the 2D preview this value should not even be possible. To me this seems like an error in this new feature somehow?
  • I sliced another new model for printing and i checked again the 2D preview and the .gin file. It seems no matter the model the yMaxMove seems to be out of bounds in the .gin file for whatever reason that is causing this error.



    xMax: 162.99400329589844
    xMaxMove: 157.4720001220703
    xMin: 0.10000000149011612
    xMinMove: 0
    yMax: 200
    yMaxMove: 346.8809814453125
    yMin: 20
    yMinMove: 15
    zMax: 52.63999938964844
    zMin: 0 
  • Yes, looks like yMaxMove: 363.1159973144531 is the problem here. You could search gcode for 363.1 or 346.8 to see if it is contained. Server agrees that printing is in allowed range but it looks like somehow a move to high y values is included for what ever reason.

    Also if you upload same file multiple times is it always same yMaxMove for same gcode? If not it would be a server problem with uninitialized variable. If always the same it comes from a command in gcode.
  • I uploaded the same gcode file twice to repetier server. GIN file for both uploads shows the same yMaxMove:

    Upload 1: yMaxMove: 348.64501953125
    Upload 2: yMaxMove: 348.64501953125

    When i look in the source gcode there is no mention anywhere of this value. So its not comming from the GCODE and repeated uploads generate the same yMaxMove value in the gin file.

  • Can you post the gcode or a different one with same problem along with the exported printer configuration xml so I can test. My uploads so far did not have the problem so would like to know what is causing the problem. Could also be a simple command. G28 for example adds the homing position to moved positions, but that is 0,0,0 so not the problem.
Sign In or Register to comment.