Botqueue observations

[Wouter]

After using Botqueue 0.5 for 300+ hours of printing time (with 3 bots), I would like to share some of the things I've run into. Please note that I'm not using the slicing engine as I'm printing thin walled objects (2 shells maximum) and need visual feedback/check before I start printing. (And I'm one of those dinosaurs that still uses skeinforge.)

Feature requests:

1) Indicate estimated printing time for jobs which are on deck

The reason why I come up with this is that my girlfriend doesn't like the noise of the printers while we are trying to get some sleep. I've had several occasions that we went to bed and one of the bots was still working on something for at least half an hour. She wasn't too happy about this.

For an already sliced job it would be possible to implement this as you only have to go through the file. 

2) Search through list of jobs.

Currently I have over 200 jobs in my finished jobs list and it is quite difficult to find a particular job in order to rerun that one. A simple search box which allows searching for a job based on filename would make live quite a bit easier for me.

3) Turn heaters and motors off when putting a bot in error/offline mode

When things have gone bad for some reason everything is locked, I would need pronterface to issue a M84 before I'm able to correct things. is it possible to implement something that "releases" the bot?

Observations:

4) Every now and then one of the bots fails to start printing. The bot gets a job from the BQ server but doesn't start at all. It looks like it fails to start on the .gcode file. It happened to me about 6 to 8 times untill now and I haven't found any pattern so far. A restart of the bumblebee client solves this issue. While typing this I realised that I should have taken a look at the bumblebee logfile. Will do this next time.  

Question:

5) Is it possible to create a slicing only bot?

As each of my bots is running from a raspberry pi, I was wondering if it is possible to create a separate bot (without a printer attached) which slices everything and returns the geode files to the BQ server so that one of the RPi can start printing on it. My local webserver running the botqueue instance has much more processing power compared to the RPi's. If this is possible, what would be needed to implement skeinforge as a slicer?

After I got everything running it has been pretty smooth sailing considering. It definitely beats running several pronterface instances!

Wouter

[Justin Nesselrotte]

I've updated my email preferences, since I was never notified about this post. Sorry for the delay in my response.

I'm glad that you're enjoying BotQueue. Make sure when you call 'git pull', that you run the "apply_patches.sh" script in the upgrade directory. This makes sure that the database is perfectly in sync with the running code.

1) This is true for some slicers, but not for others. We can't depend on them. Normally, the file isn't read until it's about to be printed, so that's out too. Plus, if you're using s3 for the storage engine, you'd have to download the entire model just to read each line. Transfer between our server and s3 may be free, but it is time consuming. I agree that it should be there, but I've yet to find a good solution.

2) You're pretty much the second person that's asked that, so sure. I'll work on it.

3) I agree, but I think it should do more. I'm going to add an on error section where you can add gcode to send if the bot moves into error mode.

4) I'd definitely need to see the info log. Right now, that usually means that the printer won't connect, which is a longstanding issue that I can't seem to nail down. The other issue is that the cache directory is too large, and has used up all free space. If it's the printer not connecting issue, then make sure to do a git pull on the client side.

5) I actually did that just the other day, with some slight modifications to the backend. I think it's definitely something people would like, but I don't like the idea that it's a bot. For now, it seems that that will be how it's implemented, though. As for getting skeinforge to run, it probably won't be that difficult. I just refactored a lot of code to get started with Cura.

Thank you for your suggestions!

[Wouter]

Hi Justin,

I've finally been able to isolate an info.log with a non starting bumblebee client (point 4).

In the log you'll see that the first job runs fine and the second job (starting at 09:47:10,852) stay's at 0%.

When I updated the clients to 5.3, I've run an update for the server as well. Please let me know if you need more info.

Thanks,

Wouter

[Justin Nesselrotte]

Very interesting. Normally, when I see this behavior, it's because the bot is stock on some heating command, and it doesn't reach temperature correctly. I'm surprised though that a restart of the client would fix it. Do you have an LCD panel? If so, can you see if the issue is because of that? If it gets stuck, you can lower the temperature that it's trying to reach to see if it can continue.

[Wouter]

I have this behaviour on all three printers, none of them has a LCD attached. Uploading .gcode files to my botqueue server instead of .stl files. When a clients stalls, none of the heaters has started heating up. 

Noticed that after a client has received a new job, for a small time one cpu core is at 100% (processing job I assume) and about 20 to 30 seconds later the progress bar (on the server) goes from 0.00% to 0.02% (or 0.03%). If it does the printer has started his heating elements, if it doesn't I would have to restart the client.

A typical start command for a botqueue job is:

G28

G90

G92 E0

G92 X0

G92 Y0

G92 Z0

M106 S0

M140 S70

M104 S210

M190 S70

M109 S225

G92 E0

G90

G21

M103

etc…

I'm using marlin firmware btw.

[Justin Nesselrotte]

Hmm. Well, printrun does run through the commands first and stores then in a queue. I'm guessing that never finishes. It's a bit annoying that it's not a specific file that causes it. Do you think it could be a memory issue? As in it runs out of memory?

--
You received this message because you are subscribed to the Google Groups "BotQueue" group.
To unsubscribe from this group and stop receiving emails from it, send an email to botqueue+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Wouter]

The gcode files are not that large (usually between 1 and 5MB). I've been using raspberry pi's and recently switched to the Rpi2 which has more ram. issues remain though. 

This morning I've had to re-upload a gcode file as the one I had re run from my finished queue list did not start. even restarting the client didn't help. 

[Justin Nesselrotte]

Ooh. Can you send me that one? The main thing will be if the gcode fails preprocessing somewhere, then where does it fail?

[Wouter]

gcode file or log?

You received this message because you are subscribed to a topic in the Google Groups "BotQueue" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/botqueue/NgNpJ89c7Fg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to botqueue+u...@googlegroups.com.

[Justin Nesselrotte]

Gcode. It will probably pass checks. Did you install from pip, or use the github version of the client?

[Wouter]

git.

I’ll send the gcode to your private email

Wouter

[Justin Nesselrotte]

Awesome, thanks. Can you run "git rev-parse HEAD" in the "Bumblebee/bumblebee/engines/driver/Printrun" directory?

[Wouter]

Will do later today as the printer is currently busy.

Wouter

[Wouter]

here you go: 

~/Bumblebee/bumblebee/engines/driver/Printrun $ git rev-parse HEAD

7f5c85545d7357b2e302168f7d813328a1f623d7

[Wouter]

Another thing that comes into mind is that when bumblebee stalls it is alway before there is any "action/motion" on the printer itself. No homing, no heating, nothing.

[Justin Nesselrotte]

Yeah, so far it's looking like it's not parsing the file correctly, but I'm still trying to figure out why.

--