WHO is working on which bugs?

[boelle]

are any of the collabs and coders working on any of the bugs? just so i can put an assing to them so we dont have 2 working on the same thing

[daid]

Note, I'm not actively working on any bugs. But you can always "ping" me for information, I know a lot of details about the Marlin code, and I have a lot of ideas on how things should and should not be done.

[boelle]

i thinkt its @thinkyhead that suggested to do code sprints and a cleanup of the code...

am i wrong in pursuing that we get bugs fixed first before doing anything else?

some have expressed their feelings on the code that its way to complicated to navigate, and stupid me is just the resident house elf :-(

[thinkyhead]

I'm happy to keep fixing bugs, especially the confirmed ones that I can comprehend. I'd put the bugs towards the top of the list over new features. And where it's possible to update things to newer code, I'm into that too. (For example, patching the code to use the latest SDFat beta.)

As previously suggested, collaborators should definitely assign themselves, and others should leave a comment if they intend to fix a bug and submit a patch.

[thinkyhead]

#1226 #1227

[boelle]

been working on a order printer for local pizza delivery... but that is almost done... ordered a new 644P chip for one set of printer electronics i have...

its the OMC electronics i also uploaded bootloader etc for... will start testing once i get the chip...

while at it should there not be a testing procedure of some sorts so that the tester can tick of steps? of course my 644p based eletronics will not have a long list compared to other electronics..

[thinkyhead]

@nophead has some 644p experience.

[boelle]

removed the lock on this one... nophead replied in mail:

If you are replacing it you might as well fit a 1284p as they are pin compatible.

which i think i will... or have both around

will study the differences, but what are the "highlights" ?

@thinkyhead want to give your web config tool a go, any chance you can add OMC to the list of boards? there should also be some almost spot on example configs in /tvrrug/Round2

[nophead]

Twice as much flash, twice as much EEPROM and four times the RAM.

[thinkyhead]

@boelle Is the "OMC" board very similar to the OMCA or OMCA_A boards currently defined? (i.e., Are the pins nearly identical?) I will add it to the list once I know more.

My configurator is (so far) just an alternative way to edit the configuration files, which it is able to grab directly from GitHub, but I will soon be making some addtional helpful changes.

• Find all configurations in the GitHub repo and show them in a popup menu
• Add more tabs with fewer options in each

[boelle]

About OMC.... partly yes..... it tells about the main board but not the DSM
that goes with it. that is a board that with stepper drivers and FET...
that is the mai n reason i uploaded the example config as there is a single
line that tells to use those... they use toshiba steppers. also i can link
to a 2-3 year old copy that works with the board

will do that later, still in bed and snozze mode

Den lørdag den 7. marts 2015 skrev Scott Lahteine <notifications@github.com

:

@boelle https://github.com/boelle Is the "OMC" board very similar to
the OMCA or OMCA_A boards currently defined? (i.e., Are the pins nearly
identical?) I will add it to the list once I know more.

My configurator http://www.thinkyhead.com/_marlin is (so far) just an
alternative way to edit the configuration files, which it is able to grab
directly from GitHub, but I will soon be making some addtional helpful
changes.

• Find all configurations in the GitHub repo and show them in a popup
  menu
• Add more tabs with fewer options in each

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

about configurator.... will that one also limit displayed options depending
on what board is picked?

Den lørdag den 7. marts 2015 skrev Scott Lahteine <notifications@github.com

:

@boelle https://github.com/boelle Is the "OMC" board very similar to
the OMCA or OMCA_A boards currently defined? (i.e., Are the pins nearly
identical?) I will add it to the list once I know more.

My configurator http://www.thinkyhead.com/_marlin is (so far) just an
alternative way to edit the configuration files, which it is able to grab
directly from GitHub, but I will soon be making some addtional helpful
changes.

• Find all configurations in the GitHub repo and show them in a popup
  menu
• Add more tabs with fewer options in each

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

link to that old copy of marlin:
https://github.com/buserror/Marlin/tree/master/Marlin

line 80 in configuration.h: #define CONFIG_STEPPERS_TOSHIBA 1

about whatever to use BOARD_OMCA or BOARD_OMCA_A i looked at the old copy
of marlin just before we moved the repro

BOARD_OMCA 91 // Final OMCA board

2015-03-07 1:27 GMT+01:00 Scott Lahteine notifications@github.com:

@boelle https://github.com/boelle Is the "OMC" board very similar to
the OMCA or OMCA_A boards currently defined? (i.e., Are the pins nearly
identical?) I will add it to the list once I know more.

My configurator http://www.thinkyhead.com/_marlin is (so far) just an
alternative way to edit the configuration files, which it is able to grab
directly from GitHub, but I will soon be making some addtional helpful
changes.

• Find all configurations in the GitHub repo and show them in a popup
  menu
• Add more tabs with fewer options in each

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[thinkyhead]

@boelle I actually added that TOSHIBA line to all the configurations, just so we know it's there. I look forward to seeing the config and pins files that worked for you 2-3 years thence.

The configurator as I've built it so far knows very little about the configuration files when it first loads. It parses the files to determine what kinds of values the defines contain, which defines enable and disable other defines, which defines are similarly-named so they can be grouped, etc. The only annotations in my modified configuration files are // @section some_section comments to assign sections to settings, and // :{0:'Off',1:'On'} comments that contain the legal values for some fields (in JSON format).

So, no, it doesn't hide any options based on the selected board at this time. In order to do so (without adding any expert knowledge to the configurator) we would need add more #if blocks to the configuration, directly expressing these dependencies. But we shouldn't base dependencies on the MOTHERBOARD value. Instead options should be available (or not) based on what is defined in the board's pins file.

So, I could add some expert knowledge to the app, such as which defines represent heaters, motors, extruders, and endstops, then only allow as many as the board can support, conceal the options it doesn't support, etc. That information could be added to the configuration files as annotations, or it may come in some other form.

There are two tasks I want to complete in the configurator before I get to that. First is to get "overrides" sorted out – that's every repeated occurrence of a define after the first one (always inside #if blocks). When an option is enabled that activates a block of code with one of these overrides, I have to catch that, make its field uneditable and display the overridden value. I'm about an hour from having that working. The second thing I need to do is make a data-dump of all this extracted information and figure out interesting ways to utilize it.

[boelle]

everything should be in that git link... did you not get it?

2015-03-07 9:45 GMT+01:00 Scott Lahteine notifications@github.com:

@boelle https://github.com/boelle I actually added that TOSHIBA line to
all the configurations, just so we know it's there. I look forward to
seeing the config and pins files that worked for you 2-3 years thence.

The configurator as I've built it so far knows very little about the
configuration files when it first loads. It parses the files to determine
what kinds of values the defines contain, which defines enable and disable
other defines, which defines are similarly-named so they can be grouped,
etc. The only annotations in my modified configuration files are //
@section some_section comments to assign sections to settings, and //
:{0:Off,1:On} comments that contain the legal values for the field (in
JSON format).

So, no, it doesn't hide any options based on the selected board at this
time. In order to do so (without adding any expert knowledge to the
configurator) we would need add more #if blocks to the configuration,
directly expressing these dependencies. But we shouldn't base dependencies
on the MOTHERBOARD value. Instead options should be available (or not)
based on what is defined in the board's pins file.

So, I could add some expert knowledge to the app, such as which defines
represent heaters, motors, extruders, and endstops, then only allow as many
as the board can support, conceal the options it doesn't support, etc. That
information could be added to the configuration files as annotations, or it
may come in some other form.

There are two tasks I want to complete in the configurator before I get to
that. First is to get "overrides" sorted out – that's every repeated
occurrence of a define after the first one (always inside #if blocks).
When an option is enabled that activates a block of code with one of these
overrides, I have to catch that, make its field uneditable and display the
overridden value. I'm about an hour from having that working. The second
thing I need to do is make a data-dump of all this extracted information
and figure out interesting ways to utilize it.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

heheh... no worries... the idea for the configurator was just a thought....
given that the 644 is rather limited i just thought why display options it
cant support anyway...

let me know if you did not get the pins file etc

2015-03-07 9:45 GMT+01:00 Scott Lahteine notifications@github.com:

@boelle https://github.com/boelle I actually added that TOSHIBA line to
all the configurations, just so we know it's there. I look forward to
seeing the config and pins files that worked for you 2-3 years thence.

The configurator as I've built it so far knows very little about the
configuration files when it first loads. It parses the files to determine
what kinds of values the defines contain, which defines enable and disable
other defines, which defines are similarly-named so they can be grouped,
etc. The only annotations in my modified configuration files are //
@section some_section comments to assign sections to settings, and //
:{0:Off,1:On} comments that contain the legal values for the field (in
JSON format).

So, no, it doesn't hide any options based on the selected board at this
time. In order to do so (without adding any expert knowledge to the
configurator) we would need add more #if blocks to the configuration,
directly expressing these dependencies. But we shouldn't base dependencies
on the MOTHERBOARD value. Instead options should be available (or not)
based on what is defined in the board's pins file.

So, I could add some expert knowledge to the app, such as which defines
represent heaters, motors, extruders, and endstops, then only allow as many
as the board can support, conceal the options it doesn't support, etc. That
information could be added to the configuration files as annotations, or it
may come in some other form.

There are two tasks I want to complete in the configurator before I get to
that. First is to get "overrides" sorted out – that's every repeated
occurrence of a define after the first one (always inside #if blocks).
When an option is enabled that activates a block of code with one of these
overrides, I have to catch that, make its field uneditable and display the
overridden value. I'm about an hour from having that working. The second
thing I need to do is make a data-dump of all this extracted information
and figure out interesting ways to utilize it.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

btw... not sure if this helps or not but here are the hardwarte design
files for OMC and DSM

http://solderpad.com/folknology/open-motion-controller/

http://solderpad.com/folknology/dual-stepper-motor-module/

2015-03-07 9:45 GMT+01:00 Scott Lahteine notifications@github.com:

@boelle https://github.com/boelle I actually added that TOSHIBA line to
all the configurations, just so we know it's there. I look forward to
seeing the config and pins files that worked for you 2-3 years thence.

The configurator as I've built it so far knows very little about the
configuration files when it first loads. It parses the files to determine
what kinds of values the defines contain, which defines enable and disable
other defines, which defines are similarly-named so they can be grouped,
etc. The only annotations in my modified configuration files are //
@section some_section comments to assign sections to settings, and //
:{0:Off,1:On} comments that contain the legal values for the field (in
JSON format).

So, no, it doesn't hide any options based on the selected board at this
time. In order to do so (without adding any expert knowledge to the
configurator) we would need add more #if blocks to the configuration,
directly expressing these dependencies. But we shouldn't base dependencies
on the MOTHERBOARD value. Instead options should be available (or not)
based on what is defined in the board's pins file.

So, I could add some expert knowledge to the app, such as which defines
represent heaters, motors, extruders, and endstops, then only allow as many
as the board can support, conceal the options it doesn't support, etc. That
information could be added to the configuration files as annotations, or it
may come in some other form.

There are two tasks I want to complete in the configurator before I get to
that. First is to get "overrides" sorted out – that's every repeated
occurrence of a define after the first one (always inside #if blocks).
When an option is enabled that activates a block of code with one of these
overrides, I have to catch that, make its field uneditable and display the
overridden value. I'm about an hour from having that working. The second
thing I need to do is make a data-dump of all this extracted information
and figure out interesting ways to utilize it.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[thinkyhead]

Weird… I see that the pins file includes MOTHERBOARD 91 (OMCA) and one of the pins has been altered, but https://github.com/buserror/Marlin/blob/master/Marlin/Configuration.h is specifying MOTHERBOARD 7 - which is the default, Ultimaker.

[boelle]

yep.... i saw that one 2....

and then the 2 sample config files i have uploaded are from users of the
same board...

so i have emailed http://tvrrug.org.uk/ and asked which copy of marlin and
where it is....

2015-03-07 10:15 GMT+01:00 Scott Lahteine notifications@github.com:

Weird… I see that the pins file includes MOTHERBOARD 91 (OMCA) and one of
the pins has been altered, but
https://github.com/buserror/Marlin/blob/master/Marlin/Configuration.h is
specifying MOTHERBOARD 7 - which is the default, Ultimaker.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[thinkyhead]

As far as I can see, the example_configurations seem pretty close… So are the OMCA and OMCA_A configs basically untested, or are they known to work?

[boelle]

ohh now i remember.... motherboard 7 is the default when the repro was
forked.....

let me double check their documentation

2015-03-07 10:15 GMT+01:00 Scott Lahteine notifications@github.com:

Weird… I see that the pins file includes MOTHERBOARD 91 (OMCA) and one of
the pins has been altered, but
https://github.com/buserror/Marlin/blob/master/Marlin/Configuration.h is
specifying MOTHERBOARD 7 - which is the default, Ultimaker.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

the same configs are working copies... that much i know

2015-03-07 10:20 GMT+01:00 Scott Lahteine notifications@github.com:

As far as I can see, the example_configurations seem pretty close… So are
the OMCA and OMCA_A configs basically untested, or are they known to work?

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

Round 2 changes: There are 2 changes you need to make to configuration.h
for Round 2:

1. line 35: change the MOTHERBOARD value to 91 - #define MOTHERBOARD 91
2. line 184: change steps per mm for X and Y axis to 71.1 - #define
   DEFAULT_AXIS_STEPS_PER_UNIT {71.1, 71.1, 2560, 599.14} // Michel TVRR

so the one in their fork is simply marlin default at the time they made the
fork and did not bother to change it to 91

2015-03-07 10:15 GMT+01:00 Scott Lahteine notifications@github.com:

Weird… I see that the pins file includes MOTHERBOARD 91 (OMCA) and one of
the pins has been altered, but
https://github.com/buserror/Marlin/blob/master/Marlin/Configuration.h is
specifying MOTHERBOARD 7 - which is the default, Ultimaker.

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[boelle]

i also made an attempt to upload the bootloader for this so its there....

my plan for this was to support their machines and electronics out the box
so people would only have one stop to get it all

also makes it a tad more easy for us to update things

2015-03-07 10:20 GMT+01:00 Scott Lahteine notifications@github.com:

As far as I can see, the example_configurations seem pretty close… So are
the OMCA and OMCA_A configs basically untested, or are they known to work?

—
Reply to this email directly or view it on GitHub
#1354 (comment)
.

[scotty1024]

Modify Marlin to support DGlass3D HPX extruders (#1559) <- Mine

Please advise if I need to update anything else to claim this bug number.

On Mar 11, 2015, at 2:37 AM, Bo Herrmannsen notifications@github.com wrote:

Closed #1354.

—
Reply to this email directly or view it on GitHub.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.