Makerware only shows the grid, no scale/move/rotate buttons (remote desktop connection)

[Arjun M]

Hi all,

do any of you know what might be going on here? I have my replicator dual connected to a desktop in my house, and i am using my laptop to control that computer via windows 7 remote desktop.

I installed makerware 2.3.1. The only thing I see is the grid. I don't see any buttons (move, scale, rotate). I can add an STL file and it shows up fine! But I can't see the move/scale/rotate buttons.

(see pic)

Do any of you know what might be going on? I don't have a monitor to plug directly into that desktop computer at the moment, so I'm not sure if this issue is specific to remote desktop.

What are the minimum requirements for Makerware? I have a 3.3GHz Intel  i3 processor on that desktop (no dedicated graphics card), but that shouldn't be a problem, right? Even tinkercad works fine on remote desktop...

any suggestions/thoughts/advice would be very much appreciated!

Thank you!

[Thomas Caron]

Hi have the same problem here. I'm using 2.3.1 on a Windows 7x64. When I connect a screen to the desktop, everything is fine. When I access from a remote desktop I can't see the any buttons...

[Jetguy]

Hint, hint, maybe, just maybe you should be trying to print remotely?

 

It violates a number of known issues here.

If you are printing remotely, you are printing over USB= Fail

If you are printing remotely, USB web camera is NOT enough to operate safely=Fail

The fact you are having problem before you even try to print=Fail

 

Nuff said.

[Jetguy]

In case that hint wasn't enough:

Copied from the other group, original post by Dan.

 

A reminder of why we need to be careful.  We're all guilty of doing it: leaving

our 3d printers running unattended.

This was posted over at the Ultimaker forum.  NO, it's not an Ultimaker.

Posting was

https://groups.google.com/d/msg/ultimaker/tOx2ED07F9A/YTChN8owRUUJ

And the cost of dealing with the smoke damage to the office exceeded

the cost of the bot.

[Arjun M]

lol Jetguy,

I appreciate the concern about printing remotely....

But I'm not trying to initiate my 3D printer at home while I'm sitting at my office desk. In our general purpose media room, I have my 3D printer located in the corner of the room, on a counter. I have a Windows 7 computer connected to the 3D printer (makerbot replicator). That computer only acts as a home server to store all of our media. As a result, there is no monitor connected to it. So the only way for me to access it is by initiating remote desktop from my other computer, which is sitting at a different corner of the same room.

In other words, I want to be able to sit in one corner of the room on my computer I use for 3D designing, and then I want to copy the STL file via remote desktop into makerware onto the home server desktop and have it control the makerbot.

I prefer having a computer directly connected to the printer via makerware rather than printing with an SD card. But I can't have my main 3D designing/video game computer always connected to my printer because it is too far away. And I want to be able to play video games while I wait for the print to finish!

So I still need to figure out a way to allow one computer to control my Makerbot while it is connected either on the network or directly to another computer.

I know there is a such thing as a wireless SD card, but I don't want to use that because it still acts like an SD card. I want to be able to control the replicator directly from a computer.

[Arjun M]

Hm Thomas. Glad you were able to confirm that the issue is specific to remote desktop.

One of my friends was recently talking about how DirectX and OpenGL are not supported in remote desktop connection. This may have something to do with it. We may need to use different software to connect.

I'll look into it this weekend.

[Jetguy]

We have a solution that works with your problem.

Toshiba flash air card + Sailfish Firmware+ Custom script equals wireless connection to the bot.

I'm just trying to impress upon you, "You're doing it the hard way"

[Jetguy]

https://groups.google.com/d/msg/makerbot/Rst5ZIfs5L0/uuNP0bJL8HwJ

Explains everything about using the Toshiba air.

 

Now, your problem of running a headless windows 7 box, well that's a problem I cannot solve. I mean come on, so the application uses graphics card acceleration that obviously is not going to work over RDP.

Your choices are use a different slicer, or slice on the other machine directly. The air card solves the printing over USB problem basically making the headless win 7 a moot point.

[Jetguy]

In case you missed it, for about 1 million reasons, printing over USB is  problematic. Between some safety concerns of  how the bot handles errors in the commands it receives to EMI/RFI noise which can cause failing temperature reads, it's beyond highly recommended to NOT print over USB. Printing over RDP over USB is asking for problems.

[Dan Newman]

On 11 Oct 2013 , at 3:44 PM, Jetguy wrote:

> In case you missed it, for about 1 million reasons, printing over USB is
> problematic. Between some safety concerns of how the bot handles errors in
> the commands it receives to EMI/RFI noise which can cause failing
> temperature reads, it's beyond highly recommended to NOT print over USB.
> Printing over RDP over USB is asking for problems.

Of course, with RepG you could BOTH start a print from SD via RepG AND
monitor the print over USB. Giving folks who like monitoring via their
desktop a happy medium. But it was also known that just monitoring the
print temp over USB would cause print quality issues. And that was even
when printing at 30 - 40 mm/s without acceleration. 'tis why MBI added
to RepG the option to not monitor the temp over USB while connected to the bot
and printing (from either SD or USB) -- they did that back before they
had accelerated firmware and people were printing at slow speeds of 30 to
40 mm/s.

Dan

[Arjun M]

I didn't know about the issues with USB printing, good to know! I have printed 30 minute to 10 hour prints using a direct USB connection with Makerware, and haven't had any issues. Have I just been lucky so far, or does Makerware not have this problem that RepG has?

Haha I attached a video of my situation. I'm all the way here and really want an easy way to print over there :-P. 

Are you guys recommending just sticking to the SD card? (or toshiba air + sailfish + script, although I would really love to just be able to click the "Make Now" button on Makerware and have it work..)

haha

[Jetguy]

Yes, I ONLY print from SD card and so do a lot of other folks.

You might take a look at a technical discussion of a problem that was found.

https://groups.google.com/d/msg/jetty-firmware/qj_h43v8aI8/4eeSn0HeMvgJ

 

The bottom line is that SD card uses less CPU cycles of the onboard processor giving you a better and more reliable print.

Just because your bot didn't outright fail during a print doesn't mean you never had a problem.

Everything from tiny little pips or bumps resulting from micro pauses that happen when the USB coms has issues from the motion planner being busy.

There is a difference in print quality, it might not be huge most of the time, but there is a difference.

[MacGyver]

I don't know why you guys hate printing over USB so much?  I've printed literally 1000's of things over USB with my TOM and never really had any problems whatsoever.  In fact I've tried to print from the SD card and couldn't ever get it to work.  

[Dan Newman]

It's definitely a YMMV issue. But there are known, severe cases such as
the chap who had commands dropped when printing over USB (even logged
as such by RepG) and then had his heaters go to 290C at the end of the
print. Was reproducible even which made for a really nice test case
which we shared with MBI. Issue was not possible over SD card as it
related to the firmwares not returning error responses back over the
S3G protocol. Sailfish 7.5 resolved this particular issue in Sailfish.

And, keep in mind that back when we ported Sailfish to the Rep 1 for
MBI, Jetty invested a considerable amount of time in figuring out how
to improve USB comms responsiveness and thus, with the advent of
MBI's 7.0 firmware (Sailfish 6.2 or thereabouts), there were some
improvements.

However, there's still some quality issues stemming from the 16MHz
AVR being overtaxed at times. Again, YMMV (indeed, Your Mileage Will
Vary, YMWV).

Dan

[Sean Hunt]

I too previously used RDP to run Makerware and saw the exact issue you are seeing! I do not print using USB but I was using it so that during my lunch hours at work I could RDP into my home computer and get all my prints lined up for the evening.

There have only been a few times when I could use RDP with the new Makerware and it seems to be only if I have just rebooted my PC and not run any other graphical programs.

Also if I close Makerware then restart it I have seen this situation. 

I have been unable to find a solution to it other than to install Makerware on my work computer and create all my x3g files on that computer and either use a SD card I carry with me alost everywhere or to transfer the x3g files onto my home pc other ways.

The latest version of Makerware is running native code now and so I would expect there are still a few issues that need to be ironed out. I believe this to be one of them

As a software engineer it looks to me like Makerware is not shutting down cleanly with the graphics drivers, which they could get away with previously but since it is now native is causing problems..

Makerware v2.3.1.18 fixed alot of issues for me but this was not one of them.

One possible workaround is to open Makerware whilst physically at your PC then when you are at work you can RDP into your machine and Makerware is already open and should have all the buttons etc displayed. The trouble with this is you have to work without shutting Makerware down, after creating each x3g file you have to delete everything off the build plate and start adding the new objects. (Occasionally do this still but keep accidentally overwriting old files etc)

Purely out of interest what display card and drivers are you using, I use a AMD Radeon HD 6670 with driver version 12.104.0.0? I have other PCs with older GeForce cards that I do not usually see this issue with..

I hope this helps somewhat..

Sean

On Thursday, October 10, 2013 1:10:42 AM UTC-7, Arjun M wrote:

[Arjun M]

Thank you for the feedback, Sean! I did read online somewhere that the way RDP works, if you first load the program from the computer and then RDP later, it will work. Looks like you confirmed just that!

But I don't have a monitor to access my machine from. It doesn't have a dedicated GPU - it has a Core i3 processor and is pulling the graphics from that. This computer is really just meant as a storage device.

Haha I guess I'll stick to the good 'ol SD card for now :-P.