STL and gcode for standard models on SD card

[veng1]

Would it be useful to include a few "standard" models with gcode in the repo to allow users to compare calibration and issues on less than ideal prints?

There seems to be a plethora of different tests that people are trying and it often appears that it may simply be a difference in how they were sliced or maybe not the best ones for tracking down a specific issue.

[kraegar]

We looked at it, but we'd have to do parts for the kit with absolutely no changes. What we keep running into is every hotend / bed / shroud combo makes it so a pre-sliced print only works on your specific printer. So they're not very universal. Even something like changing your bed surface throws it off entirely... and no one seems to build the kit w/o any changes at all.

…

On Fri, Jun 14, 2019 at 9:37 AM veng1 ***@***.***> wrote: Would it be useful to include a few "standard" models with gcode in the repo to allow users to compare calibration and issues on less than ideal prints? There seems to be a plethora of different tests that people are trying and it often appears that it may simply be a difference in how they were sliced or maybe not the best ones for tracking down a specific issue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#74?email_source=notifications&email_token=ABYQQ47BDMX3ZHLBPFO55BDP2ONIZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZR4FHQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYQQ45Z2KJOEH7BQ6AD3JTP2ONIZANCNFSM4HYH6NOQ> .

[veng1]

Ha.  I don't know why anyone would build a Railcore with no changes. But it does seem like there could be at least .stl files and then the slicer configs in another spot.  Once the printer is built is when the really hard work begins and at that point the community tries to help but it's a little hit or miss the way it is now.  I'm not sure of a solution but I see many people trying to tune that are having problems.  So it appears that an agreed upon "standard" calibration files or procedure would get people moving in the right direction.  I don't think a Benchy is the best approach although it hits a lot of problems, they are not isolated. Although I'm sure you probably don't remember, we spoke at MRRF but you were pretty busy.  My background is designing and manufacturing things that are built typically by relatively unskilled workers but they need to go together without errors.  So I tend to think in "process" and then process improvement.  The process right now requires more skill than many or the users seem to have.  That's not a criticism, just an observation.

…

On 6/17/2019 8:41 AM, kraegar wrote: We looked at it, but we'd have to do parts for the kit with absolutely no changes. What we keep running into is every hotend / bed / shroud combo makes it so a pre-sliced print only works on your specific printer. So they're not very universal. Even something like changing your bed surface throws it off entirely... and no one seems to build the kit w/o any changes at all. On Fri, Jun 14, 2019 at 9:37 AM veng1 ***@***.***> wrote: > Would it be useful to include a few "standard" models with gcode in the > repo to allow users to compare calibration and issues on less than ideal > prints? > > There seems to be a plethora of different tests that people are trying and > it often appears that it may simply be a difference in how they were sliced > or maybe not the best ones for tracking down a specific issue. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#74?email_source=notifications&email_token=ABYQQ47BDMX3ZHLBPFO55BDP2ONIZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZR4FHQ>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABYQQ45Z2KJOEH7BQ6AD3JTP2ONIZANCNFSM4HYH6NOQ> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#74?email_source=notifications&email_token=ABPT7OPX7ZL472BJW5YWC3TP26BAZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3BIMI#issuecomment-502666289>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPT7OK6VUNA33CHW3VSCKLP26BAZANCNFSM4HYH6NOQ>.

-- Patrick H. Ryan, Jr. President Venture Engineering Corporation 770-604-9677 404-580-2568 (Mobile)

[kraegar]

I agree. It's just something we haven't figured out the best approach to yet. Another complication I remembered is that if folks use a slice hotend or an e3d, both are options in the kit. A slice hotend will jam 100% of the time with e3d retraction settings. It's a lot of variables to account for.

…

