Remote control of a Makerbot Replicator

[Richard]

I am looking for a way to print remotely.

The problem I am trying to solve is I would like to avoid having to
shuttle back and forth with memory cards as my printer is not where my
computer is. I don't mind the exercise, it just seems there should be
a way to "print over the network".

My preferred solutions would be to have a Raspberry Pi or other
Arduino computer hooked up to it that I could communicate to and
through wirelessly. Problem is I don't have the knowledge of how to
do this.

Another option I am thinking of is to take a spare laptop, load
Replicator G and/or Makerware on it. Have it access my wireless
network and hook it to the printer. I am thinking I could then use a
remote control program like TeamViewer to access and control my laptop
remotely and thus print remotely.

I saw another post where someone discussed doing something with a
little print server box, but it looked like that needed to be plugged
into ethernet. I am looking for a wireless solution.

I also saw another brand of printer that let's you send files to it
over the internet for printing. Problem with that one is I don't own
that printer.

So, does anyone have any good solutions to what I am trying to do or
comments on my idea about the remote control. I am going to try it
but wanted to see if anyone else has done this sort of thing before I
tackle the inevitable troubleshooting and potentially reinventing the
wheel.

[Jetguy]

James and I tried this last night with Repetier Server on a Raspberry
Pi and a Replicator Dual with Sailfish. We got the basics up but
Sailfish didn't accept the "style" of gcode.
In other words, no it's doesn't work out of the box. You would need to
investigate the COM function rep-g uses and then dump that code into
the com function of the server. I have seen the server work with
Repetier firmware but that will not run on a Mightyboard or any
MakerBot as of today,


Now, since you seem to have hardware, why not just remote desktop into
a machine connected to the printer. Control Rep-G from there.

[Richard]

I just downloaded TeamViewer onto an Android tablet and can control
the laptop remotely. I easily pulled up Replicator G remotely and can
generate gcode, etc., etc. I have not tried it with the laptop
hooked up to the printer but that is the next step. It should work
just as well as being there. I may film it and post in a couple of
days.

[Jetty]

RepG has a driver to convert gcode into .s3g/.x3g which can be thought
of as a binary version of gcode to
save parsing it at run time.

It applies to firmwares for MBI machines. You'd need to write a
driver to convert the gcode to x3g, or use the RepG
to convert it and make Repetier send it.

[66tbird]

If your only looking to move files around then what I do may work. I hated going out into the shop(barn) in the heat or cold, dark of night, rain, uphill,, both ways,  carrying an SD around. So I got two cards, but keeping track of dups and corrections was a pain.

 Then I noticed sitting right on my table was a Toshiba E805 PDA(wifi). The thing has a great networking app for dirt cheap($7). Uses low power when docked, screen off, and throttled down cpu, and it's got an SD card slot. (plus on board memory and a CF slot)  So I just keep it on and docked by my bot and drop files onto it from any of my systems. Along with boot and shutdown my other computers and watch streaming TV when I'm waiting for the HBP.

  I kept an eye on ebay for these for years and grabbed my last one a few months back for $30 shipped, and it came with an external usb gps unit which is what I really needed for another project.

 Just a thought. 

Now I've given a little thought to a small box with servos to push the bot's buttons and another camera focused on the lcd. Then window in window that to my bot monitor cam. I'd use what I have on hand for the TX, 6ch receiver and servos all powered by a wall wart.  A (2.4ghz spread spectrum radio transmitter) DX5i is not much and receivers are super cheap at $8 and servos a $4 each. So with the correct lockout mechanism I'd trust it. Luckily I'm not that lazy yet.

[Lloyd]

Is it possible to use EyeFi cards for this purpose?  I think they only push files from the SD card to a computer and can't be used to push a file from a computer to the card.  Does anyone have one and know more?  If this would work I'd buy one right away.

http://www.eye.fi/

[Jetguy]

