sizing help - when printed box completely looses corners

[c310]

Hi! I'm trying to print enclosure for easter egg bot and there is something i cannot resolve: when printing my delta "bites" coreners and it looks like giant bevel.

enclosure size is 134mm.
my bed is 220mm in diameter
in config.g i sized down B parametr a bit, so that smarteffector does not hit belts

M665 R102 L288.17 B90 H152		; set delta radius, diagonal rod length, printable radius and homed height 

Original idea (bottom is removed on purpose)

what really happens : edges are gone, walls are shifted to the center

[Stephen6309]

Looks to me the bed isn't big enough. What's distance from corner to corner? (geometery class was too long ago)

[c310]

square is 134 * 94 , diagonal 158, all millimetres

[themelle]

Seems to me like you're hitting the limits of the printable area.
Is this a brim you're printing around your object?
Or does this extended area belong to the model itself?
If it's a brim you might try printing without ...

Also, 134x94mm should be around 163.7mm diagonally

[dc42]

It looks to me that you are hitting the bed radius limit. But that shouldn't happen because the radius you need is 164mm and you have specified 180mm (2 * 90). So:

1. Check your config-override.g file, in case it contains a M665 command with a smaller B parameter.

2. Does your delta print large shapes with accurate sizes? For example, if you print a 120mm square on it, do the sides come out straight and close to 120mm long?

[c310]

@dc42 thank you for the hint... Yes, that was in config-override.g

In my opinion, config-override should have ONLY computed parameters (one that are changed automatically based on calibration: delta and temperature)

even more, header of config-override states "do not edit"

This is a system-generated file - do not edit

I see no way that safe printing radius is changed by calibration heatbed cannot neither grow nor shrink.

So, my suggestion is to remove m665 B parameter from config-override there is no sense.
@dc42 what do you think?!

thanks!

[dc42]

Yes we could remove the B parameter. But then we should also remove other parameters that haven't been changed by calibration. Then the firmware would have to remember whether the rod lengths, bed tilt, delta radius etc. have been adjusted by calibration (which depends on how many calibration factors yolu used) OR were read from a previous M665 command in config-override.g.

A possible reason not to remove the B parameter is that some people save the parameters with M500 and then copy the M665 and M666 commands from config-override.g to config.g.

Comments, anyone?

[deckingman]

@dc42 I don't have a delta nor do I know much about them but, I'd have thought that if the B parameter isn't present in config-overide.g, then it needs to be present in config.g (or somewhere else at least). So one would end up with two separate M665 commands, each one having one or more parameters that the other instance does not have. If a change needs to be made at some point in the future, one would need to remember in where each of the commands exists.

The OP has discovered that having the same command in two different locations can lead to confusion, so I'd have that having two different instances of that command, each with one or more parameters that the other does not have, would merely increase the risk of confusion.

[bot]

@deckingman I agree. The config-override thing is a weird feature brought over from ancient firmwares. The confusion is already there. Keep the confusion consistent.

Users should decide if they will be using config-override or not. If they choose to use it, then use it. Set all parameters with G codes in console and then save them with M500. If you want to start manually editing config.g -- DON'T USE CONFIG-OVERRIDE!

The problems only arise when people start poking around the files themselves without being fully aware of what is located where.

[deckingman]

@bot Well actually, I don't use config-override.g at all - nor will I ever. I know why it was introduced and I guess it saves doing a copy and paste, but I'd rather have all my setting in one place so it's not for me.

[bot]

@deckingman I agree with that too!

One thing I don't want is for David to waste too much time working on "improvements" to "features" like this which were introduced for people who are essentially unwilling to learn new ways of doing things on modern systems.

[deckingman]

@bot You could be right but it's not for me to say how anyone else should manage their system and files. We both think that not using config-overide.g is a better approach but I wouldn't propose that we should should force that way of doing things on everyone else. The override file was introduced to emulate writing to non-volatile memory and like most things, it stemmed from user requests so.....

[bot]

@deckingman Sure! I agree, let them use config-override. It already works! Why mess with it. My thoughts were in response to David seeking input as to whether the functionality should be changed. I think not. It's consistent as it is. Input gcode into console. Like the change? Send M500. End of story. Do not open config.g to edit it if you are using config-override.

[Phaedrux]

@deckingman @bot I think where a system like config-override to save computed values is useful is in the context of say an OEM situation where the end user and the system designer are not the same person. Having a macro that automates a calibration process means needing a way to permanently store those computed values. Since the firmware can't edit config.g and there is no eeprom, we're left with a secondary macro that the system can overwrite.

[c310]

@phaedrux said in sizing help - when printed box completely looses corners:

system like config-override to save computed values is useful is in the context of say an OEM situation

i agree. config-override in current implementation is a kind of storage for calibrated values. in theory it can be renamed to 'calibration_data.csv' (similar to mesh bed file)

my call was to make software architecture consistent and keep calibration data in config-override, separating it form values that calibration can not change. B parameter (bed size) is one of those user-defined values that system can not change, thus it should go to config.g

[deckingman]

@c310 That seems like a valid approach. Although it does leave situation where one could have two instances of a command in two different places, each instance having some parameters that the other instance does not have. This in itself could lead to misunderstanding and confusion.

Perhaps a better approach (and I have no idea if this is possible) might be to split the "calibration generated" parameters from the "non-calibration generated" parameters into two separate gcodes, the intention being that the former would reside in the override file (if the user chooses to use it) and the latter would reside in config.g. This would avoid the possibility of having two instances of the same gcode command.

I doubt that David will find a compromise that will suit everyone but as things stand, users have the choice whether to use config-override or not, so whichever solution he chooses isn't likely to be a huge upset. If he does find an acceptable compromise, maybe he can solve the Brexit impasse that our politicians have created

[c310]

@deckingman said in sizing help - when printed box completely looses corners:

Perhaps a better approach (and I have no idea if this is possible) might be to split the "calibration generated" parameters from the "non-calibration generated" parameters into two separate gcodes,

that exactly i was talking about: keep all commands in config.g and all calibration data (not commands) in config-override
also auto-calibration should not modify and/or add non-calibrated options and parameters.

firmware scenario than will be:

1. read config.g to memory
2. append and replace data from config-override (or from calibration_data.csv to avoid misunderstanding) to memory
3. enjoy the print

[deckingman]

@c310 You did slightly mis-quote me there by omitting the "into two separate gcodes,". That's a fairly important part of the point I was trying to make, as it would negate the need for duplicate commands.

[c310]

@deckingman added that important part