On Mon, Jun 17, 2019 at 9:17 AM veng1 ***@***.***> wrote: Ha. I don't know why anyone would build a Railcore with no changes. But it does seem like there could be at least .stl files and then the slicer configs in another spot. Once the printer is built is when the really hard work begins and at that point the community tries to help but it's a little hit or miss the way it is now. I'm not sure of a solution but I see many people trying to tune that are having problems. So it appears that an agreed upon "standard" calibration files or procedure would get people moving in the right direction. I don't think a Benchy is the best approach although it hits a lot of problems, they are not isolated. Although I'm sure you probably don't remember, we spoke at MRRF but you were pretty busy. My background is designing and manufacturing things that are built typically by relatively unskilled workers but they need to go together without errors. So I tend to think in "process" and then process improvement. The process right now requires more skill than many or the users seem to have. That's not a criticism, just an observation. On 6/17/2019 8:41 AM, kraegar wrote: > We looked at it, but we'd have to do parts for the kit with absolutely no > changes. What we keep running into is every hotend / bed / shroud combo > makes it so a pre-sliced print only works on your specific printer. So > they're not very universal. Even something like changing your bed surface > throws it off entirely... and no one seems to build the kit w/o any > changes > at all. > > On Fri, Jun 14, 2019 at 9:37 AM veng1 ***@***.***> wrote: > > > Would it be useful to include a few "standard" models with gcode in the > > repo to allow users to compare calibration and issues on less than ideal > > prints? > > > > There seems to be a plethora of different tests that people are > trying and > > it often appears that it may simply be a difference in how they were > sliced > > or maybe not the best ones for tracking down a specific issue. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > > < #74?email_source=notifications&email_token=ABYQQ47BDMX3ZHLBPFO55BDP2ONIZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZR4FHQ >, > > or mute the thread > > > < https://github.com/notifications/unsubscribe-auth/ABYQQ45Z2KJOEH7BQ6AD3JTP2ONIZANCNFSM4HYH6NOQ > > > . > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > < #74?email_source=notifications&email_token=ABPT7OPX7ZL472BJW5YWC3TP26BAZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3BIMI#issuecomment-502666289>, > or mute the thread > < https://github.com/notifications/unsubscribe-auth/ABPT7OK6VUNA33CHW3VSCKLP26BAZANCNFSM4HYH6NOQ >. > -- Patrick H. Ryan, Jr. President Venture Engineering Corporation 770-604-9677 404-580-2568 (Mobile) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#74?email_source=notifications&email_token=ABYQQ4Z7D7O524KYMTEWTJLP26FE7A5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3EDSY#issuecomment-502677963>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYQQ47YOCRDZGHZXAMJ4HLP26FE7ANCNFSM4HYH6NOQ> .

[veng1]

Yes, there are a lot of variables. But there are two different issues.  One is a set of stl files that are a baseline for calibration.  And then there are slicer recommendations or configurations.  Neither may be perfect on day one or maybe ever. The first maxim of process improvement is " You can't improve what you can't measure".

…

On 6/17/2019 9:19 AM, kraegar wrote: I agree. It's just something we haven't figured out the best approach to yet. Another complication I remembered is that if folks use a slice hotend or an e3d, both are options in the kit. A slice hotend will jam 100% of the time with e3d retraction settings. It's a lot of variables to account for. On Mon, Jun 17, 2019 at 9:17 AM veng1 ***@***.***> wrote: > Ha. I don't know why anyone would build a Railcore with no changes. > > But it does seem like there could be at least .stl files and then the > slicer configs in another spot. Once the printer is built is when the > really hard work begins and at that point the community tries to help > but it's a little hit or miss the way it is now. I'm not sure of a > solution but I see many people trying to tune that are having problems. > So it appears that an agreed upon "standard" calibration files or > procedure would get people moving in the right direction. I don't think > a Benchy is the best approach although it hits a lot of problems, they > are not isolated. > > Although I'm sure you probably don't remember, we spoke at MRRF but you > were pretty busy. My background is designing and manufacturing things > that are built typically by relatively unskilled workers but they need > to go together without errors. So I tend to think in "process" and then > process improvement. The process right now requires more skill than > many or the users seem to have. That's not a criticism, just an > observation. > > > On 6/17/2019 8:41 AM, kraegar wrote: > > We looked at it, but we'd have to do parts for the kit with absolutely no > > changes. What we keep running into is every hotend / bed / shroud combo > > makes it so a pre-sliced print only works on your specific printer. So > > they're not very universal. Even something like changing your bed surface > > throws it off entirely... and no one seems to build the kit w/o any > > changes > > at all. > > > > On Fri, Jun 14, 2019 at 9:37 AM veng1 ***@***.***> wrote: > > > > > Would it be useful to include a few "standard" models with gcode in the > > > repo to allow users to compare calibration and issues on less than > ideal > > > prints? > > > > > > There seems to be a plethora of different tests that people are > > trying and > > > it often appears that it may simply be a difference in how they were > > sliced > > > or maybe not the best ones for tracking down a specific issue. > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > > > < > #74?email_source=notifications&email_token=ABYQQ47BDMX3ZHLBPFO55BDP2ONIZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GZR4FHQ > >, > > > or mute the thread > > > > > < > https://github.com/notifications/unsubscribe-auth/ABYQQ45Z2KJOEH7BQ6AD3JTP2ONIZANCNFSM4HYH6NOQ > > > > > . > > > > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > < > #74?email_source=notifications&email_token=ABPT7OPX7ZL472BJW5YWC3TP26BAZA5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3BIMI#issuecomment-502666289>, > > > or mute the thread > > < > https://github.com/notifications/unsubscribe-auth/ABPT7OK6VUNA33CHW3VSCKLP26BAZANCNFSM4HYH6NOQ > >. > > > > -- > Patrick H. Ryan, Jr. > President > Venture Engineering Corporation > 770-604-9677 > 404-580-2568 (Mobile) > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#74?email_source=notifications&email_token=ABYQQ4Z7D7O524KYMTEWTJLP26FE7A5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3EDSY#issuecomment-502677963>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABYQQ47YOCRDZGHZXAMJ4HLP26FE7ANCNFSM4HYH6NOQ> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#74?email_source=notifications&email_token=ABPT7OM54HYUZB23KZMEAXTP26FP7A5CNFSM4HYH6NO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX3EMEA#issuecomment-502679056>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPT7OMRKNU36MKJMKZIDC3P26FP7ANCNFSM4HYH6NOQ>.

