Remote bot console

[qharley]

Another feature that can prove useful, is another bot state: "Remote"

In this mode the bot will go online without taking on jobs, but allow the user to manually issue gcode commands to the bot, with bidirectional communication.

Currently I have to switch off, disconnect, and fetch the pc in order to do this. I imagine this would be a bit more cumbersome when you have a battery of machines...

[Jnesselr]

Yes, manual control of the machines would be nice, maybe call it "manual". As far as ease of implementation, currently, the bot fetches jobs, so we could send it gcode as a job that doesn't show up as a job, but... eew. So we'd have to have something that polls jobs and commands. So a possibility is to make it poll for a next command, and have each command be a type. So "stl" "gcode" or "manual". That way, the bot polls for exactly what it needs. If it sees a job, it won't take it in manual mode. On Jun 26, 2013 11:13 PM, "qharley" notifications@github.com wrote:

Another feature that can prove useful, is another bot state: "Remote"

In this mode the bot will go online without taking on jobs, but allow the user to manually issue gcode commands to the bot, with bidirectional communication.

Currently I have to switch off, disconnect, and fetch the pc in order to do this. I imagine this would be a bit more cumbersome when you have a battery of machines...

— Reply to this email directly or view it on GitHubhttps://github.com/Hoektronics/BotQueue/issues/77 .

[qharley]

This sounds exactly like what we need.

Sent from my iPad

On 27 Jun 2013, at 6:18, Jnesselr notifications@github.com wrote:

Yes, manual control of the machines would be nice, maybe call it "manual". As far as ease of implementation, currently, the bot fetches jobs, so we could send it gcode as a job that doesn't show up as a job, but... eew. So we'd have to have something that polls jobs and commands. So a possibility is to make it poll for a next command, and have each command be a type. So "stl" "gcode" or "manual". That way, the bot polls for exactly what it needs. If it sees a job, it won't take it in manual mode. On Jun 26, 2013 11:13 PM, "qharley" notifications@github.com wrote:

Another feature that can prove useful, is another bot state: "Remote"

In this mode the bot will go online without taking on jobs, but allow the user to manually issue gcode commands to the bot, with bidirectional communication.

Currently I have to switch off, disconnect, and fetch the pc in order to do this. I imagine this would be a bit more cumbersome when you have a battery of machines...

— Reply to this email directly or view it on GitHub< https://github.com/Hoektronics/BotQueue/issues/77> .

— Reply to this email directly or view it on GitHubhttps://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20096473 .

[Jnesselr]

Plus, it expands our ability of things to send, for example, svg for laser cutter. We may end up sending config files to the client as well. That way, a job can have a different config than all other jobs. Or a cnc machine might need to know the height of what it's cutting, or a 3d printer needs to know the color of plastic. Basically, this would describe an open ended key value system of attributes where attributes can range from meta data to files.

So obviously, config changes would go before the job they modify. Manual commands would go before anything. So maybe like Linux does run level stuff and have each one be a number that can be reordered, possibly per user. So a job is like 99, a manual command is 1, config changes is 2, etc. And in that job, you'd have multiple of these key values, one for config, one for the stl or gcode (also useful for remote slicing), you could even have hooks that run between state changes, for example, before slicing, you could have a pre script that heats the bed, homes the axis, and heats the extruder, which would run while the file is being sliced. On Jun 26, 2013 11:22 PM, "qharley" notifications@github.com wrote:

This sounds exactly like what we need.

Sent from my iPad

On 27 Jun 2013, at 6:18, Jnesselr notifications@github.com wrote:

Yes, manual control of the machines would be nice, maybe call it "manual". As far as ease of implementation, currently, the bot fetches jobs, so we could send it gcode as a job that doesn't show up as a job, but... eew. So we'd have to have something that polls jobs and commands. So a possibility is to make it poll for a next command, and have each command be a type. So "stl" "gcode" or "manual". That way, the bot polls for exactly what it needs. If it sees a job, it won't take it in manual mode. On Jun 26, 2013 11:13 PM, "qharley" notifications@github.com wrote:

Another feature that can prove useful, is another bot state: "Remote"

In this mode the bot will go online without taking on jobs, but allow the user to manually issue gcode commands to the bot, with bidirectional communication.

Currently I have to switch off, disconnect, and fetch the pc in order to do this. I imagine this would be a bit more cumbersome when you have a battery of machines...

— Reply to this email directly or view it on GitHub< https://github.com/Hoektronics/BotQueue/issues/77> .

— Reply to this email directly or view it on GitHub< https://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20096473> .

— Reply to this email directly or view it on GitHubhttps://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20096546 .

[qharley]

Perfect.

Sent from my iPad

On 27 Jun 2013, at 6:32, Jnesselr notifications@github.com wrote:

Plus, it expands our ability of things to send, for example, svg for laser cutter. We may end up sending config files to the client as well. That way, a job can have a different config than all other jobs. Or a cnc machine might need to know the height of what it's cutting, or a 3d printer needs to know the color of plastic. Basically, this would describe an open ended key value system of attributes where attributes can range from meta data to files.

So obviously, config changes would go before the job they modify. Manual commands would go before anything. So maybe like Linux does run level stuff and have each one be a number that can be reordered, possibly per user. So a job is like 99, a manual command is 1, config changes is 2, etc. And in that job, you'd have multiple of these key values, one for config, one for the stl or gcode (also useful for remote slicing), you could even have hooks that run between state changes, for example, before slicing, you could have a pre script that heats the bed, homes the axis, and heats the extruder, which would run while the file is being sliced. On Jun 26, 2013 11:22 PM, "qharley" notifications@github.com wrote:

This sounds exactly like what we need.

Sent from my iPad

On 27 Jun 2013, at 6:18, Jnesselr notifications@github.com wrote:

Yes, manual control of the machines would be nice, maybe call it "manual". As far as ease of implementation, currently, the bot fetches jobs, so we could send it gcode as a job that doesn't show up as a job, but... eew. So we'd have to have something that polls jobs and commands. So a possibility is to make it poll for a next command, and have each command be a type. So "stl" "gcode" or "manual". That way, the bot polls for exactly what it needs. If it sees a job, it won't take it in manual mode. On Jun 26, 2013 11:13 PM, "qharley" notifications@github.com wrote:

Another feature that can prove useful, is another bot state: "Remote"

In this mode the bot will go online without taking on jobs, but allow the user to manually issue gcode commands to the bot, with bidirectional communication.

Currently I have to switch off, disconnect, and fetch the pc in order to do this. I imagine this would be a bit more cumbersome when you have a battery of machines...

— Reply to this email directly or view it on GitHub< https://github.com/Hoektronics/BotQueue/issues/77> .

— Reply to this email directly or view it on GitHub< https://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20096473> .

— Reply to this email directly or view it on GitHub< https://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20096546> .

— Reply to this email directly or view it on GitHubhttps://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20096770 .

[hoeken]

This is definitely high on my list of priorities - gotta get thru a few other features first. The thing that is really going to make this happen is websockets - because then you can basically get realtime bidirectional comms between your bot and the site, as well as skipping the hop to the webserver if you're on the same subnet. Check out the roadmap if you're interested in where I want to take BotQueue this summer.

---

Zach Hoeken Smith

Work: www.haxlr8r.com Blog: www.hoektronics.com Twitter: @hoeken Skype: chilldude22 QQ: 1489598623 China: +86-186-8209-7069

On Thu, Jun 27, 2013 at 12:13 PM, qharley notifications@github.com wrote:

Another feature that can prove useful, is another bot state: "Remote"

In this mode the bot will go online without taking on jobs, but allow the user to manually issue gcode commands to the bot, with bidirectional communication.

Currently I have to switch off, disconnect, and fetch the pc in order to do this. I imagine this would be a bit more cumbersome when you have a battery of machines...

— Reply to this email directly or view it on GitHubhttps://github.com/Hoektronics/BotQueue/issues/77 .

[Jnesselr]

What did you think of my idea? Or did you have a different one? What version is websockets planned for?

[hoeken]

Well, websockets will likely replace the current polling style of communications - why poll when you can have realtime communications.

Aside from that there will definitely be a way to send raw gcode commands to the bot to be executed - and on top of that we can build a control panel that you can use on botqueue.com to manually control your bot over the web.

The rest of the stuff you listed I agree in principle - but we really have no need for that stuff yet so while I'm happy to think and talk about it, I don't want to start implementing any thing like that yet.

---

Zach Hoeken Smith

Work: www.haxlr8r.com Blog: www.hoektronics.com Twitter: @hoeken Skype: chilldude22 QQ: 1489598623 China: +86-186-8209-7069

On Fri, Jun 28, 2013 at 12:02 AM, Jnesselr notifications@github.com wrote:

What did you think of my idea? Or did you have a different one? What version is websockets planned for?

— Reply to this email directly or view it on GitHubhttps://github.com/Hoektronics/BotQueue/issues/77#issuecomment-20132612 .