OpenBuilds CONTROL Software

@Steveathome is correct, maximise the window, zoom into the grid (default view shows full grid. Once you load a file it zooms to the extents of the job.. Got to have some defaults and seeing the whole job makes sense. After that its under your control, i usually tilt the view back so i get some sideward view too

 

Smoothieware is not supported, only Grbl.

Networking support is not included or planned as stock Grbl does not have networking.
If you want to use a network bridge use a TCP to virtual comport application to create a virtual serial port.

 

What is more important. The 3D view or the interface, buttons, etc. What does the viewer do: it shows you which file you loaded, and allows you to inspect the gcode a little. That's all. What really counts is being able to see the DRO, and have decent buttons that work on a touchscreen too. The 3D view is significantly less important, because it is also less usefull, than the other elements on screen. Accordingly thats how screen real estate is divided.

Also, it has to fit every user, so compromises are to be expected. Some people have widescreens, some do not. Etc

Having the extra width is awesome on the 3D viewer too, just hover over the viewer and turn the scrollwheel on the mouse: see how it uses the extra space now (;

Reposition the view using middle and right mouse button drag

 

Not sure what Keyboard shortcuts you except to have effect on the DRO specifically (; , but all keyboard shortcuts can be viewed (and conversely edited) from Wizards and Tools > Customize Shortcut Key Assignments:

 

Still rocking that old Windows 7 Laptop from 12 years ago?

We've added a menu to Disable the 3D viewer - that should help you use all the other great features of CONTROL, but without the 3D viewer (which is just Eye candy really) which slow machines couldnt handle



Some others of you reported an issue where sometimes the job stalls for a couple seconds, with CONTROL showing Not Responding along the top, if you were one of those, PLEASE do a test for us with this: Disable the viewer and run a job, see if the stalling went away. Give us feedback please! As it doesnt happen here in our labs, we need those of you who do have the issue to help test: Does disabling the 3D Viewer make a difference to the stalls. This will help us zoom in the root cause of that issue

 

As does good headers in the gcode comments (;
This is for those people who insist on using old hardware, Pi's etc. If you have an OK PC, you don't need it

 

Fix the Fusion Post: Fusion 360: grbl post processor install (the easy way)

 

@DarkPenguin , the G53 move is there for safety. What exact problem is it causing for you?
and there are options for telling it to use an offset from 0. Maybe using that will help you.

 

Great Now when you get a chance, give 1.0.196 a go:

Moved it to the Troubleshooting tab, and added some more fine-grained options (disabling the whole 3D viewer was the nuclear option to see if it even is there that some of you have an issue)
So when you have some time, play with it again, but instead of disabling the whole viewer (top item on the menu) try the finer levels one at a time and see if you can find one that definately relates to the lockups

 

ah, then you can do yourself a favour and 'fake the home'.

The convention/rule is that home is at the positive ends of axis travel, which puts it 'right, away, up' for a router type machine.
The most important one is Z, make sure it is up as far as it will go. X and Y can be in the middle somewhere though I do recommend X+ and Y+.

Now, turn on or reset the GRBL controller (or even just connect the GUI which will reset GRBL).
now GRBL thinks the current position is *home*.
now you can jog to where this workpieces 0,0,0 point is and 'set zero' there (which sets the G54 offsets without changing home), and cut your job as usual.

Before turning off when your day is done, just send it to the home position.
I define a macro button for it

Code:

G53 G0 Z0
G53 G0 X0 Y0

This raises Z safely to home Z0 and then moves to X0 Y0, ready for faking home next time your turn it on. It is important to raise Z first, this makes it very likely that the tool will miss anything lying on the table when it moves to X0Y0 (my router table is a 'flat spot' and therefore collects junk so I find this useful)

doing this also removes the randomness which means that G53 safety moves in Gcode will always be predictable and safe, set the offsets in Fusion to 0, you only really need an offset when you do have home switches because then going to 0 will actually trigger the switch, so one would normally set an offset of -10mm to prevent that.

 

Thats the problem. MKS boards have notoriously cost cut hardware so the USB chip cant keep up and breaks the serial stream. Throw it out and get a decent controller

 

Sadly no, theres no way to fix the board in place. The hardware doesnt deliver the serial stream to the MCU coherently, and as such Grbl balks back with errors as the commands sent isnt what the MCU sees.

Ask for a refund

 

I hear you. But do keep in mind, laser rastering sends a lot more tiny moves than most other kinds of jobs, so it is going to push most controllers quite hard. Cp2102 or FTDI are the only two USB chips that will cope and stay stable. 8u2, CH340, Prolific etc based boards will have trouble keeping up with rastering style datastreams.

 

So second and third: that would be Skybox and Realtime Job Position right?

If you have another minute can we try and see if its one or the other? Would be even better if we can eliminate it down to one