Page MenuHomeAleph Objects Inc

Minimize variance in printed parts
Closed, WontfixPublic

Description

To minimize the variance on critical dimensions of printed parts for quiver, we should work towards

*one gcode per part

*one part per printer-model

*one printer-model per pod

*automated/scheduled firmware checks and updates

For the first three, we just need to not slice files for multiple types of machines, but for the last one I'm not sure.

Event Timeline

kent created this task.Aug 15 2018, 12:33 PM
kent triaged this task as Normal priority.

I will have to verify if we have pods with various models.
As far as firmware flashing updates, we will have to get with Kaleb to make that happen. We currently have to take a laptop to each printer to flash firmware, as Pronterface is not on our terminal interface through our computer stations. So this one may be difficult.

Kazkade added subscribers: kaleb, Kazkade.EditedAug 15 2018, 1:58 PM

In regards to the firmware information, here's a script I wrote to check all of the versions on the beaglebones. It prints out the pod number. Some pods don't have 10s and 11s, which is why you'll see nothing output after some of the machines. We could have this output every week/month or whichever interval.

#!/bin/bash
for x in a b c d e f g h i j k l m n o
do
  for y in 1 2 3 4 5 6 7 8 9 10 11
  do
    echo "$x$y - " >> Desktop/beaglebone_versions.log
      ssh bbb-$x$y -t -oStrictHostKeyChecking=no 'grep "Debian GNU/Linux" /etc/issue && grep "Image" /etc/issue' >> Desktop/beaglebone_versions.log
      echo "" >> Desktop/beaglebone_versions.log
  done
done
exit

@kaleb You said you wanted to take a look at scripts I make, so I'm tagging you here.

Here's the result of running that script:

kent added a comment.Aug 16 2018, 10:30 AM

I found a way to flash new firmware to the printers from the BBB so that we don't have to take the laptop to each machine. This technique, combined with a script similar to what @Kazkade wrote could be used to automatically update all firmwares in cluster at once, or pod by pod, pretty much however we want to do it.

To flash a printer from the BBB, first you have to get the .hex of the firmware onto the beagle bone. The best way I have found to do this is with wget:

wget http://devel.lulzbot.com/mini/hibiscus/software/marlin/Marlin_Mini2_AerostruderV2_1.1.8.62_f3e0540ca.hex

Then, once the firmware is on the BBB, run this command:

avrdude -c stk500v2 -p m2560 -P /dev/ttyACM* -b 115200 -D -U flash:w:Marlin_Mini2_AerostruderV2_1.1.8.62_f3e0540ca.hex

To prep for a bulk-install feature, I'll need to adapt that script for the different types of machines we have and we'll need avrdude on the beaglebones.
I don't have the correct access to push a new branch to that repo, but we only need to add avrdude to line 137 in https://code.alephobjects.com/source/aobbbconf/browse/master/AO_bbb_postinstall.sh

kent added a comment.Aug 16 2018, 12:37 PM

The aobbbconf repo is set up as a restricted project. Probably against IT policy to edit it. I'll create an IT service request to add avrdude and we will see what happens.

kaleb added a comment.Aug 16 2018, 1:48 PM

Let's not be too hasty here. First we need to test whether or not avrdude will interfere with bumblebee; the simplest way to do that would be to set up bumblebee on bbb-mer, which is quite easy if you look at the configurator. If this works, will you still need to calibrate the printers manually afterward?

More importantly, it may not be a good idea to flash en masse regardless of how we do it. Any possible solution would require very rigorous checking to make sure one typo doesn't end up installing the wrong firmware on the wrong printers much like cura-lulzbot already has. It may be best to consider implementing this functionality in BQ if possible.

When we flash new firmware, we need to enter z-offsets and e-steps again, but we can have the script get/set those for us or, at the very least, output the old values before flashing. I think the best approach to using a tool like this would be to flash 1 pod at a time rather than the entire cluster all at once.

We're fine implementing this in BQ if that's the route we decide to take, but if we're pre-installing pronsole (or like-software) onto the BeagleBones, we can circumvent the use of bumblebee to send commands to the printer when its' not printing. If we have to interface with bumblebee, I'm positive some software changes are going to need to be made which can be a pretty large task.

As far as your concern with typos, I agree that rigorous typo checking can be arduous, but we can/should automate everything to avoid any issues. We could set up a repo with different branches for each machine type (mini, mini2, taz6, etc) and just supply the latest stable firmware to them then clone, flash, delete.

kent added a comment.Aug 17 2018, 2:22 PM

@kaleb I think bumblebee was already set up on bbb-mer when you set it up in December. It certainly is now in any case. I've been running prints though botqueue all day without any issues. Afaik avrdude does not run as a background task, only when it's invoked so I'm not sure how it would interfere with bumblebee. Is there a specific failure mode you are concerned about? Yes, as @Kazkade said, we would still need to enter the z-offsets and e-steps (where applicable).

avrdude can be used to check that a specific firmware has been installed, too, and if the check script was separate from the flash script, then the typo would have to be made the same way in both places, which is unlikely. The current system is just as likely (if not more likely) to get the wrong firmware onto the machines, the difference being that if a mistake is made, correcting that mistake would take much longer with the current system than with the proposed system. It's unlikely that if there was a mistake made in which firmware got flashed to an entire pod, that it would go unnoticed, which means it's a pretty low risk. I don't see this feature being added to BQ considering that there hasn't been a single commit to the repo in over two years and there are no developers actively working on it. That might change though.

Kazkade added a comment.EditedAug 23 2018, 2:27 PM

@kaleb Could you add

-e 'connect /dev/ttyACM0 250000'

to 'run-pronsole' at line 4? That'll just further streamline the connection process.

Just to note, as well, pronsole is trying to connect using 115200 as the default baudrate. All of our printers in cluster are running at 250000 since the firmware released with mini2.

nickp changed the edit policy from "All Users" to "LulzBot Hardware Products (Project)".Oct 25 2018, 12:00 PM
Steven closed this task as Wontfix.Nov 21 2018, 2:50 PM
Steven added a subscriber: Steven.

The discussion here doesn't appear to be directly specific for Quiver. I'm closing this out but feel free to reopen and tag with another project other than Quiver.