-- Patrick H. Ryan, Jr. President Venture Engineering Corporation 770-604-9677 404-580-2568 (Mobile)

[natewalck]

Perhaps there could be a slice for E3D v6 and a slice for Mosquito? Those should cover most hotends (E3D should work fine for Volcano too so long as nozzle diameter is the same).

Has to be some way to get it done 😄

[dandancheeseandham]

Here is the approach that I think would work.

The sliced test object file, and two other files - I'll use example paths and names.

i) /sys/filament/PLA-start.g - this file contains the home, level, bed and nozzle temp that would be in your intro code in your slicer, as well as firmware retraction all nicely commented for the user.
e.g.

;; Macro to be called at the start of a print for PLA

M207 S1.8 F4800 Z0.18  ; Firmware Retraction 1.8mm , speed 80m/s , Z-hop 0.18
M190 S35 ; Set and wait for bed temp to rise
M561     ; Clear bed transforms
G28 X Y
G28 Z    ; Home Z
G32      ; Level Bed 1
G28 Z    ; Home Z
G32      ; Level Bed 2
G28 Z    ; Home Z
G32      ; Level Bed 3
G28 Z ; Home Z
M104 S195 T0 ; Raise hot-end temp to profile requested hot-end layer 1 temp
M109 S195 T0 ; Wait for hot-end temp to rise to profile requested hot-end layer 1 temp

ii) /sys/filament/PLA-cooling.g - this file is simply the M106 with the right amount of cooling for the fan, to be engaged after layer 4-6. ~25% for kits by default.

iii) The test object file is sliced with M98 P"/sys/filament/PLA-start.g" called at the start, firmware retraction on and M98 P"/sys/filament/PLA-cooling.g" called at layer 4-6.

(If you really think there are people with 3mm filament, then we can even switch to volumetric extrusion and include M200 in the start.g 😄 )

[dandancheeseandham]

Bonus points for directing the user to include a stop.g in /sys/ and having an M0 at the end of the G-code 😄

e.g.

; stop.g
; run when a print finishes normally with an M0 command at the end of the print job.
;

G91 G1 E-1.0 F1000.0 ;  retract
G91 G1 Z50
M400                    ; wait for moves to complete
M140 S-273               ; turn off bed
M106 S0                  ; cooling fan off
M84 E0:1                 ; extruders off
G10 P0 R-273.15 S-273.15 ; Turn off tool heaters
T-1                      ; deactivate current tool

[dandancheeseandham]

(ofc, you could go the route of not making them different files, and just have it all in one monolithic test file, with instructions to suit)