OpenBuilds CONTROL Software

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

 

Thanks, but what if you try each in turn, with both disabled theres still two smoking guns (; would be nice if we can drill it down just a little more (is skybox, or is it the realtime position indicator, which one causes the hang)

 

If you rotate the 3d view around there is an horizon, and then a blue sky above it. Also some nice fog to make the sky look realistic. Totally just eye candy, though it does help you keep your orientation when you look at the 3d view from weird angles, instincttively humans try and reference off an horizon for level

 

Thanks for the report, let me see if I can replicate - EDIT: Fixed in v1.0.198 - will be available in update channels shortly - just waiting on Amazon AWS's DNS problem to get sorted so I can push out the update:

 

Amazon AWS issue seems to be solved, should start automacally updating the next time you run control, or grab it from OpenBuilds Software - FREE Software for CNC Control: OpenBuilds CONTROL and OpenBuilds CAM or https://github.com/OpenBuilds/OpenBuilds-CONTROL/releases/tag/v1.0.198

 

you should try them one at a time so we can find out which part it is (;
Disabling the whole kaboodle gets you working, but misses out on a debug opportunity

Not came back, just still havent found the cause of the problem, so never had it fixed remember (; - we need to find out which one it is!

See the changelog if you ever wonder what changed between version: (on the troubleshooting tab in control, or on software.openbuilds.com or on OpenBuilds/OpenBuilds-CONTROL:

 

Oh and all old versions, bug reports, source code etc lives on Github: OpenBuilds/OpenBuilds-CONTROL