@matcoller I can probably help with rotating the screen. I'm guessing you had issues with rotating the touch events as well. I dont know if it will make the UI better or not, but if you want to try it, DM me.
At that resolution it should fit both vertically and horizontally: Post some pics, lets see whats off?
I am also getting the webgl error, so no preview of what I'm cutting. I get true for !!window.WebGLRenderingContext, but false for the next two. I am running an older Dell Inspiron E1505 laptop with windows 7, 32 bit and intel 945gm graphics.
Either graphics card, or drivers. Sometimes you just need a little newer hardware, WebGL needs a little oomph
That sounds about right. The driver is the newest one, and the graphics card is integrated into the motherboard. Thanks for the reply.
@Peter Van Der Walt Have you seen this? I can confirm its an issue: G Code (G21), XYZ Touch Probe Question
can someone explain to me what might be happening here?... I am running CONTROL v1.0.148 on OSX 10.13.6. The App opens ok, but as soon as I connect via USB, these prompts flash up continuously...
the same thing happens on UGS though. The Blackbox was originally flashed on a Windows PC, but now I am trying to connect using a mac. thats could be the problem perhaps?
I've seen that error once when I had an error in my gcode, but you say its happening right when you plug it in, before you load any code. I'm going to ask some obvious questions here, because I'm not really sure what's happening, so bear with me. Also, I'm not a mac user nor am I the person who wrote the program, but I'd like to help if I can. Did you install the FTDI drivers? Are you sure you're connecting to the correct port and not some other device? Edit: You can connect to it just fine with windows so we know the blackbox is good. Curious, why did you flash it?
I did a google search of the errors you're getting from grbl. It may point to a bad usb connection. What happens when you press the reset button on the blackbox?
I have just loaded the FDTI firmware. The OS was preventing it from running so I had to deliberately allow it to run. But still no change. In terms of the flashing. All I did was run the G-code flashing option from the troubleshooting tab. pressing the reset button lights up one of the motor indicators on the side. But no activity from the usb led. This is all the info I can get to on the troubleshooting page. Obviously can get to settings page as I would need to connect first.
it seems to be working now. I'm not sure what made the difference. thanks for your help anyway sharmstr!
Excellent! (because I was out of ideas. lol) Edit: Heads up. There is a bug with the macros right now. It wont effect you running jobs, but just need to be aware of it. Peter will fix it once he's back online I'm sure.
Not sure that's listed anywhere, but its basically a web app and it can run on something as simple as a raspberry pi. So, you dont need much. With that said, I dont think it can run on Windows 95 LOL
I am having trouble getting it to run correctly on 2 different laptops which should be a little more powerful than an rpi. One is running windows 7 and the other running windows 10 and Ubuntu. The windows 7 laptop has WebGL error and also keeps crashing on the com port/ USB port. <---- So, not good enough graphics to run the webgl, and maybe a bad driver for the usb. The windows 10/ Ubuntu laptap runs the software fine until any gcode is loaded. It crashes the software every time with a white screen where the software was running. I guess the shared 3gb of system ram is not enough to run it with integrated graphics. Is the rpi able to render the preview screen of the gcode when loaded? I should mention the software crashes the same way running Windows 10 or Ubuntu. So, that tells me it's hardware related, I would assume.
Yes, if you search a few posts back, I explain how to get the preview to work on rpi. You can try debugging by hitting F12 and bringing up the inspector. Check the console. There's info on how to do this early on in this thread. Unfortunately, that's about all the support I can offer. Peter will probably offer better support when he's back online.
Thanks for the info. I bought another laptop from ebay and am waiting for it to come. Lenovo T430S i7-3520M 2.9GHz 16GB RAM 128GB SSD Nvidia 5200M If that doesn't power software that can be ran on a rpi, then I should just give it up. It doesn't even make sense that the laptops I have won't do what a pi can!
Did you make the changes I referenced before? Here is the post I was talking about: OpenBuilds CONTROL Software
Have you tried another file? What board? What version of grbl? Same usb cable you used on the other laptops?
Smaller files work fine. rpi not hooked up to anything, so board, usb cable is not causing the issue. Large files load fine on my desktop gaming pc with 32gb of ram, just not on anything else. I was able to run a large file on the windows 7 laptop that the webgl is not supported on. I couldn't see the preview screen, but ran the file anyhow, and it worked that way. Just seems the software is memory hungry. Most of what I do are 3d carvings, so the smaller <1mb roughing files seem to load fine, but the finish pass cgode files are much bigger, and are crashing the software.
Will pop in with some replies later guys We just had a baby so I am on leave and out of town, but will pop in later today and check these out for you all when I get back home. Sorry about the delay
By nature yes, WebGL can get memory hungry with large files (lots of small moves) OpenBuilds CONTROL is meant for that "Something easy to get you started" - so as you outgrow it with more advanced needs (work coordinates, advanced setups, rotary work, massive files etc) - we almost hope as you grow, so too does your need for better software. Making software to fit both beginner and adanvanced users, always ends up sacrificing something for both. As our dream is to make CNCing easier for everyone, we also have to compromise on some things. Running on the machine without WebGL - will run just fine, without the preview. If we detect the that the machine doesnt have webgl, we also dont enable gcode parsing, 3d viewing and all other functions requiring webgl. So it speeds things up a lot. As for why the machine doesnt support webgl: we simply check what chromium says the machine can or cannot do. Its always a case of drivers, hardware or OS configuration: All we do is check if the machine has a WebGLRenderingContext and can create an experimental-webgl canvas: var webgl = (function() { try { return !!window.WebGLRenderingContext && !!document.createElement('canvas').getContext('experimental-webgl'); } catch (e) { return false; } })(); Do post some of those big files that crash out as a white screen and I'll see if we can see why it fails