Well, here's the problem, can you write to a file system while beign
accessed, probably not? You want to put this at the bot but then that
only solves part of the issue. You still have to control the bot.
Part 2 is the unattended crap is just plain not supported. If you
choose to do it, fine, your risk. MakerBot doesn't support it,
Sailfish doesn't support it, this google group owned by MakerBot
shouldn't support it.
If you can't walk over to the printer, you don't need to be printing.

Some folks here are willing to take the risk and say it's not that
bad. These aren't UL listed or certified, they are a heating
appliance, some of them have melted on their own.
http://jettyfirmware.yolasite.com/v74-v44.php
Quoted directly below:
New Replicator safety features

Thing-o-Matics and Cupcakes have safety hardware designed to reduce
the likelihood of the bot's extruder overheating. The Replicators lack
this particular safety hardware. To help compensate for that lack, new
safety features have been added to Sailfish. However, there is only so
much that firmware can do to assure safe operation of your bot.
Firmware bugs including the microprocessor locking up will prevent
software safety measures from functioning. Always operate your bot
safely and in accord with the manufacturer and distributor's
directions. Leaving your bot operating unattended is not recommended.

[Gary Crowell]

I went out and bought a Toshiba FlashAir 8G WiFi SD card.  Supposedly this card has the ability for bidirectional file transfers of any filetype.  The card works in the Replicator with Sailfish.  But, there appears to be no facility provided to send files to the card (even though it is presumably able).  FWIW I can transfer files from my Replicator to the PC via the WiFi connection.  In a review of this card on Amazon, a reviewer specifically says he has sent files to the card.  I've added a comment asking how he did it, but otherwise have no way to contact him, afaik.  I've Googled but found nothing.  Nothing on the Toshiba site either.

Assuming the file transfer could be figured out, I was thinking it might be possible to send the .x3g file to it, then send a .cmd file.  A modified Sailfish could look for a .cmd file while it's idle, and if it finds one 'appearing', that file would tell it the file to print and begin printing.

Gary

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

--
----------------------------------------------
Gary A. Crowell Sr., P.E., CID+

Linkedin  Elance  KE7FIZ

[Jake]

On Friday, May 24, 2013 8:23:14 PM UTC-4, notstarman wrote: 

For the record I tried the wifi solution you mentioned and I can 
confirm that it does allow you to push data to the card. 

To confirm, you're talking about an EyeFi?  Someone also mentioned a Toshiba FlashAir as well.  Which one did you try?  Was there any trick to writing files to the SD, as Gary mentioned that that it wasn't quite straightforward with the Toshiba product.

I'd love to be able to load x3g's while the machine is idle, rather than flipping the SD card between my PC and the bot.

Care to share details?   Can you load files while a print is going on, or only when the machine is idle and the SD not in use? What works and what doesn't? Maybe a brief how-to? 

[MadReasonable]

I have the same basic question as Jake. Was this with an EyeFi card? Did you get this to work while it was plugged in?

If So, this is great news. I have an IP camera ($50 Trio Stealth 4.3" from BestBuy) and my printer is hooked up to a linux box that I can connect to with X11 over ssh from anywhere using my tablet. Now if this EyeFi thing works the only thing left to do is practice knocking prints of the platform using the jog controls ;)

[MadReasonable]

By plugged in I meant inserted into the Replicator while the Replicator is on... And which Replicator?

[Jake]

I took the plunge and bought the Toshiba FlashAir card ($53 shipped from someone's amazon store)

Many reviews of the card talk about its ability to upload.  I have found that this feature is not available, nor barely mentioned, out of the box.  I did some poking around and found that you can add the like "UPLOAD=1" to the config file on the card.  This will enable a page "http://flashair/upload.cg" which allows you to upload files to the card over WiFi.

There are some limitations.  First, the upload only supports 8.3 filenames, so welcome to 1993.  Second, it UPPERCASES the filename.  So your file format comes though as X3G rather than x3g.  So you're files won't show up on the SD menu on the bot, which only sees lowercase x3g extensions.  I'm trying to find a way to control the filename better so that the file becomes visible on the bot.

Also, there are settings for how long the WiFi stays active.  I haven't played with this much, but it seems like its configurable.  5 or 10 minutes are the options in the configuration app.  You might be able to set it longer or disable the timeout completely in the config file, I have't tried yet.

There is a firmware updater on the Toshiba FlashAir site.  If you poke around inside the mac version, you'll see that there is some sort of firmware or disk image with an extension "fbn"  Seems like it contains a linux-ish OS but I don't really know how to extract the file further.  Some older sony erricson phones used to use an FBN file format for firmare, but I'm not sure if is the same and I haven't been able to find any tools to work with this file.  It would be a really cool thing to have full command line access to the card, but it'd be more time to figure out anymore than I care to invest.

[Gary Crowell]

That's progress!  I'll fiddle with mine tonight.

Gary

--

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

[Jake]

A few things I failed to mention.

1. The URL of the upload page, once enabled in the config file, is upload.cgi not .cg as I said (typo)
2. It seems that he upload.cgi CREATES files in all upper case, but overwrites in whatever case is there. You could, in theory have one file called PRINTME.x3g, created on the desktop, that you overwrite on demand, for example. I haven't tried this yet.
3. When playing on my Mac, changes made to the card from the upload script are not immediately reflected on the mounted SD card. I am not sure why. If you eject and reinsert then you see the changes. Maybe the OS buffers or caches or something. I am hopeful that the simpler SD card stack on the Makerbot will work since I don't think it really caches anything.
4. There are other keys such as APMODE and WLANSTMODE for use in the config file that make me wonder if you could get this guy to connect to an existing network.

[Jake]

Hmm. the file overwrite thing isn't working quite as I thought it did. Back to the drawing board.

[Justin Nesselrotte]

So I know I'm a little late to this party, but I'd love to suggest BotQueue.com.  Basically, you can print remotely. We're currently getting it to work on the replicator, so look forward to that in the future.

[Bryon Miller]

I thought it was not suggested to print from USB on these machines, but you would need to be connected via USB in order to do remote printing because you'd need a robot to physically move the SD card back and forth.  With that said... Why can't a user just use remote desktop and control the computer from a phone, tablet or laptop?  To the main machine it would be like someone was just using the machine locally wouldn't it?

For wireless printing, would a print server work?  I have no clue.  My friend and I set up a print server between our houses over an internet network.  We used it to print dirty pictures on each others printers (this was over 11 years ago).  Do print servers do something that wouldn't work with the makerbot?

On Wednesday, February 27, 2013 12:26:54 PM UTC-7, Richard wrote:

[graphmastur]

Remote desktop is complicated and annoying. If there is a way to load the file to the sd card through usb, then we'll do that. I'm sure there is.

Currently, I've gota raspberry pi attached to my printer. Wi-Fi should work, but the raspi doesn't probably give enough power for it.

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

[Jake]

As I understand it, there used to be commands for loading files to the SD over USB. Loading files this way, however, was slow due to baud rate limitations. Also, since the mightyboard uses an ATMEGA 1280, firmware space is at a premium. I believe these features were removed to save space. Dan would know better.

I am very happy with using the Toshiba FlashAIR card to load files to my Sailfish-enabled Makerbot. I haven't ejected the card from the Makerbot for weeks and I've loaded every file over Wifi successfully. It really is a good way to load files to an SD card. I wrote a small python script that uploads the file and then re-downloads it to verify that it was received properly before printing from the SD Card menu.

If one were inclined, they could make a special version of Sailfish that checked the SD card for new files every so often, and if found, start a print on any new files. Maybe using a file numbering scheme and a counter that tracks the last print number. I don't know if the Sailfish SD FAT library supports file writing, but if it did, you could even write a text file back out with the print statistics at the end of the print to confirm the completion of a print job.

I don't think these are the kind of features Dan would be interested in due to file space limits, but its achievable for the motivated firmware hacker.

[Jetguy]

Don't forget, you can join the small but growing group of us who just cut off our mega1280s and soldered on 2560s and no longer have a "space" issue for extra program features.

 

Just saying, it's about $18 for the chip from Digikey and an evening with a soldering iron.

[Dan Newman]

On 11 Jul 2013 , at 10:05 AM, Jake wrote:

> As I understand it, there used to be commands for loading files to the SD over USB. Loading files this way, however, was slow due to baud rate limitations. Also, since the mightyboard uses an ATMEGA 1280, firmware space is at a premium. I believe these features were removed to save space. Dan would know better.
>
> I am very happy with using the Toshiba FlashAIR card to load files to my Sailfish-enabled Makerbot. I haven't ejected the card from the Makerbot for weeks and I've loaded every file over Wifi successfully. It really is a good way to load files to an SD card. I wrote a small python script that uploads the file and then re-downloads it to verify that it was received properly before printing from the SD Card menu.
>
> If one were inclined, they could make a special version of Sailfish that checked the SD card for new files every so often, and if found, start a print on any new files.

That's actually pretty difficult when you have maybe 200 - 300 bytes of spare RAM.
You can't expect time stamps on the files, so you need to maintain a list of known
files. But to do that and to support multiple folders, you now need to be able
to handle a tree traversal so you can walk all the directories. No matter how
you slice it that requires more RAM (either for stack if doing a recursive
traversal, or heap == RAM if doing a non-recursive traversal). Net, net the
memories not there unless you abandon folder support. And, even if you abandon
folder support there's still some issues: interlocking of some sort so that you
don't spot the new file and start acting on it when it hasn't been completely
written (e.g., maybe the write process failed and left it incomplete). I suppose
you could use a poor man's hitching post technique but even that might leave a
small window.

> Maybe using a file numbering scheme and a counter that tracks the last print number. I don't know if the Sailfish SD FAT library supports file writing, but if it did, you could even write a text file back out with the print statistics at the end of the print to confirm the completion of a print job.

File writing is supported -- 'tis how your EEPROM can be saved to SD card.
Again, the hard part is the interlocking. For example, is a file rename
atomic? Then you would write it to a temp name on the SD card and rename
it to the name which the firmware would see. However, there's no room
for any of this on an ATmega 1280. Not without tossing something.

Dan

[Dan Newman]

On 11 Jul 2013 , at 8:25 AM, Bryon Miller wrote:

> I thought it was not suggested to print from USB on these machines,

If you have a dedicated uProcessor talking over USB to the bot, then
you remove some of the USB issues. E.g., desktop going to sleep,
other processes suddenly consuming huge numbers of CPU cycles and/or
IOPs causing the USB to stall, etc. However, there are other USB
issues which are not surmountable: namely on the firmware side,
using USB to send the print to the bot consumes lots of interrupt
level CPU cycles which then robs cycles from other activities,
including the stepper interrupt. Net result is that print quality
can suffer, especially when printing high detail at very fast
speeds. (Seen too many people have print quality issues which
then go away when they stop printing over USB.)

And, since the Rep 1 / Rep 2's have no flow control over the serial
s3g/x3g protocol, matters are exacerbated. USB had flow control,
but the 8u2 chip takes bytes off the USB bus and copies them over
to a very primitive TX/RX USART with no flow control. The host
just sends bytes until the firmware stops responding. The firmware
sends back a buffer overrun and the host then just keeps on resending
with no synchronization the same command until finally the bot accepts
it. Commands flow for a command or two and then the bot's buffer
overflows again and the desktop just then keeps on resending. All
these resends hit the bot at interrupt level with it reading the
bytes off the USART, discarding them if it isn't ready for them,
and sending back an "buffer overrun" error. It's really quite
inefficient and wastes lots of cycles at interrupt level on the
bot. And when it's trying to quickly print fine detail, it's
already somewhat lacking in spare CPU cycles.

Dan

[Jake]

Good points.   Not as easy as I had considered I guess.  Probably still possible, but maybe not so simple.

There is some weirdness with how the Toshiba FlashAir handles things and I'm not sure things are atomic, but there might be some sort of locking.  I can tell you its like the "SD Interface" and the "WiFi Interface" are separate things and they access a shared store.  Doing tests on a PC, I have made changes using the WiFi interface and didn't see those changes reflect on the SD card until I pulled the card and re-inserted it.  However, it's really hard to know what's going on-- how much is the PC caching and whatnot.  When playing on a PC, the OS tends to pull power from the SD card when it thinks nothing is going on on the SD side, like when doing network access over WiFi.  I have not done an extensive investigation on how the "two sides" interact, as there is no need for me: the card works for how I like to use it-- loading files over WiFi and then printing using the menu

I don't know if a "Print file named" USB command would be possible, but then you could do a split solution, load the file via WiFi and then command it to print that specific file over USB, but that's more complicated.  Again no space, but if someone were making a firmware for print server use only, then there could be some things that get tossed.

[Dan Newman]

On 11 Jul 2013 , at 3:10 PM, Jake wrote:

> Good points. Not as easy as I had considered I guess. Probably still
> possible, but maybe not so simple.

Everything we programmers take for granted as being simple simply isn't
when you have insufficient RAM and insufficient program space. Typical
directory tree traversal is either recursive and thus requires lots
of stack (RAM) and being able to open lots of files concurrently (lots
more RAM), or doing a non-recursive traversal which ends up requiring
lots and lots of RAM. For those of us who were programming in the 70's
or earlier, its just reminds us of why we were so happy to get past
8K of RAM, overlay linkers, etc., etc.

> I don't know if a "Print file named" USB command would be possible,

There already is one. It's how Cupcake owners print from USB: RepG
gets a list of the files on the SD card, displays them, and then the
user picks one. RepG then sends an S3G command over USB saying, "Print X".
The file must be in the bot's concept of the current working directory on
the SD card. RepG navigates to directories by telling the bot to "Print D"
where "D" is a directory file. The bot, recognizing that it is a directory
file, moves to that directory as the current working directory. You move
to the parent directory by, you guessed it, telling the bot to print the
file "..".

Dan

[John Dogru]

Hey guys! There is a way to totally remote control your makerbots. Just search for fabsecure fabsecure.com . You simply plug it in and it connects your printer to the cloud for sharing and remote control printing with a built in wide angle camera and start stop prints from your mobile or desktop. It also has secure streaming whichever encrypts your designs and allows you to print to most all desktop printers. Check it out and email me for questions.

Sincerely,

John Dogru

[Joseph Chiu]

Hi John,

Interesting idea -- is the product for securing the STL source data (which I believe it does), or for limiting unauthorized reprinting?

As it is, MBI firmware does not support encryption, so it would be easy to sniff the signal chain to intercept the .x3g/.s3g data.   Even if you secure the link to the 1280, it seems to me that with a second printer, and about a dozen clip-leads, I could easily slave a "duplicator" to simultaneously print a second copy of any active print in progress.  

And, since standard MBI hardware is not secured (unlike, for example, DCI/DCP compliant hardware protecting digital cinema with a secured strong-box), you would have a hard time detecting or preventing an intercept.  

I suppose there's some regulatory teeth under DMCA?

--

You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.

To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.

[Jetguy]

What's worse about this solution is that you are basically setting up a mini computer connected via USB as one more point of failure. Power loss, reboot, USB glitch, whatever, it's one more point of failure. Also, we cannot forget that MakerBot is continually changing the S3G/X3G protocols and commands nearly every release of the firmware and software. This means that this company would have to follow each MakerBot update with it's own update to the device. Obviously, with proper coding review and QC practices that would take additional time or be a lag between updates.

 

So again, just to be clear, using this device or any other like is:

Violates the printing over SD card principal rather than USB.

Is another device that requires constant power.

Another source of electrical noise and could present a ground loop across the USB connection.

Will require updates to match changes in the S3G/X3G protocol.

[Jetguy]

See, and just to kind of bring home how complicated this can be here is a discussion just today on handling communications and commands in the firmware https://groups.google.com/d/msg/makerbot/OKVn-SZsma0/Gmqakdg8PQkJ

The folks I would consider "Experts" in this field, are still trying to evolve and understand interactions with the communications to a MakerBot.

 

So how can this company guarantee they too are on top of such changes or even an understanding as this is evolving.