Aug 23 2019
Aug 22 2019
@adam What is this? Is it a manufactured part in Cluster? Is it a resale item?
Aug 12 2019
@karrad Routing has been updated.
Jul 22 2019
@Heather "Cluster Staging -> Presub" That's right.
Jul 11 2019
Jul 2 2019
Has there been any decision on which color we're going to be printing this stuff in?
Jun 26 2019
Just to note, this is happening on PP-GP0386/PP-IS0101
Jun 5 2019
Would someone update the OHAI to reflect this
Pre-sub has been informed and will make sure they are sunk correct in the AS-PR0127
May 30 2019
That bandwidth that @west mentioned is going to be consumed again by the introduction of Kangaroo Paw, Brizo, and whatever else comes down the pipeline over the next couple of years, isn't it? While it isn't intrusive, not planning ahead of the bottleneck and potential pitfalls (ie Broken machines, server/Botqueue issues, call-ins, employee loss, etc) can factor into problems in production later on. We've already seen this happen several times. @bowman The figures you have are based on a ideal, problem free production zone.
I agree with @DaniAO. We can discourage the customer all we want but that's not going to stop them from trying. Even with the difference, what's stopping them from downloading the Pro X Carriage model, printing one themselves, and slapping it on a WE? There's already enough differences in the designs and hardware that attempting to put a Pro Dual on a WE would be nearly impossible.
May 29 2019
IT has refused to tackle this issue as it's a symptom of a larger issue involving Botqueue and Bumblebee Driver that runs the Beaglebones. Their solution is to develop a better software that operates more reliably, but until it's ready and launched, we likely won't see a solution to this problem.
Just to clarify, in the future, IT would like all employees to create their own IT Tickets on projects.alephobjects.com
C3 had recently been reformatted and the SSH key was different, resulting in an access issue. I've submitted a ticket on Projects for this issue: #21502 It's been resolved.
May 22 2019
I've updated that part. I'll also double-check all of the PP-GP and other AS-PR parts for Redgum.
Apr 29 2019
Please put any that don't work into a bin or bag and red tag the whole bin/bag. This process hasn't been refined and all of these are currently hand-cut. There's going to be a large fall-out for the time being.
Apr 15 2019
Mar 21 2019
This is going to have all of our most updated weight information for our parts. Parts that are missing weights are either a new parts that we haven't weighed, yet or parts that we don't print anymore.
Mar 14 2019
This gcode may very well be for Gladiola and was one that wasn't updated for Mini2
Mar 12 2019
PP-GP0334 for Mini2 kinda fits the bills.
PP-GP0221 for Mini2 Flexy
Jan 7 2019
I've also included an upload of the file with the questions included.
Oct 11 2018
Oct 9 2018
@alexei I don't think it was mentioned in T3400, but part of adding the "batch" control stuff to Botqueue was to update it to PHP7. As far as I could tell, this was all that needed to be changed that were critical breaks for PHP7.
first_boot.sh was also out of date, so I updated some of the syntax there.
Oct 2 2018
Oct 1 2018
Sep 18 2018
Aug 27 2018
As far as implementing the bare-bones batch control, you'd really only need to add checkboxes and an ajax function that contacts all of the selected bots using the API. This would just be like a plugin that we would just include in the dashboard.
A better practice would be to modify the dashboard's html generation; group machines into separate tables by pod, each with their own form, buttons, and checkboxes The generated structure would probably look similar to this:
<form action="/batch" method="GET"> <!-- Batch Control Syncronized Dropdown and Submit Button --> <!-- Table for A Pod --> <table> <th colspan=12> <!-- Pod Information, Syncronized Dropdown, Submit Button --> <th> <!-- Machines in A Pod --> <tr> <td> <!-- Checkbox with a name based on each machine's id. --> <input type="checkbox" name="bot-$id"> <!-- ID is the bot ID generated with the rest of the row on the table.--> </td> </tr> </table> <table></table> <!-- B Pod --> <table></table> <!-- C Pod --> <!-- Continued Pod Tables --> </form>
This would be generated the way it is now; through PHP. The form's purpose would be to send a list of checked boxes with bot's IDs to a page that would check which ones are true against the current list of machines then set the status of those machines to whichever the user specified in the dropdown by building a query based on the selected option. Using this method would allow for the batch control of setting bot status, passing/failing jobs, clearing queues, or any combination of those. Furthermore, using the HTML/PHP approach, it would also help prepare Botqueue for individual job assignment and batch firmware updates.
Aug 23 2018
@kaleb Could you add
-e 'connect /dev/ttyACM0 250000'
to 'run-pronsole' at line 4? That'll just further streamline the connection process.
Aug 16 2018
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.
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
Aug 15 2018
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.