-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
STL and gcode for standard models on SD card #74
Comments
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>
.
|
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)
|
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>
.
|
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)
|
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 😄 |
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.
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 😄 ) |
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.
|
(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) |
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.
The text was updated successfully, but these errors were encountered: