Connection on UDOO Quad

tkramm

I have some problems to connect to a printer on the UDOO Quad external via USB and also the onboard DUE. It seems that it reconnects all the time, since I hear the reset from the Motors. Firmware is 0.92 and runs fine with repetier-server on the mac.

When i set a wrong serial speed it switches to connected in yellow.

Also for the internal DUE, it is not selectable until an external Arduino is connected and makes the list of ports available.

for the listing of ports in Octoprint you need to manually add the port /dev/ttymxc3 (http://forums.reprap.org/read.php?249,446256,446508#msg-446508)

btw. in Octoprint both (internal/external) connect fine and work.

Repetier

Are there any hints in the log (from printer menu reachable, should be in connected log what happens). Have no UDOO for testing, but connection of Due with a Cubietruck worked so far without problems.

tkramm

No, it doesn't create any log entrys.

tkramm

Since latest Version 0.50.3 connection on the USB ports works perfectly now, but still no success with the onboard Arduino on /dev/ttymxc3

Repetier

I have reports that it worked at least on standard debian. 

Important i sthat the user repetierserver has rights to use that port. Since octoprint works, can you say in which groups your octoprint user is? Adding repetierserver to the right group should work.

orcinus

I had the exact same issue.

The solution is to add repetierserver to groups "intserial" and "ugpio".

However, there is a different problem on the UDOO...

The Control tab sometimes freezes Chromium and sometimes it causes a brief disconnect for some reason.

Most of the time it works correctly, it's very very random.

I'm guessing it has to do with KineticJS and its usage of canvas.

orcinus

Scratch that, i just had it report a disconnect on my desktop as well (Chrome 39, Windows 8.1).

Resizing the window while in Control tab triggered it.

Repetier

Thanks for the group hints. Hard to find it out without having the hardware.

The disconnects have an other reason. The server closes a connection if it does not get a ping within 5 seconds. Website pings every second but it seems some operations block longer like tab switches or uploads. Then it directly reconnects and work goes on. Still need to learn when browsers block to make it less often happen. Should have no impact on the print it self also I heard the preview might stop until reload.

orcinus

Ah! Thanks for the heads-up.

Sorry for going so offtopic, but are there any plans for adding a "skin" or "theme" support?

I'd like to give making  a compact touch-friendly interface a go (for 7" screens), but don't want to mess up the existing UI.

Also, might be a cool feature to serve one interface on localhost and another for remote connections

That way web browsers connecting remotely would retain the responsive, regular UI, while machines with a local screen could run the compact touch-optimized version.

tkramm

Thanks for the tip, seem to work now.

Repetier

@orcinus Yes there are plans. We have already published the complete web api here: http://www.repetier-server.com/documentation/

So making new interfaces is no problem. Now I'm working on a module system for the pro version. That will allow new webpages and also new programming logic inside the server program (logic using lua to make it compatible for all platforms). Part of the module system will be the possibility to inject new css/js/html pages allowing to extend the existing web frontend. With css you can also replace colors/fonts etc. I hope also to publish the javascript services and directives to make it easier to make a new interface, but that will take some time.

Concerning the on computer touch screen I'm not sure what the way should be. Especially boards like the pi have not much power and a browser for the frontend might be too much. No problem with a UDOO I guess. After all we also want to add a slicer and stl raytracer which also need some resources when running locally.

orcinus

I'm actually trying to avoid slicing on the same machine, as i usually do it in concert with tweaks in CAD, fixes in Netfabb etc. So controlling the machine locally is the only thing, with the ability to upload an already sliced gcode model to SD card on the machine.

The idea is to use the (remote) web interface for control whenever possible, and in that scenario, there are no benefits from slicing on the server - i'm sitting at a far more powerful machine anyways. However, if i'm setting up a print manually and/or debugging, a local screen is a must. I normally use a G-code console for that, but with a touch screen that's obviously not very convenient, so a pronterface-like panel is what i'm aiming at in that scenario. Something like VizPrint's UI, perhaps, but with multiple extruder and SD support (and less crappy):

For everything else, there's the remote web interface.

PS: LOVE the future plans for the API and modules! In that name, i've contributed a small donation via the site

orcinus

Again, very offtopic, but wanted to mention it here before i forget:

Just stumbled upon a problem that was driving me crazy for 15 minutes (i thought the Due on the UDOO got fried) before i realized what's going on. If you remove a RADDS from Due flashed with Repetier, Repetier fw will silently crash on start and stop responding to the outside world.

I suspect this is due to EEPROM on the RADDS.

It might be a good idea to proof this a bit and make it a soft(er) failure, or at least put up a warning/notice somewhere so people don't get confused

Repetier

Yes, it's the missing eeprom. I2C call never returns here. One reason I copy complete eeprom at startup to have no unwanted eeprom reads during prints.

Writing a simple control interface should also be simple. Also I want to add a way to use the APIKEY for such access so no login/password is needed. Mein problem for us would be to have such a page for all sizes. A 4" display surely needs a reduced set. But I think we could also add at least a demo implementation making it easy to adopt a personal version with some html changes.

orcinus

Love that idea.

Just a stub version that can be modified for personal use would be enough.

But regarding screen sizes - there only need to be a few of them, as screen sizes commonly in use are pretty limited - it comes down to 4", 7" and 9". Bigger screens (15"+) can probably use the regular web interface (if someone can fit a screen greater than 9" onto/near your printer, they can quite likely fit in a small keyboard and a mouse as well

Repetier

Yes, you are right. Since websites are more or less invariant to high dpi displays with same size a 4" and 7" version should suffice. I can already control it from my iPad 9,7" withh full frontend, but I guess that would be to heavy to run a small device like beagle bone or raspberry pi. It shoudl still run the server without interruptions and especially things like 3d and 2d plotting may tike quite some ram and cpu power. A simple controlling display is hopefully no problem. Will see that I get a display myself for testing/developing.

One thing that is bothiering me since I saw some videos is that all showed a cursor where you touched display. Do you know a solution to make it behave like a tablet without cursor?

orcinus

Nope, i'm still researching a solution to that too.

I did notice, however, that on UDOO it doesn't ALWAYS move the cursor at the touch point - only sometimes, i think when it detects a touch and drag.

So there obviously *is* a way to do it somehow.

orcinus

Actually, i've just thought of a (roundabout) way to do it.

Changing the cursor file to a transparent image.

orcinus

Another semi-solution:

sudo apt-get install unclutter

unclutter -idle 0

It will not hide the cursor completely - it will show at the touch point briefly and disappear.

Which isn't that bad, as it gives feedback of a tap at least.

Oddly enough, doing that on the UDOO makes the cursor show up more often than without it (with the default UDOObuntu distro).

And another, more permanent solution, but it requires snooping around to find the right place to edit: start X11 with the -nocursor option ("startx -nocursor")