Taz 6 drunken octopus questions for Maricio

1

  1. The CUSTOM_MACHINE_NAME is defined as “TAZ 6” in the config by default, this should actually be “LulzBot TAZ 6” because otherwise Cura doesn’t properly communicate with the printer while in monitoring mode. Changing it in config.h and recompiling fixed the issue.

  2. The version is displayed as “bugfix 2.0.x” - is that on purpose? Would be nice if this was properly set in the repo to easier track which version I installed. Didn’t see this in config.h, not sure where to set it manually…

  3. Browsing the SD card is SLLLLOWWWW, like noticeably worse than with my ancient 8bit rambo board and default firmware. Is this a known issue? I was hoping the new board would help this existing problem, instead it made it noticeably worse…

2

Ok, managed to solve #3 myself, for some reason SD_SPI_SPEED was set to SPI_SIXTEENTH_SPEED, changing it to SPI_FULL_SPEED made it awesome… now this has got me thinking, how properly configured is drunken octopus? How many other things like this are set to questionable values? Was it a stable branch or something random and dev that got grabbed when AlephObjects self destructed? There seem to be a lot of “<-- changed” in the config files…

3

To answer 1 & 2

  1. It is named Taz 6 in DO firmware as is not linked to Lulzbot in any way, and probably doesn’t want to add a trademarked name to an unofficial FW for the machine.

  2. Yes! the FW is compiled on the latest bugfix version of Marlin. if you want it to show the version you are using, use the main branch of Marlin and edit the config file to state the version, alternatively, you can find the version under about printer on the LCD.

4

  1. Yeah, the trademark thing makes sense, but it actually causes a problem in basic functioning of the printer, monitoring and testing things from Cura is important so if “LulzBot” isn’t allowed there should be another way of doing it. I guess changing and re-compiling works lol :slight_smile:

  2. Do you know what the variable name for that is, couldn’t find it…

5

The algorithm used by Marlin for reading file is O(N*N) complexity with the number of files on the SD card, so with more than a few dozen files on the board, it will slow to a crawl, no matter what board you have. The solution is to keep fewer files on the card or to put them in folders.

As you correctly identified, the SPI_SPEED makes a difference, but it was intentionally set low because during initial testing at LulzBot we found that machines would occasionally crash when the speed was set higher. This is because the ribbon cables are unshielded and higher transfer speeds make it more susceptible to noise. It is also because the Archim is 3.3V rather than 5V and thus is way more sensitive to noise. This largely depends on the machine and how it was build. Some are more forgiving than others. Given the number of machines in the field, the choice was made to set the SPI_SPEED very low in order to prevent problems.

For what it is worth, that speed was also chosen for the Touch Panel, which is somewhat more susceptible to communication glitches than the GLCD, but again, the values chosen are meant to operate across the board.

So you can crank the SPI_SPEED higher if you want, you may even get away with it for a while. But this will only provide a linear speed up, vs. the exponential slowdown as you continue to add files to the card, so it will eventually catch up with you.

As for the LulzBot thing, yeah, it was removed for trademark reasons. You can go into Preferences in Cura and tell it to allow connection to unrecognized printers.

6

DO tracks the “upstream/bugfix-2.0.x” branch. This is because I routinely push patches upstream and they are only accepted into that branch.

“Official” releases are made in other branches and do not necessarily correspond to “upstream/bugfix-2.0.x”. That is why it is impossible for me to provide a version number corresponding to official Marlin releases.

7

Thanks for the historical and engineering details, that makes sense. Was the crashing happening as part of printing or just when reading the files / using the touchpad for navigation? I could probably tolerate the latter but definitely not the former. Will try reducing the speed to HALF or just wrapping the ribbon cables in copper foil with a grounded conductor attached if problems arise.

Fundamentally, do you know why reading files is N^2? It seems like a pretty straightforward linear problem. I naturally get the “can’t be that hard, i can fix this open source thing!” drive but I’m sure if there was a simple way of addressing this, it would have been done long ago…

“You can go into Preferences in Cura and tell it to allow connection to unrecognized printers.” - ah cool, you should probably add this to your instructions because testing LulzBot printers through Cura is what people used to their ecosystem will start doing right after upgrading the firmware.

“This is because I routinely push patches upstream and they are only accepted into that branch.” - awesome, thanks for doing this!

8

Was the crashing happening as part of printing or just when reading the files / using the touchpad for navigation?

The touch panel relies on bidirectional communications, so if there was an error in the SPI bus, in some place where there wasn’t a timeout, it could freeze the board. This could happen at any time. So for the TAZ Pro, it became necessary to ensure no errors ever happened.

The GLCD is strictly a write-only display, so errors in the SPI bus may garble the display, but is otherwise harmless. This is probably why an unshielded cable was used in the first place. So with that display, you may be able to get away with a higher SPI speed.

Fundamentally, do you know why reading files is N^2?

It’s quite simple. The SD library only is able to list files in the forward direction. Marlin wants to show files in the reverse direction so most recently added files show up at the top of the list. So they loop through all the files to find the last one and paint it on the menu, then they scan through all the files to find the penultimate one and paint it on the menu… and so forth. So roughly 1/2O(NN) at the start of the list, but you will see that if as you move to towards the end of the file list, it gets faster and faster…

9

Lol is that sd card library open source? Again, scan through all the files adding them to memory with their dates, sort by that date, print descending… seems straightforward to implement, wonder why it wasn’t done. Memory limitation of the old 8bit rambo? I know many old arduinos barely have enough for anything.

Anyways, I did a low-level format on the card and moved a bunch of old files to a subdirectory, it’s very fast now, I guess that’s the real reason nothing was done, it works if you keep the card clean.