Beta of latest Marlin_V1 w/ Solidoodle Patches (Oct-13) (All Boards) (Page 1 of 4)

Thanks for the hard work!

Outstanding work!

Most people will have no idea the time and effort you've put into this. I can only hope you're building up some 3D printing karma that will reward you in some way in the future.

Adrian,

Just tried to compile with ZWOBBLE_PATCH enabled but get the following error with Sanguinololu.

Any ideas?

planner.cpp: In function 'void plan_buffer_line(const float&, const float&, const float&, const float&, float, const uint8_t&)':
planner.cpp:533: error: 'zwobble' was not declared in this scope

Just happy to be of help all

My bad, I committed the wrong planner.cpp file.

Redownload the source-code, download the planner.cpp file, or add to your local copy from Line 60:

#ifdef ZWOBBLE_PATCH
  #include "ZWobble.h" //{SD Patch}
#endif
#ifdef HYSTERESIS_PATCH
  #include "Hysteresis.h" //{SD Patch}
#endif

Apologies about that!

Hazer - Thanks very much for testing. Means we now have a unified firmware at least, different firmware update methods not withstanding...

Hey Hazer; thanks for the feedback, appreciate it.

Quick responses to your points right now:

1: Cool! Loads of bugfixes and improvements as a result of the delta code have occured in mainstream-marlin
2: I'll have to check it out further. Not having a printrboard immeadiately handy, I'll have to take that away and investigate it further on the weekend for you. It shouldn't be too much of a drama to get some alignment. 
3: Yes, but I have pulled it from *this release* as I'm going to realign it to work with some newer/different functions. I basically have 'backed the wrong horse' on some M600 patches a few months back, and rather than continue to try and beat it into submission, I'm going to refactor my code to work with the 'as adopted' M600 patches... Blah... but once its aligned, I'll let it soak for a few weeks then submit it upstream. The original is still there under the _M600 branch... but I'll patch this branch with the newer code in next few days.
4: I'll have a few things in next few days you can test

Hazer , good news!!
I *think* i've got the Onboard SD sorted out, and can explain how the pinmappings working.

Redownload the firmware from https://github.com/ozadr1an/Solidoodle- … in_v1_beta and enable SD Card support. Compile and upload that to the board.

Now - the Y-Endstop on the Printrboard, for whatever reason, is wired to the *hardware* SS port on the at90usb.. which means when this pin changes state the sd library is coded to pull an interrupt - this is what you would have read about elsewhere... it *may* not be a problem now, or it may be. So during this testing, be prepared to test accessing hte SD card with the Y-axis both homed and 'not homed'.... If it proves to continue to interfere, we can swap across to the E-stop pins..

Ok, so to test, you should be able to upload a file to the SD card via repetier host using the sd-card 'upload' command... you should also be able to list files etc. make sure to keep them '8.3' such as 'yoda.gco'.

With regard to the pin mapping, yeah its a mess, but its not entirely the fault of any one particular person.

Whats happening is some parts of marlin are referencing the fastio.h pin mapping, which is bound to a map defined in that file and loosely based on atmega 'arduino' pins, and that goes to the PortXXX on the at90..  but you can work it out via the 'PortXXX' mapping elsewhere in the file.
Now, *other* parts of the SD library are using the pin numbers directly in 'native' numbering, meaning the use the Teensyduino port mapping. This is also why the 'fan pin' is actually "pin 16", not the '22' as per mainline-marlin. Pin 22 is the 'fastio.h' mapping for "pin 16", but the FAN_PIN calls in 'planner.cpp' actually use native analog_write calls direct to "FAN_PIN", so you need the 'teensyduino' pin mapping.

Long waffling story short, I've made a bunch of changes, set stuff to do what appears to be the right calls. So re download the firmware code

But I can't predict if some nasty back code will still cause issues by reading hte hardware-ss pin (pin 20 or 8 depending on mapping) which is now the 'y-stop' on the printrboard will interefere. Try as above, both on and off the home switch, and if it does interfere, solution is to jump to using hte E-stop for y-stop (and setting y-stop in firmware to read pin 13/19...)

Anyway - mapping issue solved - just takes some dilligence on what calls what where

Can you test asap if this has made the onboard SD work as expected... if that works.. we can move on to cleaning up the LCD issues for you.

Cool cool, I didn't change the mapping, I just dealt with it. I can't see fastio going back as its coded based on the teensylu, which follows the arduino-esque pin mapping. The printrboard on the other hand, was laid out from scratch based on whats closest to what physical connectors - or borrowing Teensylu pins otherwise - meaning it follows nothing close to the teensylu pin numbering in a bunch of areas.

So this way at least, motherboard == 81 (the new printrboard type code), will work, as long as you uncomment SDSUPPORT... The end-stop, we will deal with seperately (and I'll have a chat to SD about if it is a root issue - and get them to pin swap the gerber files they use to get the boards etched (painful as there will then be two versions) or get them to 'adopt' using the e-stop port, and either switch the silkscreens around, or deal with it (less painful, and only leads to differences in connection point not behaviours...)

Keen to hear if it works. and the status of the y-stop (being the hardware SS port, the microcontrollers natural reaction is to treat it as an interrupt...)

No worries.

Keen for someone to test the SD Card support on a new Printrboard SD... (bearing in mind, you can't use Kingston branded SD as they don't support the required protocols...)

Thanks for that !

The file-format, looks to still be 8.3, but I could be wrong.

And the kingston issue is more that 90% of kingston cards don't support SPI, which is what the sdlib uses (theres a few ways to access SD cards - SPI or 'native'.. SDIO is the way to access cards though using 4x, 10x etc.. and not done with most microcontrollers as its a pita timing wise...). It may well have moved on, but its been a long standing general 'using-spi-to-access-sd-cards' issue for a while outside of marlin.

Not good. Enabling SD support and having an SD card in it breaks the USB communication. I cannot get RH to talk to the printer. If I comment out SDSUPPORT, then everything works again.

Just to let you know, I have had alot of problems with the stock printrboard and SD card working. In actuality, I have a clone printrboard that I have had no problems getting the same firmware to work, where it will not work on the SD stock board. I plan to install the clone more 'permanently' this week. I will load this firmware into that and let you know.

Does this update work with the Sanguinololu boards?

Update:

I installed a printrboard clone and tried the latest one you gave me. No good. It does the same thing. When I enable SDSUPPORT, it hoses the connnection to RH. It doesnt show me the printer information, and does not recieve commands. Yes, removing SDSUPPORT it goes back to normal.

So, I took the firmware from the first post and changed the following:
fastio.h has old pin numbering.
SD2pinmap.h has B6 for SDSS.
pins.h has oold pin numbering, and Y stop is moved to E5 (the E endstop).

I can now see the SD card mounted in RH. I am running a test print as I type. Now, this is on the clone board. I had an issue with the stock motherboard before, but I will re-install and try again to see if the newest Marlin somehow takes care of that issue.